Fast MAC algorithms?

[Joseph Ashwood]

--------------------------------------------------
From: "Nicolas Williams" <Nicolas.Williams at 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 majordomo at metzdowd.com