rotor alternative?

[Dave Brueck]

Re: rotor alternative?

Peter Hansen wrote:[color=blue]
> "John J. Lee" wrote:[color=green]
> >
> > "Dave Brueck" <dave@pythonapo crypha.com> writes:
> >[color=darkred]
> > > 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[/color]
> > [...Dave has switched to AES][color=darkred]
> > > Since I'm not going to great lengths to hide the key, it works out to be[/color][/color][/color]
about[color=blue][color=green][color=darkred]
> > > the same strength of encryption as rotor. ;-)[/color]
> >
> > 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)??[/color]
>
> 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?[/color]

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]

Re: rotor alternative?

Dave Brueck wrote:[color=blue]
>
> 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[/color]

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]

Re: rotor alternative?

jjl@pobox.com (John J. Lee) writes:[color=blue]
> 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)??[/color]

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]

Re: rotor alternative?

Paul Rubin <http://phr.cx@NOSPAM.i nvalid> wrote in message news:<7xwu9x32j 2.fsf@ruckus.br ouhaha.com>...[color=blue]
> aaron@reportlab .com (Aaron Watters) writes:[color=green][color=darkred]
> > > Is an alternative to rotor planned?
> > > http://athos.rutgers.e du/~aaron/python/pulver.py>[/color][/color]
> 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[/color]

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]

Re: rotor alternative?

"Dave Brueck" <dave@pythonapo crypha.com> writes:[color=blue]
> Rotor was nice because for very little costs in terms of CPU /
> coding nuisance you could protect semi-sensitive data from nearly
> everyone.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> As a built-in data
> obfuscator, rotor filled about 99% of my "security" needs.[/color]

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]

Re: rotor alternative?

In article <7xad6sb7cd.fsf @ruckus.brouhah a.com>, Paul Rubin <http@?.cx>
writes[color=blue]
>jjl@pobox.co m (John J. Lee) writes:[color=green]
>> 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)??[/color]
>
>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.[/color]
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.

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]

Re: rotor alternative?

Peter wrote:[color=blue]
> Dave Brueck wrote:[color=green]
> >
> > Rotor was nice because for very little costs in terms of CPU / coding[/color][/color]
nuisance[color=blue][color=green]
> > 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[/color]
>
> That's kind of the heart of the matter right there: just how good _is_
> rotor, compared to modern algorithms?[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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]

Re: rotor alternative?

Robin Becker <robin@jessikat .fsnet.co.uk> writes:[color=blue]
> 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.[/color]

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.
[color=blue]
> How should we obfuscate? Using a crypto function just increases the time
> and effort that someone needs to get the plain text.[/color]

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.
[color=blue]
> Likewise using a C
> extension makes it harder for the casual thief. The professional won't
> be bothered.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> When we really want data to be protected we're using one time passwords
> assigned by a special server.[/color]

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 gotchas Re: rotor alternative?

hwlgw@hotmail.c om (Will Stuyvesant) wrote in message news:<cb035744. 0311181342.3187 96ba@posting.go ogle.com>...[color=blue]
> Deprecation is a very serious matter. I love the Python language but
> I have questions about the deprecation decisions.[/color]

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]

Re: rotor alternative?

Peter wrote:[color=blue]
> 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?[/color]

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]

Re: rotor alternative?

aaron@reportlab .com (Aaron Watters) writes:[color=blue][color=green]
> > 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[/color]
>
> 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.[/color]

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.
[color=blue]
> FWIW it was loosely inspired by RC4 and it seems to scramble
> things up nicely.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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]

Re: deprecation gotchas Re: rotor alternative?

aaron@reportlab .com (Aaron Watters) writes:[color=blue]
> 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".[/color]

repr really shouldn't be used that way though.

[Paul Rubin]

Re: rotor alternative?

"Dave Brueck" <dave@pythonapo crypha.com> writes:[color=blue]
> 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).[/color]

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.
[color=blue]
> 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).[/color]

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.
[color=blue]
> 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,[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> Also, with rotor errors in the key cause only localized damage in
> the data stream,[/color]

Several of the standard block cipher chaining modes have the same property.
[color=blue]
> 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.[/color]

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.
[color=blue]
> (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. :) )[/color]

But it really is totally useless nowadays, unless you want an insecure
system.

[Paul Rubin]

Re: rotor alternative?

Peter Hansen <peter@engcorp. com> writes:[color=blue]
> 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?[/color]

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.
[color=blue]
> 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.[/color]

It's best to go with that assumption even if breaking rotor is
actually a bit harder.
[color=blue]
> 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.[/color]

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]

Re: rotor alternative?

"Dave Brueck" <dave@pythonapo crypha.com> writes:[color=blue][color=green]
> > 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.[/color]
>
> Maybe so, maybe not. Here's one counter data point: me. :)[/color]

May I ask what application you want to use rotor for?
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

But that's precisely what rotor is, and IMO it does a bad job.
[color=blue]
> 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?[/color]

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.