Re: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt

[Qin Wu <[e-mail]>]

Thanks for clarification. I removed the fixed comments, please see inline.
----- Original Message ----- 
From: "Jonathan Lennox" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, May 05, 2011 11:34 PM
Subject: Re: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt

> Section 3 Encryption Mechanism
> "
>  To encrypt (or decrypt) an encrypted extension header, an SRTP
>   participant first generates a keystream for the SRTP extension
>   header.  This keystream is generated in the same manner as the
>   encryption keystream for the corresponding SRTP payload, except the
>   the SRTP encryption and salting keys k_e and k_s are replaced by the
>   keys k_he and k_hs, respectively.
> "
> [Qin]: Is it possible to use the same keystream and crypto-suite for SRTP payload
> to provide encryption for the payload of header extension element?
> What's the benefit to choose the different keystream and crypto-suite for header extension elements?
> Can we say the same keystream and  crypto-suite for SRTP payload can be applied to header extension elements?

It definitely uses the same cryptosuite, but it can't be the same keystream -- if the payload and the extension elements are encrypted with the same keystream, you have a two-time-pad security failure.

[Qin]: I agree using the same keystream to encrypt twice  will cause two-time pad security failure issue,
 i.e., first use the keystream to encrypt STRP payload, and then use the same keystream to encrypt 
header extension elements.

However if we regard the payload of header extension elements and SRTP payload as a big payload, 
we only need to use the same keystream to encrypt this big payload once. there is no two-time pad 
security issue, right?

In principle you could use a different region of the same keystream, but there's no obvious way to do that in a way that's backward-compatible with existing SRTP.

Since SRTP implementations are already generating six separate keys based on the master key (encryption, salting, and authentication for both RTP and RTCP) and two keystreams (for RTP and RTCP), adding two additional keys and one additional keystream doesn't seem like a particularly large implementation burden.

[Qin]: True.