473,327 Members | 2,025 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,327 software developers and data experts.

rotor alternative?

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
Jul 18 '05 #1
46 3971
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
Jul 18 '05 #2
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

Jul 18 '05 #3
In article <3f***********************@news.xs4all.nl>, Irmen de Jong
<irmen@-NOSPAM-REMOVETHIS-xs4all.nl> 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
Jul 18 '05 #4
Robin Becker <ro***@jessikat.fsnet.co.uk> 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
Jul 18 '05 #5
Robin Becker <ro***@jessikat.fsnet.co.uk> wrote in message news:<b2**************@jessikat.fsnet.co.uk>...
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
Jul 18 '05 #6
aa***@reportlab.com (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.
Jul 18 '05 #7
In article <7x************@ruckus.brouhaha.com>, Paul Rubin <http@?.cx>
writes
Robin Becker <ro***@jessikat.fsnet.co.uk> 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
Jul 18 '05 #8
> [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!
Jul 18 '05 #9
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: dm**@dman13.dyndns.org
Jul 18 '05 #10
Robin Becker <ro***@jessikat.fsnet.co.uk> writes:
http://www.nightsong.com/phr/crypto/p3.py

Thanks for the kind offer, but I'm getting permission errors with that
URL.


Oops, try again now.
Jul 18 '05 #11
hw***@hotmail.com (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.
Jul 18 '05 #12
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
da***@dalkescientific.com
Jul 18 '05 #13
"Dave Brueck" <da**@pythonapocrypha.com> 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
Jul 18 '05 #14
"John J. Lee" wrote:

"Dave Brueck" <da**@pythonapocrypha.com> 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
Jul 18 '05 #15
Peter Hansen wrote:
"John J. Lee" wrote:

"Dave Brueck" <da**@pythonapocrypha.com> 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
Jul 18 '05 #16
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
Jul 18 '05 #17
jj*@pobox.com (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.
Jul 18 '05 #18
Paul Rubin <http://ph****@NOSPAM.invalid> wrote in message news:<7x************@ruckus.brouhaha.com>...
aa***@reportlab.com (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
Jul 18 '05 #19
"Dave Brueck" <da**@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.
Jul 18 '05 #20
In article <7x************@ruckus.brouhaha.com>, Paul Rubin <http@?.cx>
writes
jj*@pobox.com (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.

You're probably right, but given that the code itself has to unobfuscate
to make use of the data then any key/algorithm etc has to be present
somewhere.

How should we obfuscate? Using a crypto function just increases the time
and effort that someone needs to get the plain text. Likewise using a C
extension makes it harder for the casual thief. The professional won't
be bothered.

The rotor module was small and speedy. In my case I'm sure that it makes
very little difference to use base64 and a xor or something similar.
When we really want data to be protected we're using one time passwords
assigned by a special server.
--
Robin Becker
Jul 18 '05 #21
Peter wrote:
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?


I disagree, I don't think that's the issue at all. Rotor is far, far weaker
than even DES, but both take far, far more effort to crack than practically
anyone is willing to put forth, and I don't tend to care about that 0.0001% of
the people who do want to invest the effort.
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. :) FWIW, rotor isn't
_that_ much more complicated that XORing your data, the main difference being
that the data you XOR it with changes after each byte. Probably the bulk of the
benefit of rotor is that it's present, documented, and maybe that it's in C so
it's fast.

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


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

-Dave
Jul 18 '05 #22
Robin Becker <ro***@jessikat.fsnet.co.uk> writes:
You're probably right, but given that the code itself has to unobfuscate
to make use of the data then any key/algorithm etc has to be present
somewhere.
The idea of cryptography now is to keep the data secure as long as the
key is secret. It's ok if the algorithm is known. If the key is known
too, all bets are off.
How should we obfuscate? Using a crypto function just increases the time
and effort that someone needs to get the plain text.
If you can keep the key secret and the cryptography is any good, there
should be no way for anyone to break the cryptography without the key.
Rotor fails in that criterion.
Likewise using a C
extension makes it harder for the casual thief. The professional won't
be bothered.
I think you're underestimating the technical ability and determination
of amateurs on the internet. Look at all the virus writers out
there--who is paying them? Almost every day Microsoft has to release
a new critical security patch because of some weakness that got
exploited by a non-professional and caused users a lot of hassle. The
exploit usually isn't some technical breakthrough on the attacker's
part, but rather stems from an attitude problem at Microsoft, that
their products only have to be secure enough to make it "harder for
the casual thief" since "the professional won't be bothered". That is
precisely the wrong attitude to have, as we see every time Microsoft
announces that "as of today security is our #1 priority" and then goes
back to doing the same dumb stuff, and a few days later, yet another
virus brings everyone's work to a halt yet another time. If you're
going to use cryptography at all, use it as well as you can.
The rotor module was small and speedy. In my case I'm sure that it makes
very little difference to use base64 and a xor or something similar.
Using base64 or an xor should be even smaller and speedier than rotor,
so if that's your goal, the answer is still "use xor and get rid of
rotor". The only reason to use rotor instead of xor is you think xor
isn't secure enough. But if xor isn't secure enough, you should use
real cryptography, not rotor.
When we really want data to be protected we're using one time passwords
assigned by a special server.


If you really want data to be protected I hope whatever methods you're
using were designed or at least reviewed by someone who knows what
they're doing. That's not intended as a put-down toward you; there
are a lot of mistakes that get made over and over again, and it takes
some knowledge and experience to recognize them and not make them.
Using something like rotor is very frequently an example of such a mistake.
Jul 18 '05 #23
hw***@hotmail.com (Will Stuyvesant) wrote in message news:<cb**************************@posting.google. com>...
Deprecation is a very serious matter. I love the Python language but
I have questions about the deprecation decisions.


Yea, random changes can do a lot of damage. Examples
repr(string) went hex and broke a lot of stuff for interacting
with systems that matched the old octal representation
(pdf format for example). It's very hard to ferret out all
the places where someone assumed that chr(0)=="\000".
cgi.environ disappeared and broke every cgi script in the CD
ROM in my python book right after it hit the shelves. :(!
regex was used pervasively. Why not just provide a translator stub
rather than deprecate it (noting in the documentation that it's
slower)? More examples on request...
arrgh. Please don't break code for cosmetic reasons!
-- Aaron Watters
===
I can't do that, Dave.
Jul 18 '05 #24
Peter wrote:
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?


Just as a semi-off-topic followup, rotor-like algorithms still have some
situations that make them more attractive than modern algorithms. While rotor
_is_ much weaker on an "equivalent key size" basis, its computational
simplicity makes it feasible to use extremely large keys without additional CPU
costs, so that you can end up with a much _higher_ degree of security per CPU
cycle spent in encryption / decryption if there is a way for both sides to
agree on extremely large keys (and there are plenty of ways to do that).

For example, suppose you and I have a monthly face-to-face meeting, so we use
that as an opportunity to swap CDs of random data. It is feasible for us to use
_the entire CD_ as an encryption key (yay, a 6 billion bit key!) and, assuming
the data is sufficiently random, there is literally _no_ amount of computing
power that can crack a single intercepted message using a brute force approach
(because cracking part of the key doesn't yield you info on any other part of
the message until you have intercepted messages totalling several times the
length of the key).

Obviously you could use the face-to-face meeting to exchange a CD of AES keys
to use, but each intercepted message would, in theory, be open to a brute force
attack, unless every AES-bitKeyLength/8 bytes of the message were encrypted
with a new key from the CD, but it would be far more expensive
computationally - using "modern" encryption algorithms is just a trade off
because for many appications CPU cycles are an abundant resource. But there do
exist situations where you are CPU constrained, so it may be a good tradeoff
for e.g. an embedded device with limited CPU to use a rotor-like algorithm and
its own ROM as the key.

Also, with rotor errors in the key cause only localized damage in the data
stream, so if the application consuming the decrypted data can recover from a
small error rate, you can use some pretty crazy sources for your keys: with a
little work you could e.g. encrypt live telephone conversations with the
satellite video feed of CNN (with the telephony application running the feed
through a filter to reduce noise and extract a reliable subset of the feed and
then synchronizing off of, say, the closed caption data). If somebody knows
that you're using that as your key source then they can crack your message, but
otherwise an intercepted message is safe from brute force attacks.

(I'm not suggesting that we should be using rotor everywhere, just pointing
that it has some cool properties and isn't totally useless nowadays. :) )

-Dave
Jul 18 '05 #25
aa***@reportlab.com (Aaron Watters) writes:
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.


I don't want to spend time analyzing the algorithms when there are
already perfectly good ciphers available and it's better to just stick
with them. But without making any real attempt to figure out what
your cipher is doing, several things are immediately obvious:

1) There is no attempt to provide any randomness in the output. If
you encrypt the same plaintext twice with the same key, you get the
same ciphertext. That is a security failure in many applications.

2) What's more, the cipher is a one-character-at-a-time stream cipher
so if you encrypt two different plaintexts that begin with a common
prefix, it looks to me like the ciphertexts will also have a common
prefix, another security failure.

3) No authentication is provided. An attacker who intercepts a
ciphertext in transmission can change it and the decryption side
will have no idea that anything has happened. All kinds of real-world
systems have made that same mistake and suffered for it.

4) It's almost certain that the cipher is vulnerable to
related-key attacks (as RC4 is), and from the way the cipher
feedback works, it may be easy to spot related plaintexts
(not just common prefix) by looking at the ciphertext.
FWIW it was loosely inspired by RC4 and it seems to scramble
things up nicely.
Being loosely inspired by RC4 is unreassuring on several grounds.

First of all, RC4 was designed very carefully by a knowledgeable
cryptographer who did a lot of studies and statistical experiments on
RC4 variants before settling on RC4. Don't be fooled by RC4's
simplicity, since just about every attempt to tweak it has in fact
made it worse. If you want an RC4-like cipher, use RC4, not a
"loosely-inspired" home-cooked variant that hasn't withstood a lot of
cryptanalysis attempts.

Second, RC4 itself doesn't have such good properties. RC4 can only be
used securely if key selection and authentication are done properly,
which takes knowledge. Take a look at IEEE 802.11 WEP to see what
happens if you use RC4 improperly but still in a way a reasonable
non-stupid engineer might expect it to work. The
Fluhrer-Shamir-Mantin attack uses RC4's internal structure to break
WEP with a very limited amount of captured traffic. Since WEP is
deployed in millions of Wifi cards, corporations all over the place
are spewing secret data over their wireless networks where they can be
intercepted by any malicious cretin driving past their building with a
wifi-equipped laptop. WEP would be much more secure if it had used
AES instead of RC4.

Third, even if RC4 is used properly, there are distinguishing attacks
that can tell that the RC4 keystream is not random given a few
gigabytes (maybe a lot less). That itself can be a security failure
in some applications like encrypting a hard drive. RC4 really
shouldn't be used in new applications. Use AES instead.
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.
Coding either of those algorithms as a C function would be a big
mistake. Once you have a way to use C functions, it's better to use
AES. However, coding RC4 in pure Python should run about midway
between Pulverizer and p3 in speed.
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.


Yes correct, p3.py encrypts a single string like rotor does. Bryan
Olson did a reference implementation of an earlier version of p3, that
can be used for stream encryption. It's in this post:

http://groups.google.com/groups?selm...%40nowhere.org
Jul 18 '05 #26
aa***@reportlab.com (Aaron Watters) writes:
repr(string) went hex and broke a lot of stuff for interacting
with systems that matched the old octal representation
(pdf format for example). It's very hard to ferret out all
the places where someone assumed that chr(0)=="\000".


repr really shouldn't be used that way though.
Jul 18 '05 #27
"Dave Brueck" <da**@pythonapocrypha.com> writes:
Just as a semi-off-topic followup, rotor-like algorithms still have
some situations that make them more attractive than modern
algorithms. While rotor _is_ much weaker on an "equivalent key size"
basis, its computational simplicity makes it feasible to use
extremely large keys without additional CPU costs, so that you can
end up with a much _higher_ degree of security per CPU cycle spent
in encryption / decryption if there is a way for both sides to agree
on extremely large keys (and there are plenty of ways to do that).
But the internal state of the rotor system has fixed size, no matter
how long the key is. In the case of the Python rotor module, that
size is 10 bytes, though of course there are much better attacks than
brute force search.
For example, suppose you and I have a monthly face-to-face meeting,
so we use that as an opportunity to swap CDs of random data. It is
feasible for us to use _the entire CD_ as an encryption key (yay, a
6 billion bit key!) and, assuming the data is sufficiently random,
there is literally _no_ amount of computing power that can crack a
single intercepted message using a brute force approach (because
cracking part of the key doesn't yield you info on any other part of
the message until you have intercepted messages totalling several
times the length of the key).
In that case we can just use the random cd as an additive one-time pad
and have no need for rotor algorithms. Note that we won't get any
authentication either way.
Obviously you could use the face-to-face meeting to exchange a CD of
AES keys to use, but each intercepted message would, in theory, be
open to a brute force attack,
But in fact the likelihood of such an attack is much lower than the
likelihood of the CD itself getting intercepted by an attacker. Really,
this stuff gets rehashed on sci.crypt almost every week, it gets boring
after a while.
But there do exist
situations where you are CPU constrained, so it may be a good
tradeoff for e.g. an embedded device with limited CPU to use a
rotor-like algorithm and its own ROM as the key.
There are much better algorithms than rotor even for tiny cpu's.
Skipjack, for example, needs only about 3 bytes of scratch ram on an
8-bit cpu while any reasonable rotor cipher needs far more than that.
Also, with rotor errors in the key cause only localized damage in
the data stream,
Several of the standard block cipher chaining modes have the same property.
so if the application consuming the decrypted data can recover from
a small error rate, you can use some pretty crazy sources for your
keys: with a little work you could e.g. encrypt live telephone
conversations with the satellite video feed of CNN (with the
telephony application running the feed through a filter to reduce
noise and extract a reliable subset of the feed and then
synchronizing off of, say, the closed caption data). If somebody
knows that you're using that as your key source then they can crack
your message, but otherwise an intercepted message is safe from
brute force attacks.
But that's silly, you have to assume that your attacker knows what
methods and key sources you're using (Kerchoff principle). If you
can't securely exchange a shared secret key beforehand, the solution
is to use a public-key key agreement algorithm with locally generated
random data at each end, not crazy crap like digitizing a CNN feed.
(I'm not suggesting that we should be using rotor everywhere, just
pointing that it has some cool properties and isn't totally useless
nowadays. :) )


But it really is totally useless nowadays, unless you want an insecure
system.
Jul 18 '05 #28
Peter Hansen <pe***@engcorp.com> writes:
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?
That's not really a sensible question to ask. The WW2 Enigma machine,
for example, had much more key space than DES/3DES, but it was
vulnerable to cryptanalytic attacks that were far more effective than
brute force. Rotor itself looks to have been written quite
carelessly. It's basically a bunch of linear-congruential PRNG's
which are notoriously weak as ciphers.
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.
It's best to go with that assumption even if breaking rotor is
actually a bit harder.
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.


Actually it's the other way, lots of people think they can get by with
rotor or with something weaker, when they really need something
stronger. Leaving rotor IN the standard library is a real problem.
Jul 18 '05 #29
"Dave Brueck" <da**@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.
Jul 18 '05 #30
aa***@reportlab.com (Aaron Watters) wrote previously:
|FWIW it was loosely inspired by RC4 and it seems to scramble
|things up nicely.

For cryptography, "inspired by" is a very bad standard. Very small
changes to algorithms can hugely lessen their strength. Moreover,
"seeming to scramble" is almost worthless--good algorithms need
literally years of serious study by very good cryptographers before even
minimal assurances of strength can be made.

Yours, Lulu...

--
mertz@ | The specter of free information is haunting the `Net! All the
gnosis | powers of IP- and crypto-tyranny have entered into an unholy
..cx | alliance...ideas have nothing to lose but their chains. Unite
| against "intellectual property" and anti-privacy regimes!
-------------------------------------------------------------------------
Jul 18 '05 #31
On Wed, 19 Nov 2003 09:09:54 -0700,
Dave Brueck <da**@pythonapocrypha.com> wrote:
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


s/of the U.S./of various countries/ and you'd be correct. See the
python-dev thread starting at
http://mail.python.org/pipermail/pyt...il/034957.html . I
originally deprecated rotor with the goal of getting an AES module into 2.3.
The objection was then raised that having crypto produces legal hassles in
various countries, so the idea of an AES module was shot down but rotor was
deprecated anyway as one step to removing it.

(Arguably this is inconsistent with distributing SSL support in binary
versions of Python. No one has suggested removing SSL support from the
source code, but MAL did suggest removing it from the default Windows
installer.)

--amk
Jul 18 '05 #32
"A.M. Kuchling" <am*@amk.ca> writes:
http://mail.python.org/pipermail/pyt...il/034957.html . I
originally deprecated rotor with the goal of getting an AES module into 2.3.
The objection was then raised that having crypto produces legal hassles in
various countries, so the idea of an AES module was shot down but rotor was
deprecated anyway as one step to removing it.


This is unfortunate, especially since it's so simple to implement
strong cryptography with the already-existing modules like SHA.

Maybe there needs to be a crypto and a non-crypto distribution.
That's what was done for both Netscape and MSIE for years, under the
old US export restrictions. For Python nowadays, it will be easier,
since the problem isn't exporting from Python's central distribution
point, but rather with importing into certain repressive regimes. So
it's not required for the distribution point (as long as it's in a
free country) to try to enforce any restrictions on downloading
cryptography, as Netscape and Microsoft formerly had to do. It can
just provide two links (crypto and non-crypto) and let the user
download whatever they want.

I also continue to urge inclusion of a secure random number generator
in the Python library, per the technical discussions we've already
had about how to do that. I don't think that would count as cryptography.
Jul 18 '05 #33
On Wed, 19 Nov 2003 11:38:21 -0700, Dave Brueck wrote:
Just as a semi-off-topic followup, rotor-like algorithms still have some
situations that make them more attractive than modern algorithms. While rotor
_is_ much weaker on an "equivalent key size" basis,
It isn't. The WWII Enigma machine with 3 rotors and 10 plugboard
pairings has a "pure brute force" strength of ~88.8 bits (~98.4 bits
for the 4 rotor version) -- that's more than 4 billion times stronger
than DES :-)

It has a major statistical weakness, though, in that no letter can
encode to itself.
its computational
simplicity makes it feasible to use extremely large keys without additional CPU
costs, so that you can end up with a much _higher_ degree of security per CPU
cycle spent in encryption / decryption if there is a way for both sides to
agree on extremely large keys (and there are plenty of ways to do that).
I'm not sure how the rotor module works, but AFAIK it's just some
variant on the basic Enigma theme -- in which case, the real key
length is fixed (e.g., in real Enigma, the selection of rotors
installed, their initial positions, and the plugboard settings), so
whatever it does with the key you pass in to generate the internal
state, you can't increase the strength by using a longer key.

I had a quick look at rotormodule.c -- the internal key consists of 5
16 bit values (and it looks like they're not independent of one another)
so it wouldn't be worth using a key longer than about 60 characters
even if it was a "strong" cipher.
For example, suppose you and I have a monthly face-to-face meeting, so we use
that as an opportunity to swap CDs of random data. It is feasible for us to use
_the entire CD_ as an encryption key (yay, a 6 billion bit key!) and, assuming
the data is sufficiently random, there is literally _no_ amount of computing
If you were going to do that, you should just use XOR against the data
on the CD. Using rotor in this situation can only make an attack
possible.
Also, with rotor errors in the key cause only localized damage in the data
stream, so if the application consuming the decrypted data can recover from a
small error rate, you can use some pretty crazy sources for your keys: with a
little work you could e.g. encrypt live telephone conversations with the
satellite video feed of CNN (with the telephony application running the feed
through a filter to reduce noise and extract a reliable subset of the feed and
then synchronizing off of, say, the closed caption data). If somebody knows
that you're using that as your key source then they can crack your message, but
otherwise an intercepted message is safe from brute force attacks.


Want to bet?

--
You don't have to agree with me; you can be wrong if you want.

(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))
Jul 18 '05 #34
Paul Rubin <http://ph****@NOSPAM.invalid> wrote in message news:<7x************@ruckus.brouhaha.com>...
aa***@reportlab.com (Aaron Watters) writes:>
I don't want to spend time analyzing the algorithms when there are
already perfectly good ciphers available and it's better to just stick
with them.
Yes, I agree. Thanks for taking the time.
1) There is no attempt to provide any randomness in the output...
2) What's more, the cipher is a one-character-at-a-time stream cipher
so if you encrypt two different plaintexts that begin with a common
prefix, it looks to me like the ciphertexts will also have a common
prefix, another security failure.
3) No authentication is provided....
4) It's almost certain that the cipher is vulnerable to
related-key attacks...
Since the input is fed into the encryption mechanism adding random
garbage bytes to the input every so often in a predictable manner will
address 1,2,4. Adding any sort of checksum will address 3. This is
the kind criticism I enjoy! thanks again.
Being loosely inspired by RC4 is unreassuring on several grounds...


I agree completely with the rest. -- Aaron Watters
===
The cup holder on my computer is broken.
Jul 18 '05 #35
Paul Rubin wrote:

Peter Hansen <pe***@engcorp.com> writes:
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.


Actually it's the other way, lots of people think they can get by with
rotor or with something weaker, when they really need something
stronger. Leaving rotor IN the standard library is a real problem.


Maybe it's both. :-) Obviously at least some of the people here
don't think they can get by with less, and yet it seems increasingly
likely that they actually could, given that all that has been asked for
is "obfuscation". (If the goal is to prevent accidental or casual
observation from revealing information, almost anything (like an XOR)
should be good enough. Anything more needs something that shouldn't
be called "obfuscation", IMHO.)

I guess the point is then that rotor is in a dangerous middle ground,
where it looks better than it really is. Either way it's the wrong
thing for someone to use, whether they want strong or weak encryption.

-Peter
Jul 18 '05 #36
Peter Hansen <pe***@engcorp.com> writes:
I guess the point is then that rotor is in a dangerous middle ground,
where it looks better than it really is. Either way it's the wrong
thing for someone to use, whether they want strong or weak encryption.


Yes, that's a good summary.
Jul 18 '05 #37
Paul Rubin <http://ph****@NOSPAM.invalid> writes:
"Dave Brueck" <da**@pythonapocrypha.com> writes:

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


That's not a "but", that's an "and". It does a bad job of strong
encryption, it does the job for obfuscation. It *is* a step up
Anybody can write a program to decrypt XORed data in a line of code
(maybe emacs has a keystroke for it), decryption of rotor encryption
requires the extra effort to find a library to crack it, or to know
enough to write your own. Whether that small point justified its
initial inclusion is certainly debatable, but now it's in there, it
seems like a mistake to deprecate it.
John
Jul 18 '05 #38
Paul Rubin <http://ph****@NOSPAM.invalid> writes:
jj*@pobox.com (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.


First, not necessarily, if you're in a country that has legislation
controlling strong encryption (and yes, we know "that should be
fixed", but sadly we don't have that power ;-). Second, if you have
to have the key around anyway (true for some applications), it really
doesn't matter how secure the algorithm is.

Obfuscation is a perfectly sane thing to want to do, and rotor is just
a way of making reading data mildly more of a PITA than XOR. I don't
think even emacs has a decrypt-rotored-text function <0.5 wink>.
John
Jul 18 '05 #39
jj*@pobox.com (John J. Lee) writes:
That's not a "but", that's an "and". It does a bad job of strong
encryption, it does the job for obfuscation. It *is* a step up
Anybody can write a program to decrypt XORed data in a line of code
(maybe emacs has a keystroke for it), decryption of rotor encryption
requires the extra effort to find a library to crack it, or to know
enough to write your own. Whether that small point justified its
initial inclusion is certainly debatable, but now it's in there, it
seems like a mistake to deprecate it.


Sorry for my ignorance, but how do you get to decrypt the code to run?
Use any kind of wrapper? Is such a wrapper written in C? Do you store
the key inside such a wrapper?

The same problem would happen with AES or any other crypt method:
where and how to store the key in a way that's easy for the user.
See you,
--
Godoy. <go***@ieee.org>
Jul 18 '05 #40
jj*@pobox.com (John J. Lee) writes:
the act of obtaining such a program is itself a psychological
barrier to decryption: you can't fool yourself about what you're
doing.


Not just a psychological barrier, but a legal one, if your aim is to
provide a possible basis for future litigation.

I worked at a software company whose products required the customer to
enter a software key as part of the install process. The key
generation algorithm was rather simple, and it would have been easy to
generate bogus keys. But the very act of entering a bogus key provides
a grounds for legal action. You can't just say "I thought I could
install as many as I wanted," since the terms for acquiring a key were
explicit.

I would assume a similar principle would apply to people who
circumvent obfuscation in order to poach software.

I do understand that lawyers and engineering best practices often part
ways early in the game, I'm just trying to explain a non-technical
reason for obfuscation (as engineers, our constraints often have
nothing to do with actual engineering -- sad but true).

Nick

--
# sigmask || 0.2 || 20030107 || public domain || feed this to a python
print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?')
Jul 18 '05 #41
Nick Vargish <na*******@bandersnatch.org> writes:
the act of obtaining such a program is itself a psychological
barrier to decryption: you can't fool yourself about what you're
doing.


Not just a psychological barrier, but a legal one, if your aim is to
provide a possible basis for future litigation.


Rotor is not needed to provide that barrier. You can do the same thing
with a simple xor against the key.
Jul 18 '05 #42
Paul Rubin <http://ph****@NOSPAM.invalid> writes:
Rotor is not needed to provide that barrier. You can do the same thing
with a simple xor against the key.


Since rotor is there, though, people have used it.

It's also a nice homage to one of the defining periods of "modern"
cyptography. But that doesn't mean it needs to be in the standard
library.

Nick

--
# sigmask || 0.2 || 20030107 || public domain || feed this to a python
print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?')
Jul 18 '05 #43
jj*@pobox.com (John J. Lee) writes:
Jorge Godoy <go***@ieee.org> writes:
jj*@pobox.com (John J. Lee) writes:

[...]
Sorry for my ignorance, but how do you get to decrypt the code to run?


What code?


Weren't you obfuscating Python code? Or did I read it all wrong?

--
Godoy. <go***@ieee.org>
Jul 18 '05 #44
Paul Rubin <http://ph****@NOSPAM.invalid> writes:
[...]
Rotor should never have been shipped with Python. If some application

[...]

Was it *really* intended as an encryption tool? I'm amazed. Hasn't
anyone on python-dev heard of Bletchley Park...??

However, if you're right in suspecting that anti-crypto legistlation
is always (or even usually) applied without exception or waiver even
to broken algorithms, then I agree it's pointless -- after all, AES
would serve just the same purpose!


I'm going to have to catch up with the python-dev traffic about the
legislation issue but I think it's silly to leave crypto out of the
library because some regime somewhere doesn't permit its use. Apache
2.0 now ships with SSL by default, and I don't think its popularity or
useability has been impaired.


Another point, of course (I say of course, but it only just occurred
to me ;-), is that you have to find the key in the first place (even
though it's sitting on your disk somewhere, in the scenario we were
discussing). I guess that's just an easy brute force search through
the appropriate disk files to find the key, but even so, probably
enough of a barrier to make it the "bottleneck of inconvenience",
hence to make rotor no better or worse than XOR as an obfuscation
tool.
John
Jul 18 '05 #45
In article <87************@pobox.com>, John J. Lee wrote:
Paul Rubin <http://ph****@NOSPAM.invalid> writes:
jj*@pobox.com (John J. Lee) writes:[...]
I don't know of any country that controls strong encryption and
doesn't control weak encryption. Back before the US export controls

[...]

That's interesting.

> Second, if you have
> to have the key around anyway (true for some applications), it really
> doesn't matter how secure the algorithm is.


I'm not sure what you're getting at here. The normal use of
cryptography is to transmit or store data that can be intercepted by
an attacker. Obviously you don't transmit or store the key with the
data.


Oh, do we have to go around this loop again?

You can if your aim is _obfuscation_: simply to place a minimal
barrier in front of people so they have to do something more than XOR
some data.

[snip]

How about using rot13? At least it's build-in ;)

Wasn't the Adobe encryption for eBooks (which Sklyarov was imprisoned
for "cracking") something close to rot13?

http://zork.net/pipermail/free-sklya...ly/001045.html

Not exactly clever stuff, but quite funny :]

Hooray for 'Nqbor'.decode('rot13').
John


--
Magnus Lie Hetland "In this house we obey the laws of
http://hetland.org thermodynamics!" Homer Simpson
Jul 18 '05 #46
ml*@furu.idi.ntnu.no (Magnus Lie Hetland) writes:
In article <87************@pobox.com>, John J. Lee wrote: [...] How about using rot13? At least it's build-in ;)
Built in to emacs, too, unfortunately (though I've admitted all this
probably doesn't matter, see my earlier post).

Wasn't the Adobe encryption for eBooks (which Sklyarov was imprisoned
for "cracking") something close to rot13?

[...]

That was XOR, I think.
John
Jul 18 '05 #47

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

92
by: Reed L. O'Brien | last post by:
I see rotor was removed for 2.4 and the docs say use an AES module provided separately... Is there a standard module that works alike or an AES module that works alike but with better encryption?...
5
by: rony steelandt | last post by:
I'm in the midle of porting a python 1.5 application to 2.4 I just discovered that the rotor encryption module isn't part anymore of the 2.4 distribution. Is there a way to add this module to...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.