Encryption and authentication modes

[Justin Troutman]

Florian Weimer wrote:
>
> 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.
>   

As David [McGrew] mentioned -- thanks, David -- I've been working
towards drafting a proposal for standardizing encrypt-then-authenticate
generic composition, and David [McGrew, again] has been quite generous
in sharing his work in this area.  Working towards this is one aspect of
our work (Vincent Rijmen and I) in making cryptography easier to get
right at the implementation level, so that its true potential can be
realized in practice.  Developers shouldn't be making cryptographic
decisions, which is one of the driving forces behind our push for
standardizing encrypt-then-authenticate generic composition; they
needn't be burdened with addressing the subtleties that go along with
composite authenticated encryption schemes.

The desire to push for this was born out of "green cryptography," which
Vincent and I introduced in IEEE Security & Privacy last year.  The
premise behind green cryptography was to recycle cryptographic
primitives whenever and wherever possible, and do so in a way that not
only minimizes implementation complexity, but maximizes cryptographic
security.  What we ended up with is AES-based encrypt-then-authenticate
(e.g., AES-CBC-then-AES-CMAC); this achieves the strongest notions of
confidentiality and integrity per Bellare and Namprempre (i.e., IND-CCA2
/\ INT-CTXT) and -- here's the best part -- it's the easiest for
developers to get right, since it is secure for all possible secure
instantiations of its constituent primitives.

If we are to standardize encrypt-then-authenticate generic composition,
we would most likely have to include support for SHA-1, SHA-2, and
SHA-3; this isn't exactly in line with the recycling paradigm, but a
necessary compromise in regards to support across the board.  You can
get the same security out of AES-CMAC and SHA-*-HMAC, either way.
Still, it's important to limit the number of options available, since
the more options you have, the more complexity you introduce to the
implementation.  Perhaps having a standard that supports
AES-CBC/AES-CTR-then-AES-CMAC/SHA-*-HMAC would work; this is where
community feedback is really useful, since such a standard needs to be
as flexible as it is secure.  Any thoughts?

I've recently spoke with Steve Weis and Ben Laurie at Google, who put
together the open-source Keyczar (keyczar.org) cryptographic toolkit,
aimed at making cryptography "safe and simple" for developers to use;
they did say, however, that oftentimes, they found themselves backed
into a corner with allowing configurations that may be secure, and
reasonable, for niche applications, but insecure elsewhere -- in other
words, no good for standards.  I mention Keyczar because it may be
something of interest to you, and I think it serves as a progressive
model for the direction we need to be going in -- making cryptography
easier to get right.  You're absolutely right that you shouldn't have to
worry about the details, and that it is easy to misuse.  That needs to
change.

In closing, I'll mention that green cryptography's design paradigm of
"do a lot with a little; less is more" has found its way into a
conceptual framework we're working on, dubbed Mackerel, which looks at
abstracting away as much of the cryptography as possible and, instead,
focus on the higher level concepts of confidentiality and integrity, and
why they're mutually necessary.  Just as green cryptography is concerned
with the assurance of cryptographic implementations, Mackerel is
concerned with the tightness of the interface between cryptography and
cryptographers, developers, and users.  We're drawing a lot from the
field of HCIsec, or Human Computer Interaction Security --  of which
another Googler, Alma Whitten, is a pioneer*.

So, that's a snapshot of what we -- Vincent Rijmen and I -- have been up
to over the past couple of years, and I look forward to sharing more as
it develops and evolves.  I had hoped to have a draft together earlier,
but it just wasn't in line with the workload and pace over the past few
months; it does appear that I'll have something together by the end of
August, which is a plus.  We're wide open to thoughts on this.


* http://gaudior.net/alma/johnny.pdf

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