[cryptography] "Combined" cipher modes
noloader at gmail.com
Mon Feb 20 15:32:23 EST 2012
On Mon, Feb 20, 2012 at 2:40 PM, Kevin W. Wall <kevin.w.wall at gmail.com> wrote:
> First of all, let me thank all who have responded for lending
> your expertise. I am just picking out Ian's to respond to
> because of his suggesting dividing up the IV into
> but I do appreciate everyone else's comments as well.
> On Mon, Feb 20, 2012 at 7:11 AM, ianG <iang at iang.org> wrote:
>> On 20/02/12 18:11 PM, Kevin W. Wall wrote:
> Based on this and some additional comments from Duong & Rizzo, we decided to
> use the encrypt-then-MAC approach to ensure the integrity of the ciphertext.
> (Keep in mind this was designed around the time that Duong and Rizzo
> automated a padding oracle attack with their POET software.)
> However, we skipped the MAC calculation if the cipher mode chosen
> was an authenticated mode like CCM or GCM. The assumption (hopefully
> a correct one), was that an authenticated cipher mode was sufficient.
Duong and Rizzo relied on the fact that authentication and encryption
was glued together in a bad way, which was further compounded by
log/error messages leaking information. This was observed some time
ago (and the reason for NIST requesting authenticated encryption
modes). From "A Conventional Authenticated-Encryption Mode"
...people had been doing rather poorly when they
tried to glue together a traditional (privacy-only)
encryption scheme and a message authentication
CBC-MACs were known to be insecure for variable length messages years
before the attack, so I almost exclusively used a HMAC rather than a
CBC-MAC. A CMAC would also do if a block cipher were handy (but I
generally use a HMAC because hashes are much faster in practice). I
will be in a world of trouble if SHA-256 suddenly fails.
I also seem to recall Wagner and Schneier telling us SSL/TLS hard some
practical implementation shortcomings from "Analysis of the SSL 3.0
Protocol" (http://www.schneier.com/paper-ssl.html) in 1996. The pieces
were OK, it was they way they were glued together and the choice of
Wagner also has some good slides on his site comparing various
authenticated encryption modes during NIST selection process. CCM is
one of the worst performing modes while EAX was one of the better
performing. The slides don't talk about the politics involved in the
choice of CCM over EAX by NIST ;)
Off topic: this is why I tend to follow crypto-numerology, and listen
when bright folks tell me to do things like meet a 112-bit security
level in 2011.
More information about the cryptography