On Thu, Jul 23, 2009 at 1:34 AM, Peter Gutmann<[email protected]> wrote: > "[email protected]" <[email protected]> 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 [email protected]
