rotor alternative?

[Michael Hudson]

Hmmm... the more I think about it I guess the root cause of the
problem is the archaic, goofy encryption export laws of the U.S..

Unfortunately the US is far from having a monopoly on silly export
laws about crypto.

Given the -- highly international -- way the last year or so of Python
development have gone and e.g. where www.python.org is located it's
unclear what *any* countries *export* laws have to do with it, but
unfortunately many countries have *import* laws too. The world is a
sorry place.

Cheers,
mwh

 

[Paul Rubin]

First, not necessarily, if you're in a country that has legislation
controlling strong encryption (and yes, we know "that should be
fixed", but sadly we don't have that power ;-).

I don't know of any country that controls strong encryption and
doesn't control weak encryption. Back before the US export controls
on encryption softened up, the regulations were quite clear, you had
to get a government license to export any kind of encryption whether
it was weak or strong. The only difference was that weak encryption
was easier to get licenses for, but you still had to get a license.
Rotor would not have been exportable without a license. Even today,
you still need a license, but for cryptography in programs like Python
(whether weak or strong) you get the license automatically by
notifying the Commerce department by email what it is that you're
exporting (http://www.bxa.doc.gov/Encryption).

Second, if you have
to have the key around anyway (true for some applications), it really
doesn't matter how secure the algorithm is.

I'm not sure what you're getting at here. The normal use of
cryptography is to transmit or store data that can be intercepted by
an attacker. Obviously you don't transmit or store the key with the
data.

 

[Paul Rubin]

Given the -- highly international -- way the last year or so of Python
development have gone and e.g. where www.python.org is located it's
unclear what *any* countries *export* laws have to do with it, but
unfortunately many countries have *import* laws too. The world is a
sorry place.

I still think Python should have good crypto, but if necessary it can
be separated from the main part of the distribution, or there can be
two separate distributions (with and without crypto).

Sun used the first approach when it separated JCA (Java Crypto
Architecture) from JCE (Java Crypto Extensions). JCA only provided
authentication mechanisms and not actual encryption, so it was
exportable without a license. JCE provided encryption and you had to
get it separately.

Netscape and Microsoft used the second approach: there were separate
"US" and "export" versions of the Netscape Navigator and MSIE
browsers. The US versions had strong cryptography while the export
versions used weak cryptography. Note that Netscape and Microsoft
still had to get export licenses even for the weak versions, which at
the time required filling out a bunch of forms and waiting for
approval. It got easier as litigation and technical developments
showed the regulations to be more and more ridiculous.

 

[Bengt Richter]

I understand what you mean, but obfuscation _is_ a form of encryption, just one
that's understood to be on the weak side (so the above may be considered "too
weak"). Rather than being _either_ obfuscation _or_ encryption, they really are
just different points on a broad data protection spectrum.

IMO that ignores an important disctinction. I.e.,
obfuscation may be a lossy transformation (or conceivably noise-introducing for that matter)
(e.g., like stripping comments, compiling to eliminate source info, etc.) whereas encryption
ISTM must guarantee recoverability of all the bits.

Regards,
Bengt Richter

 

[Bengt Richter]

Yes, Python should get some real encryption functions sooner or later.
Meanwhile here's something you can use:

http://www.nightsong.com/phr/crypto/p3.py

Just noticed your using time.time.

I believe clock has more bits than time, at least on windows:

>>> from time import time,clock
>>> min([abs(time()-time()) for i in xrange(1000)]) 0.0
>>> min([abs(time()-time()) for i in xrange(1000)]) 0.0
>>> min([abs(clock()-clock()) for i in xrange(1000)]) 5.8666657726975935e-006
>>> min([abs(clock()-clock()) for i in xrange(1000)]) 5.866665771847579e-006
>>> min([abs(clock()-clock()) for i in xrange(1000)])

5.866665771847579e-006

I don't know if it's worth anything, but the change would be easy ;-)

Regards,
Bengt Richter

 

[Bengt Richter]

Yes, Python should get some real encryption functions sooner or later.
Meanwhile here's something you can use:

http://www.nightsong.com/phr/crypto/p3.py

Just noticed your using time.time.

I believe clock has more bits than time, at least on windows:

from time import time,clock
min([abs(time()-time()) for i in xrange(1000)]) 0.0
min([abs(time()-time()) for i in xrange(1000)]) 0.0
min([abs(clock()-clock()) for i in xrange(1000)]) 5.8666657726975935e-006
min([abs(clock()-clock()) for i in xrange(1000)]) 5.866665771847579e-006
min([abs(clock()-clock()) for i in xrange(1000)])

5.866665771847579e-006

I don't know if it's worth anything, but the change would be easy ;-)

Better, if you have a faster machine:

>>> from time import time,clock
>>> min(filter(None,[abs(time()-time()) for i in xrange(100000)])) 0.0099999904632568359
>>> min(filter(None,[abs(clock()-clock()) for i in xrange(100000)]))

5.8666657594130811e-006

time() seems to be getting the basic NT4 scheduling slice time on my box.

Regards,
Bengt Richter

 

[Paul Rubin]

Just noticed your using time.time.

I believe clock has more bits than time, at least on windows:

Interesting, I might try that. Thanks.

 

[Peter Hansen]

Interesting, I might try that. Thanks.

The docs for Py2.3 say:
"""On Windows, this function returns wall-clock
seconds elapsed since the first call to this function, as a floating
point number, based on the Win32 function QueryPerformanceCounter().
The resolution is typically better than one microsecond. """

I wonder if the part about "since the first call to this function" would
make this dangerous for your purposes.

-Peter

 

[Paul Rubin]

The docs for Py2.3 say:
"""On Windows, this function returns wall-clock
seconds elapsed since the first call to this function, as a floating
point number, based on the Win32 function QueryPerformanceCounter().
The resolution is typically better than one microsecond. """

I wonder if the part about "since the first call to this function" would
make this dangerous for your purposes.

I don't run Windows and don't want to use something Windows specific.
Although, "since the first call to this function" is probably ok. All
that's needed is to get a unique number to initialize the internal
PRNG with. Hopefully sometime, the Python library will include a C
extension to get secure random numbers from the Windows Crypto API.
On *nix, they are already generally available from /dev/urandom.

 

[Peter Hansen]

I don't run Windows and don't want to use something Windows specific.
Although, "since the first call to this function" is probably ok. All
that's needed is to get a unique number to initialize the internal
PRNG with. Hopefully sometime, the Python library will include a C
extension to get secure random numbers from the Windows Crypto API.
On *nix, they are already generally available from /dev/urandom.

It just struck me that if it's the first call to the function during
a given program invocation which matters (as opposed to during a power-on
cycle of the whole PC), then it seems possible that you'll get exactly the
same valueeach time you call it if it's called only once by the program.

-Peter

 

[John J. Lee]

(e-mail address removed) (John J. Lee) writes: [...]
Sorry for my ignorance, but how do you get to decrypt the code to run?

What code?

Use any kind of wrapper? Is such a wrapper written in C? Do you store
the key inside such a wrapper?

The same problem would happen with AES or any other crypt method:
where and how to store the key in a way that's easy for the user.

Gee, I guess so ;-)


John

 

[Bengt Richter]

It just struck me that if it's the first call to the function during
a given program invocation which matters (as opposed to during a power-on
cycle of the whole PC), then it seems possible that you'll get exactly the
same valueeach time you call it if it's called only once by the program.

Ugh, you're right:
====< firsttimes.py >=======
import time
c = time.clock()
t = time.time()
print c,t
============================


[16:27] C:\pywk\ut\crypto>firsttimes.py
1.25714266558e-005 1069374432.09

[16:27] C:\pywk\ut\crypto>firsttimes.py
1.25714266558e-005 1069374437.29

[16:27] C:\pywk\ut\crypto>firsttimes.py
1.25714266558e-005 1069374445.84

[16:27] C:\pywk\ut\crypto>firsttimes.py
1.25714266558e-005 1069374449.78

[16:27] C:\pywk\ut\crypto>firsttimes.py
1.17333315454e-005 1069374454.33

Why'd they do that? On my platform it ought to go back to either to the rdtsc pentium
instruction, which reads a 64-counter of CPU cycles since power on (I assume it
starts from zero) or maybe to the clock chip time counter, which is probably ~55ms/2**16 or so
resolution. But this looks like python gets and stores a value on _python_ startup
as a reference.

Well, at least the least significant bits ought to be fairly random after some time
has gone by. Hm, ... except that NT scheduling may group sampling towards the beginning
of the 10-ms slice times anyway. Phooey. Sorry Paul, I didn't realize it was re-zeroed like that.

Regards,
Bengt Richter

 

[John J. Lee]

(e-mail address removed) (John J. Lee) writes: [...]
I don't know of any country that controls strong encryption and
doesn't control weak encryption. Back before the US export controls

[...]

That's interesting.

I'm not sure what you're getting at here. The normal use of
cryptography is to transmit or store data that can be intercepted by
an attacker. Obviously you don't transmit or store the key with the
data.

Oh, do we have to go around this loop again?

You can if your aim is _obfuscation_: simply to place a minimal
barrier in front of people so they have to do something more than XOR
some data. Regardless of the facts that breaking rotor encryption
takes little computing poser, and that knowledgeable people can and do
write code-breaking programs for the rest of us to use without needing
to know anything, the act of obtaining such a program is itself a
psychological barrier to decryption: you can't fool yourself about
what you're doing. Arguably XOR comes appreciably lower down the PITA
scale, since the decryption algorithm is trivial: it may, for example,
be implemented with an editor macro.

In fact though, I'm really *not interested* in whether this argument
is correct -- the mere fact that it's a valid way of thinking
suggested to me that it was odd to deprecate the module, after
(presumably) having put it in for this very purpose (obfuscation) in
the first place. However, if you're right in suspecting that
anti-crypto legistlation is always (or even usually) applied without
exception or waiver even to broken algorithms, then I agree it's
pointless -- after all, AES would serve just the same purpose!


John

 

[Paul Rubin]

Arguably XOR comes appreciably lower down the PITA
scale, since the decryption algorithm is trivial: it may, for example,
be implemented with an editor macro.

You're talking about using rotor in a protocol where the key is included
with the ciphertext. In that case, you can decrypt without even bothering
to write an editor macro--you can just use the existing rotor module.

In fact though, I'm really *not interested* in whether this argument
is correct -- the mere fact that it's a valid way of thinking
suggested to me that it was odd to deprecate the module, after
(presumably) having put it in for this very purpose (obfuscation) in
the first place.

To my mind deprecating it is a way of recognizing that it was a
mistake to include it in the first place. Maybe in some farfetched
situation (Hollywood special effect movie) it makes sense to put an
explosive self-destruct charge into a car. That doesn't make it
anything other than insane to include a self-destruct charge in every
car that rolls off an assembly line, triggered by a button on the
dashboard that you might press while trying to adjust the CD player.

Rotor should never have been shipped with Python. If some application
programmer actually has a sensible use for it (I doubt this), then the
programmer should download the module from somewhere and ship it with
that specific app.

However, if you're right in suspecting that anti-crypto legistlation
is always (or even usually) applied without exception or waiver even
to broken algorithms, then I agree it's pointless -- after all, AES
would serve just the same purpose!

I'm going to have to catch up with the python-dev traffic about the
legislation issue but I think it's silly to leave crypto out of the
library because some regime somewhere doesn't permit its use. Apache
2.0 now ships with SSL by default, and I don't think its popularity or
useability has been impaired.

 

[Nick Vargish]

the act of obtaining such a program is itself a psychological
barrier to decryption: you can't fool yourself about what you're
doing.

Not just a psychological barrier, but a legal one, if your aim is to
provide a possible basis for future litigation.

I worked at a software company whose products required the customer to
enter a software key as part of the install process. The key
generation algorithm was rather simple, and it would have been easy to
generate bogus keys. But the very act of entering a bogus key provides
a grounds for legal action. You can't just say "I thought I could
install as many as I wanted," since the terms for acquiring a key were
explicit.

I would assume a similar principle would apply to people who
circumvent obfuscation in order to poach software.

I do understand that lawyers and engineering best practices often part
ways early in the game, I'm just trying to explain a non-technical
reason for obfuscation (as engineers, our constraints often have
nothing to do with actual engineering -- sad but true).

Nick

 

[Paul Rubin]

Not just a psychological barrier, but a legal one, if your aim is to
provide a possible basis for future litigation.

Rotor is not needed to provide that barrier. You can do the same thing
with a simple xor against the key.

 

[Nick Vargish]

Rotor is not needed to provide that barrier. You can do the same thing
with a simple xor against the key.

Since rotor is there, though, people have used it.

It's also a nice homage to one of the defining periods of "modern"
cyptography. But that doesn't mean it needs to be in the standard
library.

Nick

 

[Jorge Godoy]

(e-mail address removed) (John J. Lee) writes: [...]
Sorry for my ignorance, but how do you get to decrypt the code to run?

What code?

Weren't you obfuscating Python code? Or did I read it all wrong?

 

[John J. Lee]

Rotor should never have been shipped with Python. If some application

[...]

Was it *really* intended as an encryption tool? I'm amazed. Hasn't
anyone on python-dev heard of Bletchley Park...??

I'm going to have to catch up with the python-dev traffic about the
legislation issue but I think it's silly to leave crypto out of the
library because some regime somewhere doesn't permit its use. Apache
2.0 now ships with SSL by default, and I don't think its popularity or
useability has been impaired.

Another point, of course (I say of course, but it only just occurred
to me ;-), is that you have to find the key in the first place (even
though it's sitting on your disk somewhere, in the scenario we were
discussing). I guess that's just an easy brute force search through
the appropriate disk files to find the key, but even so, probably
enough of a barrier to make it the "bottleneck of inconvenience",
hence to make rotor no better or worse than XOR as an obfuscation
tool.


John

 

[Magnus Lie Hetland]

(e-mail address removed) (John J. Lee) writes: [...]
I don't know of any country that controls strong encryption and
doesn't control weak encryption. Back before the US export controls

[...]

That's interesting.

I'm not sure what you're getting at here. The normal use of
cryptography is to transmit or store data that can be intercepted by
an attacker. Obviously you don't transmit or store the key with the
data.

Oh, do we have to go around this loop again?

You can if your aim is _obfuscation_: simply to place a minimal
barrier in front of people so they have to do something more than XOR
some data.

[snip]

How about using rot13? At least it's build-in

Wasn't the Adobe encryption for eBooks (which Sklyarov was imprisoned
for "cracking") something close to rot13?

http://zork.net/pipermail/free-sklyarov/2001-July/001045.html

Not exactly clever stuff, but quite funny :]

Hooray for 'Nqbor'.decode('rot13').