Encryption and authentication modes

[Florian Weimer]

* David McGrew:

> can I ask what your interest in AEAD is?  Is there a particular
> application that you have in mind?

I just want to create a generic API which takes a key (most of the
time, a randomly generated session key) and can encrypt and decrypt
small blobs.  Application code should not need to worry about details
(except getting key management right, which is difficult enough).
More popular modes such as CBC lack this property, it's too easy to
misuse them.

I suppose a superficially similar primitive is contained in
Bernstein's NaCl library.  I was intrigued by its simplicity, but the
cryptographic algorithms it uses are a bit non-standard.

Right now, I would probably use it to forward session state through
browser URLs in areas which are not actually security-relevant.
Somewhat more sensitive applications are possible in the future.  In
no case I expect adversaries to actually have access to ciphertext.
To some degree, it's about being able to say "yes, we use encryption
for X, and it's algorithm Y", and I want to do it right without using
CMS or modern OpenPGP, with all the complexities that come with that.

When I said that CCM wasn't widely implemented, I was referring to the
fact that none of the cryptographic libraries on my system supports it
directly.  This is a pity because once you fix the parameters, it's
much simpler to use safely than pure encryption modes.

There seems to be one downside with the CCM instance specified towards
the end of the NIST standard, though: If you on an architecture where
sizeof(size_t) == 8, then your encryption function isn't total because
it can't accept the full range of possible input lengths---or you end
up with just 64 bit for the tag, which seems to be a bit on the small
side.  I'm not sure if this is a compelling reason to use EAX or GCM,
though---especially since we're strictly limited to 31 bit array
length in some places by software and not hardware (so this limitation
will be in place for a long time).

A mode which does not rely as much on proper randomness for the IV
would be somewhat nice to have, but it seems that the only choice
there is SIV, which has received less scrutiny than other modes.

> OCB is very attractive in software, but GCM is more efficient in
> hardware because it can be implemented without pipeline stalls.  GCM
> can perform well in software, though it can't be as compact as CCM,
> and it excells with SIMD (http://eprint.iacr.org/2009/129) or modest
> hardware support like Intel's new PCLMULQDQ instruction
> (http://www.drdobbs.com/security/218102294;jsessionid=GMTY4RCFLHBMRQE1GHOSKHWATMY32JVN?pgno=3
> ).

Interesting.  But it will take about five years until our crypto code
would make use of a new hardware instruction, assuming that we'd
implement all the necessary pieces right now (thanks to desynchronized
software release cycles at several layers of the software stack).
Speed is of no particular concern anyway.  Increase in message size is
somewhat relevant (think about the URL case I mentioned), but only to
up to a degree.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

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