Fast MAC algorithms?

[Darren J Moffat]

Nicolas Williams wrote:
> On Thu, Jul 23, 2009 at 05:34:13PM +1200, Peter Gutmann wrote:
>> "mheyman at gmail.com" <mheyman at gmail.com> writes:
>>> 2) If you throw TCP processing in there, unless you are consistantly going to
>>> have packets on the order of at least 1000 bytes, your crypto algorithm is
>>> almost _irrelevant_.
>>> [...]
>>> for a Linux 2.2.14 kernel, remember, this was 10 years ago.
>> Could the lack of support for TCP offload in Linux have skewed these figures
>> somewhat?  It could be that the caveat for the results isn't so much "this was
>> done ten years ago" as "this was done with a TCP stack that ignores the
>> hardware's advanced capabilities".
> 
> How much NIC hardware does both, ESP/AH and TCP offload?  My guess: not
> much.  A shame, that.
> 
> Once you've gotten a packet off the NIC to do ESP/AH processing, you've
> lost the opportunity to use TOE.

The SCA-4000 card from Sun provided the ESP/AH IPsec offload as well as 
a general purpose crypto acceleration.   The ESP/AH wasn't able to deal 
with all cases (if I remember correctly some fragmented packet cases) so 
we still had to "punt" to software IPsec and use the hardware crypto on 
the same card to do the decrypt/mac.   It turned out that in almost all 
cases we got better over all throughput of the machine (and ironically 
lower CPU utilisation as well) using the card as a hardware crypto 
accelerator rather than an IPsec offloader.   This card didn't do TOE 
though because Solaris/OpenSolaris doesn't do TOE because we don't need 
it (and thus have no interfaces for it).   This was 3DES, MD5, SHA1 era 
IPsec.

So when its successor came along, the SCA-6000 (adding AES), the NIC was 
dropped.

-- 
Darren J Moffat

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com