[pycrypto] Why I would be glad to find a plenty of algorithms in pycrypto
Dwayne C. Litzenberger
dlitz at dlitz.net
Sun Nov 9 17:13:38 CST 2008
On Sun, Nov 09, 2008 at 05:01:15PM -0430, Stefan Spoettl wrote:
>ARC4 is fast.
>ARC4 is easy to implement.
>ARC4 is beautiful (my personal Mona Lisa of cryptography)
On the topic of "beautiful", you should read this, by Sean O'Neil:
Most cryptographers are either mathematicians or come from a very
strong mathematical background [including myself] and we love
beautiful mathematical structures. We like magic squares, we like
fancy patterns, we like cool mathematical properties such as
guaranteed long periods, etc. etc. etc. It is extremely hard to
resist the temptation to include an unnecessarily complex but
mathematically pretty component in your design that other
mathematicians might admire. We do tend to forget that the beautiful
mathematics of it tend to be responsible for the algebraic structures
that may turn out to be exploitable to mount successful attacks. We
get attached to our cute little babies and to their beautiful
The truth: The cipher's job is to destroy mathematics as quickly as
>Some years ago this "arguments" appeared to me as "sufficient" to bank on
>it during a development of a secure protocol, which is intending to beat
>the SSL performance (in a concluded VPN).
What is a "concluded VPN"? A search on Google returns nothing useful.
>As you know some "uncultured and barefaced" cryptoanalysts have painted a
>fat nipple directly is the face of my Mona Lisa. It could be adopted that
>this people will terminate to do their sacrileges. Futheron this is not
>But what should one do if a development depends on an algorithm. The only
>way around this edge is to bank on a library that offers equivalent
"Fat nipple"? "Sacrilege"? "Equivalent compensation"? What is this, a
religious strip show with a bit of Judge Judy mixed in?
Enough with the vague rhetoric. Please make your arguments directly,
clearly, and in English, or don't make them at all. Although I speak
English as a native language, others on this list don't, and if I can't
understand you, they surely won't.
Also, please address my responses to your last email, especially my point
about keeping the amount of hand-written C code to a minimum.
Furthermore, please actually use the "Reply" function of your mailer (the
In-Reply-To header should be set correctly). By breaking up the threads,
you are making this conversation harder to follow in the mailing list
>By the way: In my point of view a block cipher that is running in CFB, OFB
>or CTR mode could never be an equivalent compensation for a stream cipher
>(if you want speed).
Quoting D. J. Bernstein's paper, which I expect you have read by now:
I don't like waiting for my computer. I really don't like waiting for
someone else's computer. A large part of my research is devoted to
improving system performance at various levels. (For example, my paper
 is titled "Curve25519: new Diffie-Hellman speed records.") But I
find security much more important than speed. We need invulnerable
software systems, and we need them today, even if they are ten times
slower than our current systems. Tomorrow we can start working on
making them faster.
"To this very day, idiot software managers measure 'programmer
productivity' in terms of 'lines of code produced,' whereas the notion
of 'lines of code spent' is much more appropriate."
—Dijkstra in [9, page EWD962–4]
If speed is more important to you than security, then I suggest you write
all your code in C, and use one of the many widely-available C crypto
libraries. I've heard Crypto++ is quite good, and several people have
already mentioned pycryptopp.
My resources are extremely limited, and I choose to devote them toward
security, not speed.
>Dwayne's statement that stream ciphers are still in an "experimental"
>state sounds in my (european) ears like a simple misapprehension.
Believe it. All of the six stream ciphers submitted to NESSIE (2000-2003)
were broken, the recently-published cube attack decimated LFSR-based
stream ciphers, and I'm sure somebody else can comment on the status of
eSTREAM, but from  it looks like the submissions required a lot of
last-minute changes in order to avoid newly-discovered attacks.
>For some reasons the Europeans are never leaving the "experimental" state
>of exactly nothing. Well, that's a part of our weakness but even a part of
I don't care where you're from unless you're submitting code:
Dwayne C. Litzenberger <dlitz at dlitz.net>
Key-signing key - 19E1 1FE8 B3CF F273 ED17 4A24 928C EC13 39C2 5CF7
Annual key (2008) - 4B2A FD82 FC7D 9E38 38D9 179F 1C11 B877 E780 4B45
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: Digital signature
Url : http://lists.dlitz.net/pipermail/pycrypto/attachments/20081109/2bc25454/attachment.pgp
More information about the pycrypto