Subject: [AVT] Secure RTP Frequently Asked Questions

From: "David A. McGrew" <[email-masked]>
Date: Wed, 26 Oct 2005 11:49:12 -0700

Hello,

Mark, Mats, Karl, and I put together an FAQ based on questions that  
we're received about RFC 3711.  It's available online at http:// 
srtp.sourceforge.net/faq.html.

David

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Usha Sharma" <[email-masked]>
Date: Thu, 27 Oct 2005 13:23:06 -0700

Hi Mats

Thanks for the reply. Yes, you interpreted it correctly. I was wondering what the inputs to the AES_CM would be since it was not very clear in the SRTP RFC. So, I guess I can use as long a plain text (all zeros) as I want to generate the keys of a certain length.

Thanks
Usha

-----Original Message-----
From: Mats Näslund [mailto:[email-masked]] 
Sent: Thursday, October 27, 2005 12:31 PM
To: David A. McGrew
Cc: Usha Sharma; SRTP; AVT
Subject: Re: [Srtp-users] RE: [AVT] Secure RTP Frequently Asked Questions

Hi,

David A. McGrew wrote:

[snip]

>  >
>  > Another doubt is about the key derivation using AES_CM.
>  > The input to the AES_CM PRF is master key (16 byte) and IV (14+2=16
>  > byte). Is this function similar to generating a random number and then
>  > encrypting it using AES_CM with master key and IV! Or is it a fixed
>  > number (which one?) which gets encrypted using AES_CM with master key
>  > and IV.
> 
> I'm not sure exactly what you mean.  Have you looked over RFC 3550, 
> Appendix B.3, "Key Derivation Test Vectors"?

If I understand the question, Usha wonders what we mean when we say that
"AES_CM is used to derive keys", since AES_CM is an *encryption*
algorithm and not really a "key derivation algorithm", is that a correct
interpretation?

If so, you should view it as follows:

1. Take the inputs to AES_CM (the master key and salt as you mention).
2. Run AES_CM to encrypt the all-zero message (000.....0).
3. Use the produced "ciper text" as session key.

So, you could view it as encrypting the value 000....

Put differently, you use AES_CM to generate key stream, but you
really don't encrypt anything with it.

Hope that was a correct interpreation, if not, please clarify and we 
will try to answer.

Best,

/Mats

---

From: "Usha Sharma" <[email-masked]>
Date: Thu, 27 Oct 2005 13:50:00 -0700

Hi David

Thanks a lot for the answers. Most of the things are clear from your
e-mail. I checked the key derivation code at  
http://srtp.sourceforge.net/srtp.html

It uses rijndael-icm functions, for which I could not find any source
code. Can you please point me to the correct location where to look for
these functions.

Thanks
Usha

-----Original Message-----
From: David A. McGrew [mailto:[email-masked]] 
Sent: Thursday, October 27, 2005 12:17 PM
To: Usha Sharma
Cc: SRTP; AVT
Subject: Re: [Srtp-users] RE: [AVT] Secure RTP Frequently Asked
Questions

Usha,

On Oct 27, 2005, at 11:28 AM, Usha Sharma wrote:

> Hi David
>
> This is very comprehensive information for SRTP.
> For Q11, about the length of MKI, I guess the SDP allows maximum  
> length
> of MKI to be 128 bytes instead of 64 bytes.
>

yes, thanks for the correction.

> I have a few other questions regarding the use of AES_CM for  
> encryption
> and key generation.
>
> You mentioned that AES_CM does not require padding. Hardware  
> encryption
> engines such as (broadcom) BCM5812 require that the input to the
> encryption/decryption block should be a multiple of block size. Isn't
> that equivalent to mandatory padding?

Yes.  It sounds like a limitation of the encryption device; it may  
not natively support counter mode.  Or perhaps it has API quirks in  
how it supports counter mode.

> In that case, how do we
> interoperate with a device which does encryption w/o padding? (How  
> do we
> decrypt the data using BCM5812, which is not a multiple of block size)

If it doesn't support counter mode, then you will want to implement  
counter mode on top of ECB mode.  One way to do this is to write the  
counters that would be used by counter mode into a data buffer, then  
pass that buffer to the crypto engine to be ECB-mode encrypted.  Then  
take the resulting ciphertext, and exor that into the plaintext.

> Can we deterministically generate such a number on both sender and
> receiver side as only the master key is known to both sides. Is there
> any example code available to generate the session keys.

Sure, check out http://srtp.sourceforge.net/srtp.html.

> Thanks a lot

You're welcome, and I hope this is useful,

David

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David A. McGrew
> Sent: Wednesday, October 26, 2005 11:49 AM
> To: SRTP; AVT
> Subject: [AVT] Secure RTP Frequently Asked Questions
>
> Hello,
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> Srtp-users mailing list
> [email-masked]
> https://lists.sourceforge.net/lists/listinfo/srtp-users
>