rotor alternative?

Discussion in 'Python' started by Robin Becker, Nov 18, 2003.

  1. Robin Becker

    Robin Becker Guest

    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?
    --
    Robin Becker
    Robin Becker, Nov 18, 2003
    #1
    1. Advertising

  2. Robin Becker

    Dave Brueck Guest

    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
    > 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?


    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
    Dave Brueck, Nov 18, 2003
    #2
    1. Advertising

  3. 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.


    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
    Irmen de Jong, Nov 18, 2003
    #3
  4. Robin Becker

    Robin Becker Guest

    In article <3fba4965$0$58701$4all.nl>, Irmen de Jong
    <> writes
    >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.

    >
    >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
    >

    Yes we do something like that already for state holding gloop in web
    pages. There're implementations of rc4 in python, but having something
    in the standard distro eases maintenance.
    --
    Robin Becker
    Robin Becker, Nov 18, 2003
    #4
  5. Robin Becker

    Paul Rubin Guest

    Robin Becker <> 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
    Paul Rubin, Nov 18, 2003
    #5
  6. Robin Becker <> wrote in message news:<b2BHKIAKJiu$>...
    > 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
    Aaron Watters, Nov 18, 2003
    #6
  7. Robin Becker

    Paul Rubin Guest

    (Aaron Watters) writes:
    > > 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.
    Paul Rubin, Nov 18, 2003
    #7
  8. Robin Becker

    Robin Becker Guest

    In article <>, Paul Rubin <http@?.cx>
    writes
    >Robin Becker <> 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

    Thanks for the kind offer, but I'm getting permission errors with that
    URL.
    --
    Robin Becker
    Robin Becker, Nov 18, 2003
    #8
  9. > [Robin Becker]
    > 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...


    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!
    Will Stuyvesant, Nov 18, 2003
    #9
  10. Robin Becker

    Guest

    On 18 Nov 2003 13:42:40 -0800, Will Stuyvesant wrote:
    [...]
    > 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:
    , Nov 18, 2003
    #10
  11. Robin Becker

    Paul Rubin Guest

    Paul Rubin, Nov 18, 2003
    #11
  12. Robin Becker

    Paul Rubin Guest

    (Will Stuyvesant) writes:
    > 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.
    Paul Rubin, Nov 18, 2003
    #12
  13. Robin Becker

    Andrew Dalke Guest

    Paul Rubin
    > 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
    Andrew Dalke, Nov 18, 2003
    #13
  14. Robin Becker

    John J. Lee Guest

    "Dave Brueck" <> writes:

    > 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
    John J. Lee, Nov 19, 2003
    #14
  15. Robin Becker

    Peter Hansen Guest

    "John J. Lee" wrote:
    >
    > "Dave Brueck" <> writes:
    >
    > > 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)??


    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
    Peter Hansen, Nov 19, 2003
    #15
  16. Robin Becker

    Dave Brueck Guest

    Peter Hansen wrote:
    > "John J. Lee" wrote:
    > >
    > > "Dave Brueck" <> writes:
    > >
    > > > 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)??

    >
    > 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.

    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
    Dave Brueck, Nov 19, 2003
    #16
  17. Robin Becker

    Peter Hansen Guest

    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? 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
    Peter Hansen, Nov 19, 2003
    #17
  18. Robin Becker

    Paul Rubin Guest

    (John J. Lee) writes:
    > 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.
    Paul Rubin, Nov 19, 2003
    #18
  19. Paul Rubin <http://> wrote in message news:<>...
    > (Aaron Watters) writes:
    > > > Is an alternative to rotor planned?
    > > > http://athos.rutgers.edu/~aaron/python/pulver.py>

    > 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.

    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
    Aaron Watters, Nov 19, 2003
    #19
  20. Robin Becker

    Paul Rubin Guest

    "Dave Brueck" <> 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.
    Paul Rubin, Nov 19, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Metin Yerlikaya

    an alternative method to do divided clocks

    Metin Yerlikaya, Feb 15, 2005, in forum: VHDL
    Replies:
    4
    Views:
    638
    John_H
    Feb 15, 2005
  2. Reed L. O'Brien

    rotor replacement

    Reed L. O'Brien, Jan 19, 2005, in forum: Python
    Replies:
    102
    Views:
    3,770
    Nick Craig-Wood
    Jan 31, 2005
  3. Murphy Wong

    How to enable rotor in python 2.4.2?

    Murphy Wong, Jan 24, 2006, in forum: Python
    Replies:
    3
    Views:
    311
    Paul Rubin
    Jan 24, 2006
  4. Paul Rubin

    Missing rotor module

    Paul Rubin, Jul 25, 2006, in forum: Python
    Replies:
    5
    Views:
    325
    rony steelandt
    Jul 26, 2006
  5. Protoman

    Rotor class reverses wierdly

    Protoman, Dec 30, 2006, in forum: C++
    Replies:
    1
    Views:
    443
    Jim Langston
    Dec 30, 2006
Loading...

Share This Page