rotor alternative?
Robin Becker
doesn't seem to be an obvious alternative. I'm using it just for
obfuscation. It seems we have ssl available in 2.3 for sockets, but
there seems no obvious way to use that from python code.
Is an alternative to rotor planned?
--
Robin Becker
Dave Brueck
I'm in the same boat - I wish rotor would stay because I commonly need a way to
keep the honest people honest. I'd prefer to use a standard (builtin) module,
but lacking that I've switched to using this AES module:
http://eevolved.com/cryptkit/index.php?page=5
Since I'm not going to great lengths to hide the key, it works out to be about
the same strength of encryption as rotor. ;-)
-Dave
Irmen de Jong
> It seems that the rotor module is being deprecated in 2.3, but there
> doesn't seem to be an obvious alternative. I'm using it just for
> obfuscation. It seems we have ssl available in 2.3 for sockets, but
> there seems no obvious way to use that from python code.
For obfuscation, I'm sometimes using just plain base-64 encoding.
For extra obfuscation, you could first rot13 the string,
then zlib.compress it, then base-64 encode it.
To decypher it, people have to make a conscious decision to do so.
No security here, but I find it good enough for most obfuscations.
--Irmen
Robin Becker
<irmen@-NOSPAM-REMOVETHIS-xs4all.nl> writes
pages. There're implementations of rc4 in python, but having something
in the standard distro eases maintenance.
--
Robin Becker
Paul Rubin
Yes, Python should get some real encryption functions sooner or later.
Meanwhile here's something you can use:
Aaron Watters
> Is an alternative to rotor planned?
Dunno, but I've been using this in my own experimental
development (private key, synchronous communication).
http://athos.rutgers.edu/~aaron/python/pulver.py
I don't know how strong it is, but I rashly guess that
it might be pretty strong.
-- Aaron Watters
ps: [off topic] go http://www.cs.rutgers.edu/~aaron/img/
for pictures of my new niece.
===
nothing exceeds like excess
Paul Rubin
> > Is an alternative to rotor planned?
> Dunno, but I've been using this in my own experimental
> development (private key, synchronous communication).
>
> http://athos.rutgers.edu/~aaron/python/pulver.py
>
> I don't know how strong it is, but I rashly guess that
> it might be pretty strong.
At first glance that function looks awful (no offense intended), and
the implementation looks very slow. I'd strongly advise against doing
anything serious with it. If you want a pure-Python cipher, please try
http://www.nightsong.com/phr/crypto/p3.py
which uses the library SHA function to generate the keystream for a
stream cipher. It's been vetted by the sci.crypt crowd and should be
quite strong unless I did something silly.
See
http://www.nightsong.com/phr/crypto/blockcipher.tgz
for a proposed new block cipher API which supports the standard FIPS
modes of operation. A reference Python implementation is included in
the tarball but is too slow for production use. I put it aside when
the machine I was writing it on suffered a disk crash, but I ought to
get back to it. My hope is that this module will be added to the
standard Python library once it's done.
Jimmy Retzlaff
> It seems that the rotor module is being deprecated in 2.3, but there
> doesn't seem to be an obvious alternative. I'm using it just for
> obfuscation. It seems we have ssl available in 2.3 for sockets, but
> there seems no obvious way to use that from python code.
>
> Is an alternative to rotor planned?
If the goal is simple obfuscation (and not encryption) then the base64
module might work:
>>> import base64
>>> base64.encodestring('Can you read this?')
'Q2FuIHlvdSByZWFkIHRoaXM/\n'
>>> base64.decodestring('Q2FuIHlvdSByZWFkIHRoaXM/\n')
'Can you read this?'
Jimmy
Robin Becker
writes
URL.
--
Robin Becker
Will Stuyvesant
> It seems that the rotor module is being deprecated in 2.3, but there
> doesn't seem to be an obvious alternative. I'm using it just for
Deprecation is a very serious matter. I love the Python language but
I have questions about the deprecation decisions. The two
deprecations I hate most are rotor and xmllib. I write software that
sometimes has to run on Python 1.5.2 too, because of lazy web
hostings, and I really hate to see the deprecation warnings now when I
run it with Python 2.3 on my laptop. Doing
try: import newstuff
except ImportError: import oldstuff
and then all the tweaking makes me feel like deinstalling 2.3. and
installing 1.5.2 on the laptop too. Especially when there are no real
good alternatives for the deprecated modules! Use xml.sax instead of
xmllib you say? NO! The effbot said it well on c.l.p.: avoid SAX and
DOM like the plague.
--
rotor lives!
dm...@dman13.dyndns.org
[...]
> and then all the tweaking makes me feel like deinstalling 2.3. and
> installing 1.5.2 on the laptop too.
Do you realize you can have _both_ installed on your laptop
simultaneously?
-D
--
Pride only breeds quarrels,
but wisdom is found in those who take advice.
Proverbs 13:10
www: http://dman13.dyndns.org/~dman/ jabber: dm...@dman13.dyndns.org
Paul Rubin
> > http://www.nightsong.com/phr/crypto/p3.py
> Thanks for the kind offer, but I'm getting permission errors with that
> URL.
Oops, try again now.
Paul Rubin
> Deprecation is a very serious matter. I love the Python language but
> I have questions about the deprecation decisions. The two
> deprecations I hate most are rotor and xmllib.
Unfortunately deprecation happens so often because crap makes it into
the library that should have been done right to begin with. I don't
know about xmllib but rotor really should be deprecated, and no one
should use it, because of its security shortcomings.
Andrew Dalke
> Unfortunately deprecation happens so often because crap makes it into
> the library that should have been done right to begin with.
And some things, like the SGI specific libraries, and the old 'regex'
module, aren't so much crap as unneeded in modern code. (I ran
Python on IRIX for years and never used the SGI-specific
modules.)
Andrew
da...@dalkescientific.com
Nagy László Zsolt
You can try pycrypto if you want. What OS do you use?
Unfortunately, I could not find an installer for Windows, but
I created my own - mail me if you want it. Installing on BSD
and Linux is quite easy.
With the pycrypto library, you can use several famous block
ciphers like AES, BlowFish etc. - these are for private key
encryption. It can do public key cryptography (RSA) and
digital signatures (RSA & DSA) too. However, this lib is
NOT SSL compatible. It has a documentation but you can
find examples on the net too. This may or may not be the
library you need. It depends on your needs. There are many
others:
ezPyCrypto, yawPyCrypto, PyOpenSSL
- please look for them on google, they are easy to find.
I choose PyCrypto because it can be compiled almost anywhere
and it is easy to use. But for example, PyOpenSSL can give you
full control over the OpenSSL library. However, you must be
familiar with OpenSSL to use it.
Well, none of those libraries are part of Python 2.3. I think this is
partly because it would not allow Python to be used in some
countries. (These can do strong encryption.) Conclusion: there
is no obvious replacement for you.
Cheers,
Laci 1.0
Jimmy Retzlaff wrote:
Robin Becker wrote:It seems that the rotor module is being deprecated in 2.3, but there doesn't seem to be an obvious alternative. I'm using it just for obfuscation. It seems we have ssl available in 2.3 for sockets, but there seems no obvious way to use that from python code. Is an alternative to rotor planned?If the goal is simple obfuscation (and not encryption) then the base64 module might work:
John J. Lee
> Robin wrote:
> > It seems that the rotor module is being deprecated in 2.3, but there
> > doesn't seem to be an obvious alternative. I'm using it just for
[...Dave has switched to AES]
> Since I'm not going to great lengths to hide the key, it works out to be about
> the same strength of encryption as rotor. ;-)
Quite. I don't understand why it's deprecated. We've known since the
fifties that the algorithm is broken, so wasn't it clear from the
start that this was for obfuscation, not strong encryption? Shouldn't
we just add a warning to the docs (if there's not one there already)??
John
Peter Hansen
If it's really for obfuscation, wouldn't a simpler algorithm be
sufficient, such as "XOR each byte with 0x5A" or something like that?
If the answer is "no, that's too easy to break", then it's not really
just for obfuscation, is it?
-Peter
Dave Brueck
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.
Rotor was nice because for very little costs in terms of CPU / coding nuisance
you could protect semi-sensitive data from nearly everyone. Sure it's
strength-per-bit-of-key-size doesn't stack up well against more modern
algorithms, but for the vast majority of users (including myself) data
encrypted with rotor or AES is, for all practical purposes, equally
untouchable. As a built-in data obfuscator, rotor filled about 99% of my
"security" needs.
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.. If Python could ship with
AES or 3DES and I'd use that, but right now adding an external encryption
package just to tell casual snoopers, "it's not worth your time to crack this
file - keep moving" seems so over the top.
-Dave
Peter Hansen
>
> Rotor was nice because for very little costs in terms of CPU / coding nuisance
> you could protect semi-sensitive data from nearly everyone. Sure it's
> strength-per-bit-of-key-size doesn't stack up well against more modern
> algorithms
That's kind of the heart of the matter right there: just how good _is_
rotor, compared to modern algorithms? Can anyone describe it perhaps
in comparison with DES/3DES using a kind of "equivalent key size" estimate?
My guess is that it's so insecure that most people wouldn't really want
to use it if they knew how insecure it was, or they would actually decide
that something like XORing the data is actually adequate and stick with
that.
I suspect that those who want rotor actually want something stronger
than it really is, but could actually get by with something even weaker
than it is (though they don't believe that), and leaving it out of the
standard library isn't a real problem, just a perceived one.
I also suspect that statement will generate quite a bit of debate. :-)
-Peter
Paul Rubin
> Quite. I don't understand why it's deprecated. We've known since the
> fifties that the algorithm is broken, so wasn't it clear from the
> start that this was for obfuscation, not strong encryption? Shouldn't
> we just add a warning to the docs (if there's not one there already)??
No. Using weak cryptographic algorithms for obfuscation should itself
be deprecated. If there's a need to obfuscate something, that means
that somebody is trying to read it when you don't want them to, and
the correct countermeasure is real encryption, not obfuscation.
Aaron Watters
> the implementation looks very slow. I'd strongly advise against doing
> anything serious with it. If you want a pure-Python cipher, please try
>
> http://www.nightsong.com/phr/crypto/p3.py
Offense taken :(. Please explain (offline if you like).
It's okay to call my stuff awful, but I require a bit of
constructive criticism to go with it.
FWIW it was loosely inspired by RC4 and it seems to scramble
things up nicely. Regarding speed: for small blocks it should
be reasonably fast for a pure python module which doesn't
use any extension modules, and it is also suitable for conversion
into a very small self contained C function, which was the intent.
But yours is much faster of course, since it uses an extension module
for the critical loop. For larger blocks more than an order of
magnitude faster. This is the timing I get when I modify
your test function
% python p3.py
(yours)
plain p3: 1000 5 0.22000002861 sec = 22727.2697717 bytes/sec
plain p3: 1000 20 0.261000037193 sec = 76628.3415706 bytes/sec
plain p3: 1000 200 0.520999908447 sec = 383877.226766 bytes/sec
plain p3: 100 2000 0.300000071526 sec = 666666.507721 bytes/sec
(mine)
plain pulver: 1000 5 0.210000038147 sec = 23809.5194845 bytes/sec
plain pulver: 1000 20 0.680999994278 sec = 29368.5758708 bytes/sec
plain pulver: 1000 200 5.94900000095 sec = 33619.0956409 bytes/sec
plain pulver: 100 2000 5.76800000668 sec = 34674.0637601 bytes/sec
In a C implementation I think mine would be more than competitive,
however.
The two are not precisely comparable, I think, because as far as I can
tell you just encrypt a single string, whereas mine encrypts a sequence
of strings progressively, unless I'm missing something.
Obviously, I have something really important to do, otherwise I
wouldn't be procrastinating like this :(... Enough goofing off...
-- Aaron Watters
===
never eat anything bigger than your head. -kliban
Paul Rubin
> Rotor was nice because for very little costs in terms of CPU /
> coding nuisance you could protect semi-sensitive data from nearly
> everyone.
But given that your application is runnign in interpreted Python, any
speed difference between rotor and AES is likely to be insignificant
in practice. So you may as well use AES.
> Sure it's strength-per-bit-of-key-size doesn't stack up
> well against more modern algorithms, but for the vast majority of
> users (including myself) data encrypted with rotor or AES is, for
> all practical purposes, equally untouchable.
No, I don't believe that. If you want to break something encrypted
with rotor and you don't have the knowledge or inclination to do it
yourself, you can hire someone else to do it for you (possibly using
one of the automated tool suites that exist for breaking rotor-like
ciphers). Breaking rotor might be as difficult as synthesizing
heroin, but there's a heroin problem as long as there are a few
specialists who can make it, so that others who can't make it
themselves can buy it from the specialists instead. It's the same way
with weak cryptography of any sort.
> As a built-in data
> obfuscator, rotor filled about 99% of my "security" needs.
Is 99% really good enough? Would you ride in a car if you had a 1%
chance of a fatal crash every time you got behind the wheel? How many
users (i.e. potential attackers) does your (e.g.) web site have? Is
it really acceptable for your site to be secure against only 99% of
them? If you have 10,000 users, that would mean 100 of them can
successfully break your cipher. Me, I'll go for 100% or as close to
it as I can get, not 99%.
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..
Those laws (actually regulations) are still goofy and archaic, but
they've softened up to the point where it's now feasible to ship real
encryption with Python. It's being worked on.
If Python could ship with AES or 3DES and I'd use that, but right
now adding an external encryption package just to tell casual
snoopers, "it's not worth your time to crack this file - keep
moving" seems so over the top.
I've posted a pure-python module that's just a page or two of code,
that should provide much better security than rotor and runs fast
enough for most practical Python apps. I think it is ok as a stopgap
til Python gets real encryption.
Robin Becker
writes
to make use of the data then any key/algorithm etc has to be present
somewhere.
How should we obfuscate? Using a crypto function just increases the time
and effort that someone needs to get the plain text. Likewise using a C
extension makes it harder for the casual thief. The professional won't
be bothered.
The rotor module was small and speedy. In my case I'm sure that it makes
very little difference to use base64 and a xor or something similar.
When we really want data to be protected we're using one time passwords
assigned by a special server.
--
Robin Becker
Dave Brueck
> Dave Brueck wrote:
> >
> > Rotor was nice because for very little costs in terms of CPU / coding
nuisance
> > you could protect semi-sensitive data from nearly everyone. Sure it's
> > strength-per-bit-of-key-size doesn't stack up well against more modern
> > algorithms
>
> That's kind of the heart of the matter right there: just how good _is_
> rotor, compared to modern algorithms?
I disagree, I don't think that's the issue at all. Rotor is far, far weaker
than even DES, but both take far, far more effort to crack than practically
anyone is willing to put forth, and I don't tend to care about that 0.0001% of
the people who do want to invest the effort.
> My guess is that it's so insecure that most people wouldn't really want
> to use it if they knew how insecure it was, or they would actually decide
> that something like XORing the data is actually adequate and stick with
> that.
Maybe so, maybe not. Here's one counter data point: me. :) FWIW, rotor isn't
_that_ much more complicated that XORing your data, the main difference being
that the data you XOR it with changes after each byte. Probably the bulk of the
benefit of rotor is that it's present, documented, and maybe that it's in C so
it's fast.
If someone is trying to protect their data but haven't done enough of their
homework to know that rotor versus e.g. AES is incredibly weak, odds are they
aren't going to have a secure system *at all* anyway, no matter how strong
encryption library they use - they'll probably leave the key totally exposed or
some such mistake. If a person using it _doesn't_ know how insecure it is, then
even if you give them AES to make the front door impenetrable, most likely all
the windows will still be wide open.
> I suspect that those who want rotor actually want something stronger
> than it really is, but could actually get by with something even weaker
> than it is (though they don't believe that), and leaving it out of the
> standard library isn't a real problem, just a perceived one.
How's this: it would be really great to have a key-based data obfuscator (read:
weak encryptor) ship as a standard part of Python. I'll concede that if rotor
keeps somebody out, a simple data munge like XOR probably would too (although
you're getting a little closer to the point where hex editor-using crackers can
play whereas rotor requires a programmer cracker). The difference is that a
standard module like rotor hits the sweet spot in terms of diminishing returns
of effort vs security, so if you're going to settle for that level of security
and have it ship as a standard module, why _not_ just use rotor?
-Dave
Paul Rubin
> You're probably right, but given that the code itself has to unobfuscate
> to make use of the data then any key/algorithm etc has to be present
> somewhere.
The idea of cryptography now is to keep the data secure as long as the
key is secret. It's ok if the algorithm is known. If the key is known
too, all bets are off.
> How should we obfuscate? Using a crypto function just increases the time
> and effort that someone needs to get the plain text.
If you can keep the key secret and the cryptography is any good, there
should be no way for anyone to break the cryptography without the key.
Rotor fails in that criterion.
> Likewise using a C
> extension makes it harder for the casual thief. The professional won't
> be bothered.
I think you're underestimating the technical ability and determination
of amateurs on the internet. Look at all the virus writers out
there--who is paying them? Almost every day Microsoft has to release
a new critical security patch because of some weakness that got
exploited by a non-professional and caused users a lot of hassle. The
exploit usually isn't some technical breakthrough on the attacker's
part, but rather stems from an attitude problem at Microsoft, that
their products only have to be secure enough to make it "harder for
the casual thief" since "the professional won't be bothered". That is
precisely the wrong attitude to have, as we see every time Microsoft
announces that "as of today security is our #1 priority" and then goes
back to doing the same dumb stuff, and a few days later, yet another
virus brings everyone's work to a halt yet another time. If you're
going to use cryptography at all, use it as well as you can.
> The rotor module was small and speedy. In my case I'm sure that it makes
> very little difference to use base64 and a xor or something similar.
Using base64 or an xor should be even smaller and speedier than rotor,
so if that's your goal, the answer is still "use xor and get rid of
rotor". The only reason to use rotor instead of xor is you think xor
isn't secure enough. But if xor isn't secure enough, you should use
real cryptography, not rotor.
> When we really want data to be protected we're using one time passwords
> assigned by a special server.
If you really want data to be protected I hope whatever methods you're
using were designed or at least reviewed by someone who knows what
they're doing. That's not intended as a put-down toward you; there
are a lot of mistakes that get made over and over again, and it takes
some knowledge and experience to recognize them and not make them.
Using something like rotor is very frequently an example of such a mistake.
Aaron Watters
> Deprecation is a very serious matter. I love the Python language but
> I have questions about the deprecation decisions.
Yea, random changes can do a lot of damage. Examples
repr(string) went hex and broke a lot of stuff for interacting
with systems that matched the old octal representation
(pdf format for example). It's very hard to ferret out all
the places where someone assumed that chr(0)=="\000".
cgi.environ disappeared and broke every cgi script in the CD
ROM in my python book right after it hit the shelves. :(!
regex was used pervasively. Why not just provide a translator stub
rather than deprecate it (noting in the documentation that it's
slower)? More examples on request...
arrgh. Please don't break code for cosmetic reasons!
-- Aaron Watters
===
I can't do that, Dave.
Dave Brueck
> That's kind of the heart of the matter right there: just how good _is_
> rotor, compared to modern algorithms? Can anyone describe it perhaps
> in comparison with DES/3DES using a kind of "equivalent key size" estimate?
Just as a semi-off-topic followup, rotor-like algorithms still have some
situations that make them more attractive than modern algorithms. While rotor
_is_ much weaker on an "equivalent key size" basis, its computational
simplicity makes it feasible to use extremely large keys without additional CPU
costs, so that you can end up with a much _higher_ degree of security per CPU
cycle spent in encryption / decryption if there is a way for both sides to
agree on extremely large keys (and there are plenty of ways to do that).
For example, suppose you and I have a monthly face-to-face meeting, so we use
that as an opportunity to swap CDs of random data. It is feasible for us to use
_the entire CD_ as an encryption key (yay, a 6 billion bit key!) and, assuming
the data is sufficiently random, there is literally _no_ amount of computing
power that can crack a single intercepted message using a brute force approach
(because cracking part of the key doesn't yield you info on any other part of
the message until you have intercepted messages totalling several times the
length of the key).
Obviously you could use the face-to-face meeting to exchange a CD of AES keys
to use, but each intercepted message would, in theory, be open to a brute force
attack, unless every AES-bitKeyLength/8 bytes of the message were encrypted
with a new key from the CD, but it would be far more expensive
computationally - using "modern" encryption algorithms is just a trade off
because for many appications CPU cycles are an abundant resource. But there do
exist situations where you are CPU constrained, so it may be a good tradeoff
for e.g. an embedded device with limited CPU to use a rotor-like algorithm and
its own ROM as the key.
Also, with rotor errors in the key cause only localized damage in the data
stream, so if the application consuming the decrypted data can recover from a
small error rate, you can use some pretty crazy sources for your keys: with a
little work you could e.g. encrypt live telephone conversations with the
satellite video feed of CNN (with the telephony application running the feed
through a filter to reduce noise and extract a reliable subset of the feed and
then synchronizing off of, say, the closed caption data). If somebody knows
that you're using that as your key source then they can crack your message, but
otherwise an intercepted message is safe from brute force attacks.
(I'm not suggesting that we should be using rotor everywhere, just pointing
that it has some cool properties and isn't totally useless nowadays. :) )
-Dave
Paul Rubin
> > At first glance that function looks awful (no offense intended), and
> > the implementation looks very slow. I'd strongly advise against doing
> > anything serious with it. If you want a pure-Python cipher, please try
> >
> > http://www.nightsong.com/phr/crypto/p3.py
>
> Offense taken :(. Please explain (offline if you like).
> It's okay to call my stuff awful, but I require a bit of
> constructive criticism to go with it.
I don't want to spend time analyzing the algorithms when there are
already perfectly good ciphers available and it's better to just stick
with them. But without making any real attempt to figure out what
your cipher is doing, several things are immediately obvious:
1) There is no attempt to provide any randomness in the output. If
you encrypt the same plaintext twice with the same key, you get the
same ciphertext. That is a security failure in many applications.
2) What's more, the cipher is a one-character-at-a-time stream cipher
so if you encrypt two different plaintexts that begin with a common
prefix, it looks to me like the ciphertexts will also have a common
prefix, another security failure.
3) No authentication is provided. An attacker who intercepts a
ciphertext in transmission can change it and the decryption side
will have no idea that anything has happened. All kinds of real-world
systems have made that same mistake and suffered for it.
4) It's almost certain that the cipher is vulnerable to
related-key attacks (as RC4 is), and from the way the cipher
feedback works, it may be easy to spot related plaintexts
(not just common prefix) by looking at the ciphertext.
> FWIW it was loosely inspired by RC4 and it seems to scramble
> things up nicely.
Being loosely inspired by RC4 is unreassuring on several grounds.
First of all, RC4 was designed very carefully by a knowledgeable
cryptographer who did a lot of studies and statistical experiments on
RC4 variants before settling on RC4. Don't be fooled by RC4's
simplicity, since just about every attempt to tweak it has in fact
made it worse. If you want an RC4-like cipher, use RC4, not a
"loosely-inspired" home-cooked variant that hasn't withstood a lot of
cryptanalysis attempts.
Second, RC4 itself doesn't have such good properties. RC4 can only be
used securely if key selection and authentication are done properly,
which takes knowledge. Take a look at IEEE 802.11 WEP to see what
happens if you use RC4 improperly but still in a way a reasonable
non-stupid engineer might expect it to work. The
Fluhrer-Shamir-Mantin attack uses RC4's internal structure to break
WEP with a very limited amount of captured traffic. Since WEP is
deployed in millions of Wifi cards, corporations all over the place
are spewing secret data over their wireless networks where they can be
intercepted by any malicious cretin driving past their building with a
wifi-equipped laptop. WEP would be much more secure if it had used
AES instead of RC4.
Third, even if RC4 is used properly, there are distinguishing attacks
that can tell that the RC4 keystream is not random given a few
gigabytes (maybe a lot less). That itself can be a security failure
in some applications like encrypting a hard drive. RC4 really
shouldn't be used in new applications. Use AES instead.
> Regarding speed: for small blocks it should
> be reasonably fast for a pure python module which doesn't
> use any extension modules, and it is also suitable for conversion
> into a very small self contained C function, which was the intent.
>
> But yours is much faster of course, since it uses an extension module
> for the critical loop. For larger blocks more than an order of
> magnitude faster.
Coding either of those algorithms as a C function would be a big
mistake. Once you have a way to use C functions, it's better to use
AES. However, coding RC4 in pure Python should run about midway
between Pulverizer and p3 in speed.
> The two are not precisely comparable, I think, because as far as I can
> tell you just encrypt a single string, whereas mine encrypts a sequence
> of strings progressively, unless I'm missing something.
Yes correct, p3.py encrypts a single string like rotor does. Bryan
Olson did a reference implementation of an earlier version of p3, that
can be used for stream encryption. It's in this post:
http://groups.google.com/groups?selm=3CC7889D.2080002%40nowhere.org
Paul Rubin
> repr(string) went hex and broke a lot of stuff for interacting
> with systems that matched the old octal representation
> (pdf format for example). It's very hard to ferret out all
> the places where someone assumed that chr(0)=="\000".
repr really shouldn't be used that way though.
Paul Rubin
> Just as a semi-off-topic followup, rotor-like algorithms still have
> some situations that make them more attractive than modern
> algorithms. While rotor _is_ much weaker on an "equivalent key size"
> basis, its computational simplicity makes it feasible to use
> extremely large keys without additional CPU costs, so that you can
> end up with a much _higher_ degree of security per CPU cycle spent
> in encryption / decryption if there is a way for both sides to agree
> on extremely large keys (and there are plenty of ways to do that).
But the internal state of the rotor system has fixed size, no matter
how long the key is. In the case of the Python rotor module, that
size is 10 bytes, though of course there are much better attacks than
brute force search.
> For example, suppose you and I have a monthly face-to-face meeting,
> so we use that as an opportunity to swap CDs of random data. It is
> feasible for us to use _the entire CD_ as an encryption key (yay, a
> 6 billion bit key!) and, assuming the data is sufficiently random,
> there is literally _no_ amount of computing power that can crack a
> single intercepted message using a brute force approach (because
> cracking part of the key doesn't yield you info on any other part of
> the message until you have intercepted messages totalling several
> times the length of the key).
In that case we can just use the random cd as an additive one-time pad
and have no need for rotor algorithms. Note that we won't get any
authentication either way.
> Obviously you could use the face-to-face meeting to exchange a CD of
> AES keys to use, but each intercepted message would, in theory, be
> open to a brute force attack,
But in fact the likelihood of such an attack is much lower than the
likelihood of the CD itself getting intercepted by an attacker. Really,
this stuff gets rehashed on sci.crypt almost every week, it gets boring
after a while.
> But there do exist
> situations where you are CPU constrained, so it may be a good
> tradeoff for e.g. an embedded device with limited CPU to use a
> rotor-like algorithm and its own ROM as the key.
There are much better algorithms than rotor even for tiny cpu's.
Skipjack, for example, needs only about 3 bytes of scratch ram on an
8-bit cpu while any reasonable rotor cipher needs far more than that.
> Also, with rotor errors in the key cause only localized damage in
> the data stream,
Several of the standard block cipher chaining modes have the same property.
> so if the application consuming the decrypted data can recover from
> a small error rate, you can use some pretty crazy sources for your
> keys: with a little work you could e.g. encrypt live telephone
> conversations with the satellite video feed of CNN (with the
> telephony application running the feed through a filter to reduce
> noise and extract a reliable subset of the feed and then
> synchronizing off of, say, the closed caption data). If somebody
> knows that you're using that as your key source then they can crack
> your message, but otherwise an intercepted message is safe from
> brute force attacks.
But that's silly, you have to assume that your attacker knows what
methods and key sources you're using (Kerchoff principle). If you
can't securely exchange a shared secret key beforehand, the solution
is to use a public-key key agreement algorithm with locally generated
random data at each end, not crazy crap like digitizing a CNN feed.
> (I'm not suggesting that we should be using rotor everywhere, just
> pointing that it has some cool properties and isn't totally useless
> nowadays. :) )
But it really is totally useless nowadays, unless you want an insecure
system.
Paul Rubin
> That's kind of the heart of the matter right there: just how good _is_
> rotor, compared to modern algorithms? Can anyone describe it perhaps
> in comparison with DES/3DES using a kind of "equivalent key size" estimate?
That's not really a sensible question to ask. The WW2 Enigma machine,
for example, had much more key space than DES/3DES, but it was
vulnerable to cryptanalytic attacks that were far more effective than
brute force. Rotor itself looks to have been written quite
carelessly. It's basically a bunch of linear-congruential PRNG's
which are notoriously weak as ciphers.
> My guess is that it's so insecure that most people wouldn't really want
> to use it if they knew how insecure it was, or they would actually decide
> that something like XORing the data is actually adequate and stick with
> that.
It's best to go with that assumption even if breaking rotor is
actually a bit harder.
> I suspect that those who want rotor actually want something stronger
> than it really is, but could actually get by with something even weaker
> than it is (though they don't believe that), and leaving it out of the
> standard library isn't a real problem, just a perceived one.
Actually it's the other way, lots of people think they can get by with
rotor or with something weaker, when they really need something
stronger. Leaving rotor IN the standard library is a real problem.
Paul Rubin
> > My guess is that it's so insecure that most people wouldn't really want
> > to use it if they knew how insecure it was, or they would actually decide
> > that something like XORing the data is actually adequate and stick with
> > that.
>
> Maybe so, maybe not. Here's one counter data point: me. :)
May I ask what application you want to use rotor for?
> If someone is trying to protect their data but haven't done enough
> of their homework to know that rotor versus e.g. AES is incredibly
> weak, odds are they aren't going to have a secure system *at all*
> anyway, no matter how strong encryption library they use - they'll
> probably leave the key totally exposed or some such mistake. If a
> person using it _doesn't_ know how insecure it is, then even if you
> give them AES to make the front door impenetrable, most likely all
> the windows will still be wide open.
Having spent a lot of time as the in-house crypto maintainer on a
security-intensive commercial development project, I can confirm that
there's much truth to what you're saying. That's why a built-in
library encryption function intended for non-specialists has to free
the application programmer as much as possible from the likelihood of
using a cipher the wrong way. Of course there's infinite ways the
application itself can screw something up, but the library implementer
can't much help that.
> How's this: it would be really great to have a key-based data
> obfuscator (read: weak encryptor) ship as a standard part of
> Python.
But that's precisely what rotor is, and IMO it does a bad job.
> I'll concede that if rotor keeps somebody out, a simple data munge
> like XOR probably would too (although you're getting a little closer
> to the point where hex editor-using crackers can play whereas rotor
> requires a programmer cracker). The difference is that a standard
> module like rotor hits the sweet spot in terms of diminishing
> returns of effort vs security, so if you're going to settle for that
> level of security and have it ship as a standard module, why _not_
> just use rotor?
If you're going to ship something as a standard module, it should try
to provide real security. It was a mistake to have ever shipped rotor.
Lulu of the Lotus-Eaters
|FWIW it was loosely inspired by RC4 and it seems to scramble
|things up nicely.
For cryptography, "inspired by" is a very bad standard. Very small
changes to algorithms can hugely lessen their strength. Moreover,
"seeming to scramble" is almost worthless--good algorithms need
literally years of serious study by very good cryptographers before even
minimal assurances of strength can be made.
Yours, Lulu...
--
mertz@ | The specter of free information is haunting the `Net! All the
gnosis | powers of IP- and crypto-tyranny have entered into an unholy
.cx | alliance...ideas have nothing to lose but their chains. Unite
| against "intellectual property" and anti-privacy regimes!
-------------------------------------------------------------------------
A.M. Kuchling
Dave Brueck <da...@pythonapocrypha.com> wrote:
> 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.. If Python could ship with
s/of the U.S./of various countries/ and you'd be correct. See the
python-dev thread starting at
http://mail.python.org/pipermail/python-dev/2003-April/034957.html . I
originally deprecated rotor with the goal of getting an AES module into 2.3.
The objection was then raised that having crypto produces legal hassles in
various countries, so the idea of an AES module was shot down but rotor was
deprecated anyway as one step to removing it.
(Arguably this is inconsistent with distributing SSL support in binary
versions of Python. No one has suggested removing SSL support from the
source code, but MAL did suggest removing it from the default Windows
installer.)
--amk
Paul Rubin
> http://mail.python.org/pipermail/python-dev/2003-April/034957.html . I
> originally deprecated rotor with the goal of getting an AES module into 2.3.
> The objection was then raised that having crypto produces legal hassles in
> various countries, so the idea of an AES module was shot down but rotor was
> deprecated anyway as one step to removing it.
This is unfortunate, especially since it's so simple to implement
strong cryptography with the already-existing modules like SHA.
Maybe there needs to be a crypto and a non-crypto distribution.
That's what was done for both Netscape and MSIE for years, under the
old US export restrictions. For Python nowadays, it will be easier,
since the problem isn't exporting from Python's central distribution
point, but rather with importing into certain repressive regimes. So
it's not required for the distribution point (as long as it's in a
free country) to try to enforce any restrictions on downloading
cryptography, as Netscape and Microsoft formerly had to do. It can
just provide two links (crypto and non-crypto) and let the user
download whatever they want.
I also continue to urge inclusion of a secure random number generator
in the Python library, per the technical discussions we've already
had about how to do that. I don't think that would count as cryptography.
Aaron Watters
> aa...@reportlab.com (Aaron Watters) writes:>
> I don't want to spend time analyzing the algorithms when there are
> already perfectly good ciphers available and it's better to just stick
> with them.
Yes, I agree. Thanks for taking the time.
> 1) There is no attempt to provide any randomness in the output...
> 2) What's more, the cipher is a one-character-at-a-time stream cipher
> so if you encrypt two different plaintexts that begin with a common
> prefix, it looks to me like the ciphertexts will also have a common
> prefix, another security failure.
> 3) No authentication is provided....
> 4) It's almost certain that the cipher is vulnerable to
> related-key attacks...
Since the input is fed into the encryption mechanism adding random
garbage bytes to the input every so often in a predictable manner will
address 1,2,4. Adding any sort of checksum will address 3. This is
the kind criticism I enjoy! thanks again.
> Being loosely inspired by RC4 is unreassuring on several grounds...
I agree completely with the rest. -- Aaron Watters
===
The cup holder on my computer is broken.
Peter Hansen
>
> Peter Hansen <pe...@engcorp.com> writes:
> > I suspect that those who want rotor actually want something stronger
> > than it really is, but could actually get by with something even weaker
> > than it is (though they don't believe that), and leaving it out of the
> > standard library isn't a real problem, just a perceived one.
>
> Actually it's the other way, lots of people think they can get by with
> rotor or with something weaker, when they really need something
> stronger. Leaving rotor IN the standard library is a real problem.
Maybe it's both. :-) Obviously at least some of the people here
don't think they can get by with less, and yet it seems increasingly
likely that they actually could, given that all that has been asked for
is "obfuscation". (If the goal is to prevent accidental or casual
observation from revealing information, almost anything (like an XOR)
should be good enough. Anything more needs something that shouldn't
be called "obfuscation", IMHO.)
I guess the point is then that rotor is in a dangerous middle ground,
where it looks better than it really is. Either way it's the wrong
thing for someone to use, whether they want strong or weak encryption.
-Peter
Paul Rubin
Yes, that's a good summary.
John J. Lee
> "Dave Brueck" <da...@pythonapocrypha.com> writes:
[...]
> > How's this: it would be really great to have a key-based data
> > obfuscator (read: weak encryptor) ship as a standard part of
> > Python.
>
> But that's precisely what rotor is, and IMO it does a bad job.
That's not a "but", that's an "and". It does a bad job of strong
encryption, it does the job for obfuscation. It *is* a step up
Anybody can write a program to decrypt XORed data in a line of code
(maybe emacs has a keystroke for it), decryption of rotor encryption
requires the extra effort to find a library to crack it, or to know
enough to write your own. Whether that small point justified its
initial inclusion is certainly debatable, but now it's in there, it
seems like a mistake to deprecate it.
John
John J. Lee
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 ;-). Second, if you have
to have the key around anyway (true for some applications), it really
doesn't matter how secure the algorithm is.
Obfuscation is a perfectly sane thing to want to do, and rotor is just
a way of making reading data mildly more of a PITA than XOR. I don't
think even emacs has a decrypt-rotored-text function <0.5 wink>.
John
Jorge Godoy
> That's not a "but", that's an "and". It does a bad job of strong
> encryption, it does the job for obfuscation. It *is* a step up
> Anybody can write a program to decrypt XORed data in a line of code
> (maybe emacs has a keystroke for it), decryption of rotor encryption
> requires the extra effort to find a library to crack it, or to know
> enough to write your own. Whether that small point justified its
> initial inclusion is certainly debatable, but now it's in there, it
> seems like a mistake to deprecate it.
Sorry for my ignorance, but how do you get to decrypt the code to run?
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.
See you,
--
Godoy. <go...@ieee.org>
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
--
ARTHUR: Ford, you're turning into a penguin, stop it.
-- The Hitch-Hikers Guide to the Galaxy, Episode 2
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
>>
>> If it's really for obfuscation, wouldn't a simpler algorithm be
>> sufficient, such as "XOR each byte with 0x5A" or something like that?
>>
>> If the answer is "no, that's too easy to break", then it's not really
>> just for obfuscation, is it?
>
>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
>Robin Becker <ro...@jessikat.fsnet.co.uk> writes:
>> It seems that the rotor module is being deprecated in 2.3, but there
>> doesn't seem to be an obvious alternative. I'm using it just for
>> obfuscation. It seems we have ssl available in 2.3 for sockets, but
>> there seems no obvious way to use that from python code.
>>
>> Is an alternative to rotor planned?
>
>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
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
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
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
> j...@pobox.com (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
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
> j...@pobox.com (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.
> > 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.
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
> > > Second, if you have to have the key around anyway (true for some
> > > applications), it really doesn't matter how secure the algorithm is.
> 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
--
# sigmask || 0.2 || 20030107 || public domain || feed this to a python
print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?')
Paul Rubin
> > 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.
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.
Jorge Godoy
> Jorge Godoy <go...@ieee.org> writes:
>
>> j...@pobox.com (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?
--
Godoy. <go...@ieee.org>
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...??
> > 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.
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
>Paul Rubin <http://phr...@NOSPAM.invalid> writes:
>
>> j...@pobox.com (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.
>
>
>> > 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.
>
>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.
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').
>John
--
Magnus Lie Hetland "In this house we obey the laws of
http://hetland.org thermodynamics!" Homer Simpson
John J. Lee
> In article <87smkit...@pobox.com>, John J. Lee wrote:
[...]
> How about using rot13? At least it's build-in ;)
Built in to emacs, too, unfortunately (though I've admitted all this
probably doesn't matter, see my earlier post).
> Wasn't the Adobe encryption for eBooks (which Sklyarov was imprisoned
> for "cracking") something close to rot13?
[...]
That was XOR, I think.
John