
Encrypt-then-MAC - cperciva
http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html
======
tptacek
The reason you want to use EAX or CCM instead of CTR+HMAC is that EAX and CCM
are standard constructions. CTR+HMAC isn't.

Let's be clear about this, Colin. You're saying that EAX and CCM
implementations are so untrustworthy that lay developers should implement
their moral equivalents (substituting CBC-MAC and OMAC for HMAC) _by hand_.

In order to use CTR+HMAC, you have to design your own construction to do so.
You likely have to implement HMAC yourself. You have to determine when to
apply it, and where to put it in your messages.

CCM and EAX remove those degrees of freedom, which is exactly what you want:
the fewer decisions a developer/designer needs to make, the fewer
opportunities for things to blow up.

It's the places where primitives join together --- encryption with MAC, for
instance --- where crypto protocols are broken. The person who uses OpenSSL is
far more likely to make a fatal error than the OpenSSL developers themselves.

With all due respect to Colin, I think this take on how to minimize attack
surface is, well, asinine. I think it's based on a bias against crypto library
developers, based on the fact that Colin probably knows more about crypto than
they do.

Stipulated.

But the point isn't that OpenSSL developers are better, or even comparable to
Colin. It's that their code is 1000x more likely to be reviewed than anything
anybody else writes. Your hand-hacked CTR + HMAC protocol isn't going to be
reviewed by anyone who doesn't have a direct financial interest in your code.

~~~
cperciva
_The reason you want to use EAX or CCM instead of CTR+HMAC is that EAX and CCM
are standard constructions. CTR+HMAC isn't._

I don't know from where you get the idea that Encrypt-then-MAC is not a
standard construction. Encrypt-then-MAC was a standard construction long
before EAX and CCM were invented -- in fact, in the paper where EAX is
introduced, it is actually defined as an Encrypt-then-MAC composition!

 _It's the places where primitives join together --- encryption with MAC, for
instance --- where crypto protocols are broken._

If you look carefully at recent breaks, they have been in Encrypt-and-MAC and
MAC-then-Encrypt -- both of which I specifically mention as inferior to
Encrypt-then-MAC.

 _With all due respect to Colin, I think this take on how to minimize attack
surface is, well, asinine. I think it's based on a bias against crypto library
developers, based on the fact that Colin probably knows more about crypto than
they do._

I apply the same approach of minimizing attack surface even when it's only my
own code which is being attacked. The question isn't how prone some code is to
vulnerabilities (although in the examples I gave, there certainly is a poor
track record) -- the issue is _engineering code to eliminate potential risks_.

~~~
tptacek
Encrypt-then-MAC is just an idiom.

By contrast, EAX is a NIST standard.

I don't find your argument particularly convincing. This "encrypt-then-MAC"
thing is a total red herring. You're not advocating for the idiom. You're
advocating for people to build their own nonstandard versions of it, because
you don't like the library code that already exists for the standard versions.

Let's cut to the chase. I can point out HMAC vulnerabilities. Nate's Google
Keyczar finding. SNMPv3. That's 15 seconds worth of research. [ _edit_ SSH
screwed up HMAC as well.]

It should be at least as easy for you to give me two published implementation
flaws in a CCM or EAX implementation. Go.

~~~
cperciva
_I can point out HMAC vulnerabilities. Nate's Google Keyczar finding._

Funny you mention that. The flaw Nate pointed out in Google keyczar can also
affect CCM or EAX (or, for that matter, any authenticated encryption method).

 _It should be at least as easy for you to give me two published
implementation flaws in a CCM or EAX implementation. Go._

Sure:

<http://people.csail.mit.edu/tromer/papers/cache.pdf>
<http://cr.yp.to/antiforgery/cachetiming-20050414.pdf>

Of course, neither of these two papers mention CCM or EAX -- but the flaws
they mention apply to both CCM and EAX (because an attacker can cause you to
input a block of his choice to your AES core) while not affecting CTR-then-
HMAC.

~~~
tptacek
First, the flaw in Keyczar didn't affect CCM (or CBC-MAC) or EAX (or OMAC).

Second, I cited SSH, SNMPv3, and Keyczar. You responded with localhost cache
timing of AES and remote cache timing of naked AES. There's an obvious
difference between the two sets: one consists of real attacks, the other of
speculative attacks. If your point is valid, it shouldn't be hard for you to
name _one system_ in which CCM or EAX were "broken" --- and I'll give you _any
definition of broken you choose_ \--- because of these papers.

They're both great papers. But I don't think they make the argument you think
they do.

~~~
cperciva
_First, the flaw in Keyczar didn't affect CCM (or CBC-MAC) or EAX (or OMAC)._

Of course not -- keyczar doesn't implement CCM or EAX. But the fact that CCM
and EAX are obscure shouldn't count as a point in their favour.

 _There's an obvious difference between the two sets: one consists of real
attacks, the other of speculative attacks._

The Bernstein and Oskiv-Shamir-Tromer attacks were not at all speculative.
They showed the concrete theft of a key.

 _If your point is valid, it shouldn't be hard for you to name one system in
which CCM or EAX were "broken" --- and I'll give you any definition of broken
you choose --- because of these papers._

I don't know of any systems which use CCM or EAX in software on general-
purpose hardware -- but if you name me a system which uses OpenSSL's AES code
circa early 2005 in EAX mode, I'll name you a system which was vulnerable to a
timing side channel.

~~~
tptacek
[http://www.google.com/codesearch?q=CCM+AES&hl=en&btn...](http://www.google.com/codesearch?q=CCM+AES&hl=en&btnG=Search+Code)

Tally ho, Colin! Looking forward to what you find; I'm sure I'll learn
something. If Bernstein's attack was really that relevant to real-world
cryptosystems, I'm sure you'll come back with something fun.

------
ambition
It'd be awesome if someone with great visual communication skills (Amy
Hoy-/Dustin Curtis-/Bret Victor-style) teamed up with cperciva's intense
summaries of encryption knowledge. That would be a helluva one-two punch.

~~~
cperciva
That's an interesting idea, but I'm not sure how well it would work in
practice. Maybe I'm weird, but I find that making things look nice (whether
via improved formatting or the addition of pictures) helps to draw readers'
attention, it doesn't actually help get any more information across.

~~~
kragen
Merely making things look nice won't help, but sometimes things like dataflow
diagrams can convey information more quickly and clearly than just words —
maybe especially to people who are particularly visually oriented.

~~~
cperciva
Fair enough -- if someone wants to start drawing diagrams, I'd be happy to
talk cryptography / security to them. :-)

------
huhtenberg
A well known paper comparing encrypt-authenticate to authenticate-encrypt
approaches (in the context of SSL) is
<http://www.iacr.org/archive/crypto2001/21390309.pdf>

------
cperciva
For reference, the discussion about my earlier post is here:
<http://news.ycombinator.com/item?id=652768>

------
kragen
"It doesn't pass untrusted data to AES" had never occurred to me as an
advantage of CTR over CBC. The XORability of CTR always gives me the willies.

~~~
tptacek
ECB, CBC, CTR, CFB, and OFB are all "XORable", although if you're pointing out
that CTR ciphertexts that share a keystream can be XOR'd to decrypt streams,
that's a valid point, and one that a MAC (of any type) doesn't solve.

You're so far better off not trying to implement any of this stuff that it's
almost not worth studying. PGP at rest, TLS in motion. Spend your time and
heartache on something that will make you money, not something that will get
you laughed at by asshole pentesters.

~~~
kragen
There's the problem with keystream reuse, yes, and also the problem shared to
some degree by CBC and OFB (but not ECB) that's at its worst in CTR — that you
can flip single bits in the plaintext by flipping arbitrary bits in the
ciphertext. (But of course that's why you use a correctly-implemented MAC,
right?)

I concur with you that new cryptographic protocols are likely to be flawed,
and your recent blog post on that subject was excellent reading.

------
chmike
I fully agree on the cypher then MAC policy. Deciphering is time consuming and
by feeding bogus data could be used in a DOS attack. Without prior checking it
may be possible to indirectly probe the deciphering process.

What I am not so sure is the choice of CTR. I currently prefer CFB.

~~~
tptacek
... because?

~~~
chmike
CTR cyphers a value that changes with only a few bits, while CFB uses previous
output which is much more random, though exposed, since it is the ciphered
text.

PS: <http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation> makes it
clear.

~~~
tptacek
Security under those circumstances is a design requirement for AES. CTR is
secure if AES is secure. If known plaintext pairs differing in only a few bits
break AES, we have bigger problems than CTR mode.

------
lisper
I think I'm missing something really basic here. If you encrypt-then-mac, what
is to prevent an attacker from appending a valid MAC to a forged ciphertext
(in order to mount a DOS attack for example)?

~~~
cperciva
A MAC is a keyed hash -- you can only compute it if you have the MAC key.

~~~
lisper
Ah. Thanks. I knew I was missing something basic :-)

------
weavejester
Is there a possibility of timing information being leaked if you verify a HMAC
manually instead of using, say, CCM?

