Home Original page

rotor alternative?

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