Hi David,As I read the email, I wondered about replacing HMAC-SHA-1 in 3711 also, and glad to see that your open questions lists that. I have a few questions:
1. Is the 112-bit salt sufficient even with longer keys? You might recall that we've (Mark B., you and I) had discussions on the master key and salt being input to a KDF that results in the derivation of the encr_key, integ_key and a salt, where the output might be longer than the input to the KDF. You are the expert in this area, but I am still wondering if it is an issue.
Figure 2 applies to AES-128 only, right?2. I would suggest that this draft include AES-based CMAC, so we can move away from SHA-1 and also use a single crypto primitive for encryption, and PRF and MAC computation (opinion on your open question).
Q: What are the considerations in truncating cipher-based MAC outputs? Specifically, is truncating below half-the-size of the output (which I vaguely recall as relating to the birthday attack in case of hash-based MACs -- perhaps it is not) of the cipher-based MAC ok? What would be the strength of the MAC in that case. If we are making a case for AES-192 or AES-256, then we have a certain stronger adversary in mind (one that requires us to move away from AES-128). In that case, why is MAC truncation not an issue?
Let's discuss those for now. I may have more later :-). Thanks for doing this! I was going to ask you about using CMAC in 3711!
regards, Lakshminath At 08:15 AM 5/2/2006, David McGrew wrote:
Hello, there has been some interest in using AES with larger key sizes in Secure RTP, and some implementations have gone in this direction in advance of any specification. I wrote up an internet draft to fill this gap (after trying unsuccessfully to get someone else to write it :-) and to provide usage guidance and (eventually) test vectors.It's online at http://www.ietf.org/internet-drafts/draft-mcgrew-srtp- big-aes-00.txtI propose that this draft be adopted for standards track, and I ask for your review (if you have an interest in Secure RTP). Please note the "Open Questions" section. The ietf-rtpsec list is copied since this draft is potentially interesting there, even though the draft has little architectural impact. Best regards, David