4 ms·

Is a CTR+HMAC code much more tricky to implement than EAX? I'd imagine it's just: e := encrypt(x) e := e + sep + hmac(e) And for decryption: e, m

Is a CTR+HMAC code much more tricky to implement than EAX? I'd imagine it's just: e := encrypt(x) e := e + sep + hmac(e) And for decryption: e, m := split(e, sep) if m = hmac(e): x := decrypt(e) The only thing I'd be particularly worried about is timing attacks on `m = hmac(e)`. Am I just being naive?

tptacek 17y ago
http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/ http://rdist.root.org/2009/05/28/timing-attack-in-google-key... The issue isn't that EAX is easier to implement than CTR+HMAC. EAX is actually harder to implement than CTR+HMAC. The issue is that someone will have already written EAX for you, because EAX is a NIST standard that is used in actual fielded systems. There is no NIST standard AE construction (that I know of; I'm not an expert) that combines CTR and HMAC. You'll have to implement it yourself.
- weavejester 17y ago
  Yes, but so far as I can see, the implementation is very straightforward. I wouldn't have thought there'd be much difference in practise.
  - tptacek 17y ago
    My "actual citation of a Rivest student coding for Google making the HMAC error" argument has a THAC0 of 5, and your "yes, but" argument has a THAC0 of 15. You might win this debate, but I doubt it. Colin points out (rightly, in the narrow scope he drew) that Google could have made the same error with CBC-MAC or OMAC; they'd still be comparing bytes directly, not doing the safe XOR comparison. But Colin is making my point for me. Because if you used EAX or CCM, you wouldn't be implementing that compare for yourself; it'd be taken care for you by the block cipher mode, which would yield either a plaintext or a failure. Yes, the library designer could make that mistake too; after all, Google did! But again, that's my point. Google making this error was a newsworthy event, and the mere fact Google implemented it caused Nate Lawson to review the code and find it. You have none of those benefits. You're going to make the same error, and nobody's going to find it until it matters that you've not made it.
    - weavejester 17y ago
      Okay, but using an encryption library doesn't guarantee your code is free of mistakes either. Just initiating a generic cryptography library requires a certain amount of specialised knowledge. You have to get the right mode, create a secure key, know how to correctly use an IV or whatever additional parameters the particular encryption algorithm needs. Compared to all that, comparing two HMACs seems relatively straightforward.

tptacek 17y ago

http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/ http://rdist.root.org/2009/05/28/timing-attack-in-google-key... The issue isn't that EAX is easier to implement than CTR+HMAC. EAX is actually harder to implement than CTR+HMAC. The issue is that someone will have already written EAX for you, because EAX is a NIST standard that is used in actual fielded systems. There is no NIST standard AE construction (that I know of; I'm not an expert) that combines CTR and HMAC. You'll have to implement it yourself.

weavejester 17y ago
Yes, but so far as I can see, the implementation is very straightforward. I wouldn't have thought there'd be much difference in practise.
- tptacek 17y ago
  My "actual citation of a Rivest student coding for Google making the HMAC error" argument has a THAC0 of 5, and your "yes, but" argument has a THAC0 of 15. You might win this debate, but I doubt it. Colin points out (rightly, in the narrow scope he drew) that Google could have made the same error with CBC-MAC or OMAC; they'd still be comparing bytes directly, not doing the safe XOR comparison. But Colin is making my point for me. Because if you used EAX or CCM, you wouldn't be implementing that compare for yourself; it'd be taken care for you by the block cipher mode, which would yield either a plaintext or a failure. Yes, the library designer could make that mistake too; after all, Google did! But again, that's my point. Google making this error was a newsworthy event, and the mere fact Google implemented it caused Nate Lawson to review the code and find it. You have none of those benefits. You're going to make the same error, and nobody's going to find it until it matters that you've not made it.
  - weavejester 17y ago
    Okay, but using an encryption library doesn't guarantee your code is free of mistakes either. Just initiating a generic cryptography library requires a certain amount of specialised knowledge. You have to get the right mode, create a secure key, know how to correctly use an IV or whatever additional parameters the particular encryption algorithm needs. Compared to all that, comparing two HMACs seems relatively straightforward.