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 majord...@metzdowd.com