[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The use of AES-192 and AES-256 in Secure RTP
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
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!
At 08:15 AM 5/2/2006, David McGrew wrote:
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
I 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.