--------------------------------------------------
From: "Nicolas Williams" <nicolas.willi...@sun.com>
Sent: Tuesday, July 21, 2009 10:43 PM
Subject: Re: Fast MAC algorithms?

But that's not what I'm looking for here.  I'm looking for the fastest
MACs, with extreme security considerations (e.g., "warning, warning!
must rekey every 10 minutes")

There's a reason everyone is ignoring that "requirement" rekeying in any modern system is more or less trivial. As an example take AES, rekeying every 10 minutes will have a throughput of 99.999% of the original, there will be bigger differences depending on whether or not you move the mouse.

being possibly OK, depending on just how
extreme -- the sort of algorithm that one would not make REQUIRED to
implement, but which nonetheless one might use in some environments
simply because it's fast.

I would NEVER recommend it, let me repeat that I would NEVER recommend it, but Panama is a higher performing design, IIRC about 8x the speed of the good recommendations, but DON'T USE PANAMA. You wanted a bad recommendation, Panama is a bad recommendation.

If you want a good recommendation that is faster, Poly1305-AES. You'll get some extra speed without compromising security.

For example, many people use arcfour in SSHv2 over AES because arcfour
is faster than AES.

I would argue that they use it because they are stupid. ARCFOUR should have been retired well over a decade ago, it is weak, it meets no reasonable security requirements, and in most situations it is not actually faster due to the cache thrashing it frequently induces due to the large key expansion.

In the crypto world one never designs weak-but-fast algorithms on
purpose, only strong-and-preferably-fast ones.  And when an algorithm is
successfully attacked it's usually deprecated,

The general preference is to permanently retire them. The better algorithms are generally at least as fast, that's part of the problem you seem to be having, you're not understanding that secure is not the same word as slow, in fact everyone has worked very hard in making the secure options at least as fast as the insecure.

new
ones tend to be slower because resistance against new attacks tends to
require more computation.

New ones tend to be faster than the old.
New ones are designed with more recent CPUs in mind.
New ones are designed with the best available knowledge on how to build security
New ones are simpler by design
New ones make use of everything that has been learned.

I realized this would make my question seem a
bit pointless, but hoped I might get a surprising answer :(

I think the answer surprised you more than you expected. You had hoped for some long forgotten extremely fast algorithm, what you've instead learned is that the long forgotten algorithms were not only forgotten because of security, but that they were eclipsed on speed as well.

I've moved this to the end to finish on the point
The SSHv2 AES-based ciphers ought to be RTI and
default choice, IMO, but that doesn't mean arcfour should not be
available.

I very strongly disagree. One of the fundamental assumptions of creating secure protocols is that sooner or later someone will bet their life on your work. This isn't an idle overstatement, instead it is an observation. How many people bet their life and lost because Twitter couldn't protect their information in Iran?
How many people bet their life's savings on SSL/TLS?
How many people trusted various options with their complete medical history?
How many people bet their life or freedom on the ability of PGP to protect them?

People bet their life on security all the time, it is a part of the job to make sure that bet is safe. Joe
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to