Encryption and authentication modes

[David McGrew]

Hi Florian,

On Jul 23, 2010, at 1:14 AM, Florian Weimer wrote:

> * 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.

RFC 5116 sounds perfect.  It might be worthwhile to publish a C API  
for that interface, along with detailed documentation.   That would be  
fairly straightforward; I think the only complexity is supporting an  
incremental "init/update/final" interface.   For your application, it  
sounds like you don't need the incremental API.

thanks,

David

>
> 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