Hi Lakshminath, thanks for your comments, more inline: On May 2, 2006, at 9:50 AM, Lakshminath Dondeti wrote:
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.
I think that the 112-bit salt is sufficient. The srtp salt is present so that the srtp use of counter mode is essentially as secure as CBC mode against attacks that amortize computational effort over multiple target keys. This property still holds for the larger key sizes. Besides, there's not much that we can do to increase the salt length, since there are only 16 more bits that we could possibly add. I also think that it is valuable to retain counter-format compatibility with the AES-128 counter mode.
Figure 2 applies to AES-128 only, right?
No, it's for all of the key sizes. AES-192 and AES-256 still have 16 byte plaintexts. Or maybe I'm not understanding; did I mislabel something?
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).
We think alike :-) I implemented AES CMAC for SRTP and found that it performs better than HMAC-SHA1 for very short packets (like those for conversational voice over a WAN) but not long packets (like video). It also has some other advantages. But OTOH there is a cost to proliferating cryptoalgorithms. Let's start up a separate thread on CMAC.
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?
Ah, good points. The NIST CMAC specification disallows truncation to MACs shorter than 64 bits. This is not because CMAC is weaker than an ideal MAC with respect to truncation, though. CMAC has been shown to be a good pseudorandom function if AES is a good blockcipher (as long as some usage limits are respected), and a PRF essentially is an ideal MAC. I'm pretty sure that the CMAC specification insists on MACs of at least 64 bits because it feels that a per-MAC forgery probability greater than 2^64 is not acceptable. No doubt they were not considering the case of stateless codecs, which some SRTP users need only 32-bit MACs. It is an interesting question as to what tag sizes would be recommended for use with CMAC!
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?
That's a good question. I think that in some circumstances it could make sense to use a short authentication tag and a huge key. If some unanticipated advance in cryptanalysis enables us to break AES-128 but not AES-256, but some user is still okay with accepting one out of a billion forged g.711 packets, this scenario would fit the bill. So the cryptosuites defined in the draft might make sense. But I take your point that users concerned that AES-128 doesn't have enough security may well not be satisfied with a 32-bit MAC. It would be good to get some input from the Suite B community on this question.
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!
Any thoughts on whether or not AES-192 should be included? David
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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.