On Wed, Jul 22, 2009 at 06:49:34AM +0200, Dan Kaminsky wrote:
> Operationally, HMAC-SHA-256 is the gold standard.  There's wonky stuff all
> over the place -- Bernstein's polyaes work appeals to me -- but I wouldn't
> really ship anything but HMAC-SHA-256 at present time.

Oh, I agree in general.  As far as new apps and standards work I'd make
HMAC-SHA-256 or AES, in an AEAD cipher mode, REQUIRED to implement and
the default.

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

For example, many people use arcfour in SSHv2 over AES because arcfour
is faster than AES.  The SSHv2 AES-based ciphers ought to be RTI and
default choice, IMO, but that doesn't mean arcfour should not be

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, put in the ash heap of
history.  But there is a place for weak-but-fast algos, as long as
they're not too weak.  Any weak-but-fast algos we might have now tend to
be old algos that turned out to be weaker than designed to be, and new
ones tend to be slower because resistance against new attacks tends to
require more computation.  I realized this would make my question seem a
bit pointless, but hoped I might get a surprising answer :(


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to