Fast MAC algorithms?

[mheyman at gmail.com]

On Thu, Jul 23, 2009 at 1:34 AM, Peter Gutmann<pgut001 at cs.auckland.ac.nz> 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".
>
TCP offload would, of course, help reduce CPU load and make crypto
algorithm choice have more of an effect. With our tests, however, to
actually show an effect, we had to use large packet sizes which
reduced the impact of TCP - I know we were using 64K packets for some
tests. Boosting the packet size also affected cycles-per-byte for
NMAC-style algorithms because the outer function gets run less often
for a given amount of data (IPSec processing occurs outbound prior to
fragmentation).

We needed to reduce the impact of TCP because it still remained that
when doing something with the data, the cycles-per-byte of that
processing greatly impacts the percentage of slowdown your MAC
algorithm choice will have.

To throw another monkey wrench into the works, obviously, you may
think "But what if I have a low power application, trying to be green,
you know. So I want to use less processor intensive cryptography to
save energy?" Well, I sat in the middle of a group of people doing
work for another DARPA project (SensIT) shortly after the ACSA
project. The SensIT project was for low energy wireless sensors in
which we experimented with different key exchange/agreement techniques
in an attempt to economize energy. As a throw-in result, the SensIT
people found it takes 3 orders of magnitude more energy to transmit or
receive data on a per-bit basis than it does to do AES+HMAC-SHA1 (it
came as a surprise to me back then that reception and transmission
take similar amounts of energy). Moral: don't scrimp on crypto to save
energy - at least for wireless, I don't know what it costs to send a
bit down a twisted pair or fiber.

The SensIT final report is available here:
<http://www.cs.umbc.edu/courses/graduate/CMSC691A/Spring04/papers/nailabs_report_00-010_final.pdf>.

-Michael Heyman

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