[pycrypto] Why I would be glad to find a plenty of algorithms in pycrypto

[Dwayne C. Litzenberger]

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

     The truth: The cipher's job is to destroy mathematics as quickly as
     possible.

     -- http://www.enrupt.com/index.php/2008/09/05/strength_in_complexity

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

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

>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
     [6] 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[1], 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 [2] it looks like the submissions required a lot of 
last-minute changes in order to avoid newly-discovered attacks.

[1] https://www.cosic.esat.kuleuven.be/nessie/deliverables/decision-final.pdf
[2] http://cr.yp.to/streamciphers/broken-20080330.pdf

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

I don't care where you're from unless you're submitting code: 
http://www.pycrypto.org/submission-requirements/

-- 
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
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.dlitz.net/pipermail/pycrypto/attachments/20081109/2bc25454/attachment.pgp