|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: cryptography@metzdowd.com X-Original-To: cryptography@metzdowd.com Date: Sun, 14 May 2006 19:27:46 -0500 From: "Travis H." <solinym@gmail.com> To: EKR <ekr@rtfm.com> Cc: Cryptography <cryptography@metzdowd.com> In-Reply-To: <86ves8dvrp.fsf@romeo.rtfm.com> On 5/14/06, Eric Rescorla <ekr@rtfm.com> wrote: > Consider the case where you're transmitting message M. The > hash is H(M). You then encrypt (M || H(M)), generating > K XOR (M || H(M)). If the attacker knows M and H, he can > compute (M || H(M)) and compute K. Then he can re-encrypt > a message M' of his choice. Excellent point. When I wrote that I had strongly universal hashes in mind, like UMAC, where the hash is chosen from a family of functions based on some secret data shared by sender and recipient. I mistakenly conflated them with ordinary hashes (which they are, once you pick one). Thanks for catching that. IMHO encrypting MACs is a good defensive measure, because you can then use a smaller hash value, so you end up encrypting as little as 4 bytes instead of transmitting 20 en clair, and now you also know the opponent hasn't learned anything. Does anyone know if MAC-then-encrypt(plaintext) versus encrypt(plaintext)-then-MAC makes a difference if the MAC itself is to be encrypted? I can't think of why it would. --=20 "Curiousity killed the cat, but for a while I was a suspect" -- Steven Wrig= ht Security Guru for Hire http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |