rotor alternative?

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

 

[Dave Brueck]

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

 

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

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.

 

[Paul Rubin]

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

 

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

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.

 

[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. 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[/QUOTE]
Thanks for the kind offer, but I'm getting permission errors with that
URL.

 

[Will Stuyvesant]

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

 

[dman]

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: (e-mail address removed)

 

[Paul Rubin]

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]

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
(e-mail address removed)

 

[John J. Lee]

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]

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

 

[Dave Brueck]

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

 

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

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

 

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