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

[Dave Brueck]

Re: rotor alternative?

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

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]

Re: rotor alternative?

Robin Becker wrote:
[color=blue]
> 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.[/color]

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]

Re: rotor alternative?

In article <3fba4965$0$587 01$e4fe514c@new s.xs4all.nl>, Irmen de Jong
<irmen@-NOSPAM-REMOVETHIS-xs4all.nl> writes[color=blue]
>Robin Becker wrote:
>[color=green]
>> 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.[/color]
>
>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
>[/color]
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

[Paul Rubin]

Re: rotor alternative?

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

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]

Re: rotor alternative?

Robin Becker <robin@jessikat .fsnet.co.uk> wrote in message news:<b2BHKIAKJ iu$Ew0g@jessika t.fsnet.co.uk>. ..[color=blue]
> Is an alternative to rotor planned?[/color]

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]

Re: rotor alternative?

aaron@reportlab .com (Aaron Watters) writes:[color=blue][color=green]
> > Is an alternative to rotor planned?[/color][/color]
[color=blue]
> 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.[/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

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]

Re: rotor alternative?

In article <7x8ymd4hwf.fsf @ruckus.brouhah a.com>, Paul Rubin <http@?.cx>
writes[color=blue]
>Robin Becker <robin@jessikat .fsnet.co.uk> writes:[color=green]
>> 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?[/color]
>
>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[/color]
Thanks for the kind offer, but I'm getting permission errors with that
URL.
--
Robin Becker

[Will Stuyvesant]

Re: rotor alternative?

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

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!

[dman@dman13.dyndns.org]

Re: rotor alternative?

On 18 Nov 2003 13:42:40 -0800, Will Stuyvesant wrote:
[...][color=blue]
> and then all the tweaking makes me feel like deinstalling 2.3. and
> installing 1.5.2 on the laptop too.[/color]

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: dman@dman13.dyn dns.org

[Paul Rubin]

Re: rotor alternative?

Robin Becker <robin@jessikat .fsnet.co.uk> writes:[color=blue][color=green]
> > http://www.nightsong.com/phr/crypto/p3.py[/color]
> Thanks for the kind offer, but I'm getting permission errors with that
> URL.[/color]

Oops, try again now.

[Paul Rubin]

Re: rotor alternative?

hwlgw@hotmail.c om (Will Stuyvesant) writes:[color=blue]
> 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.[/color]

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]

Re: rotor alternative?

Paul Rubin[color=blue]
> Unfortunately deprecation happens so often because crap makes it into
> the library that should have been done right to begin with.[/color]

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
dalke@dalkescie ntific.com

[John J. Lee]

Re: rotor alternative?

"Dave Brueck" <dave@pythonapo crypha.com> writes:
[color=blue]
> Robin wrote:[color=green]
> > 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][/color]
[...Dave has switched to AES][color=blue]
> 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. ;-)[/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)??


John

[Peter Hansen]

Re: rotor alternative?

"John J. Lee" wrote:[color=blue]
>
> "Dave Brueck" <dave@pythonapo crypha.com> writes:
>[color=green]
> > Robin wrote:[color=darkred]
> > > 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][/color]
> [...Dave has switched to AES][color=green]
> > 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. ;-)[/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?

-Peter