Home Original page

rotor alternative?

Paul Rubin http
Wed Nov 19 14:46:30 EST 2003 
"Dave Brueck" <dave at pythonapocrypha.com> writes:
> > 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.
More information about the Python-list mailing list