rotor alternative?

Robin Becker robin at jessikat.fsnet.co.uk
Wed Nov 19 12:47:19 EST 2003


In article <7xad6sb7cd.fsf at ruckus.brouhaha.com>, Paul Rubin <http@?.cx>
writes
>jjl at 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




More information about the Python-list mailing list