Re: MACs need to pay attention to small-packet performance

From: Thomas Pornin (pornin_at_nerim.net)
Date: 09/27/04 

Date: Mon, 27 Sep 2004 07:39:17 +0000 (UTC)

According to D. J. Bernstein <djb@cr.yp.to>:
> So you're trying to limit the damage when you lose your laptop? And
> you're reading 1 gigabit per second continuously from your laptop disk?

Actually, my own laptop has a so-called "multi-tasking" operating
system, which means that it has the ability to run other tasks while
performing disk operations. This means that the amount of cpu dedicated
to encryption should not be more, ideally, than about 10% of the total
cpu power. Otherwise, encryption will slow down things, and users will
begin to actively resist the installation of the security system, which
is not a good situation.

Thus, with a 2.5 GHz cpu and an AES implementation which can encrypt a
block in 250 cycles, 10% of the cpu can handle up to 16 megabytes of
data per second. A modern harddisk can work at twice that speed.

Granted, the "10%" figure is arbitrary, but the base idea remains:
symmectric encryption algorithms (and MACs) should be very fast because
even if we have a big fat cpu, we do not want to use the whole of it for
the cryptographic algorithms. The same applies to network connections:
when I am downloading a video stream, my cpu is working on decompression
and rendering, and I don't want to lose frames due to network layer
encryption.

In that view, DoS are not even considered: we do need very fast
encryption and MAC algorithms for legitimate use. Current algorithms are
"quite good" but for some situations we still need better ones. Harddisk
encryption is such a situation.

A variation upon this is the situation with handheld devices. Those are
power-starved since they run on batteries. They need algorithms which
can be computed with very little gate switches. That's what made A5/1
so popular for GSM phones: it can be implemented in hardware with a few
hundred gates, and it operates with only a few scattered electrons.

        --Thomas Pornin

Relevant Pages

  • RE: IBM announces Encrypting tape drives
    ... I prefer CPU-based compression/encryption mostly ... I must admit that I am prejudiced towards CPU machine instructions. ... I would much rather have compression and encryption available on ... "Tape only" encryption solution greatly limits my choices. ...
    (bit.listserv.ibm-main)
  • Re: Encrypted network communication
    ... Bob) communicate over an insecure channel. ... This type of encryption uses a single shared, ... Secret-key encryption algorithms use a single secret key to encrypt and ... unauthorized users and a public key that can be made public to anyone. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: House on Fire... Do You Rescue the Computer?
    ... Long keys are hard to remember. ... Although I've tested it to make sure it works properly, mozy for me, is a $5/month worst case insurance program. ... His point was existing algorithms are useless, because GovCo can setup software or hardware solutions to decrypt existing known algorithms. ... My point was if encryption was not already your primary game, don't bother because it'll be weaker than what's already existing now anyway. ...
    (sci.electronics.design)
  • Re: A question on law and regarding accountability
    ... encryption software is not covered under the same laws it should be ... export laws. ... books, pamphlets, and miscellaneous publications including bound ... Still can run dang fast considering modern cpu power. ...
    (sci.crypt)
  • Re: Connect:Direct (NDM) CPU Usage
    ... An early foray into file encryption showed this behavior, ... Subject: Connect:Direct CPU Usage ... If you wish to communicate securely with Commerce Bank and its ... If you have received this electronic mail message in error, ...
    (bit.listserv.ibm-main)