Does rotor follow a cross-language encryption algorithm ?
kragen at canonical.org
Mon Nov 26 02:33:32 CET 2001
shriek at gmx.co.uk (Stephen) writes:
> Lance Ellinghouse (who wrote rotormodule.c) also writes that the
> output "is considered BINARY data" so a CRLF, LF or CR are not
> possible output.
This seems like a dubious interpretation of 'binary data' to me, and
testing reveals that you are wrong; here's an abbreviated session:
Python 2.1.1 (#1, Oct 24 2001, 10:59:24)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import rotor
>>> x = rotor.newrotor("x", 1)
>>> x.encrypt("x" * 100)
>>> longstring = x.encrypt("x" * 2048)
> Reading his comments, this does not seem to be a "standard"
> rotor. However, having the C and Java equivalents will suffice
> at the moment. Makes me wonder why more people don't use the
> rotor when they need "just enough" encryption without going
> the full hog with PKI.
Triple-DES or Blowfish are much better choices if you need encryption
but don't want to hassle with PKI. They will keep your data secret,
and the rotor module is vulnerable to cryptanalysis.
> Just to clear up my own understanding, is it fair to say that
> a "built-in" module can be defined as one that is included in
> the core Python distributed, and is written in C as oppopsed
> to Python, but which still needs to be imported before use ?
A module that is written in C is called an 'extension module'.
A built-in module is one that is linked into the Python executable
rather than stored as a DLL; you can turn any extension module into a
The modules that are included in the core Python distribution are the
All modules need to be imported before use, except for __builtins__.
More information about the Python-list