Subject: [AVT] SRTP and algorithmic delay

From: Scott Keagy <[email-masked]>
Date: Mon, 04 Nov 2002 19:53:44 -0800

Folks:

I haven't noticed any discussion of algorithmic delay associated with SRTP 
(and only found one unrelated instance of a keyword search on delay in the 
ID). My apologies if this has already been discussed on the list (I've been 
unsubscribed for a while). Specifically, I want to explore the implications 
for a scenario like SRTP encrypting a G.723.1 codec output.

If operating in a block cipher mode to offer increased security (as opposed 
to a stream cipher mode), it seems that a significant amount of delay can 
be incurred to wait for enough G.723.1 frames to form a complete block 
against which to apply the block cipher algorithm. For example:

Each G.723.1 frame is 30ms;
At 5.3kbps output: (5300 bps * .030 s) = 159 bits (just checked the spec, 
actually 158 bits)
At 6.3kbps output: (6300 bps * .030 s) = 189 bits (actually 189 bits)

In the good case where the cipher block size is smaller than a single frame 
of the codec output, the block cipher incurs zero algorithmic delay (which 
would be additive to the 37.5 ms algorithmic delay of the G.723.1 codec). 
In a bad case, where the cipher block size is greater than the codec frame, 
then the cipher block processing cannot begin until the cipher block is 
filled with two or more codec frames, so an additional 30 ms of algorithmic 
delay is introduced for every additional G.723.1 frame required to fill the 
cipher block (even if only 2 bits of it are required). This excludes the 
processing delay associated with actually performing the calculations with 
the data stream.

Consider the case where the block cipher was based on 160 bit block ( n_b 
=160 from your draft) for a 5.3kbps G.723.1 stream. At T=0, the digitized 
voice stream enters the G.723.1 coder. At T=37.5ms (plus processing delay) 
the output of the first G.723.1 frame is available for the block cipher 
input. Now the frame is only 158 bits and the block cipher expects 160 bits 
before acting, so we must wait for another G.723.1 frame 30 ms later, even 
though we'll only use 2 bits of it. So at 67.5 ms total algorithmic delay 
(inclusive of 37.5ms from the G.723.1 coder function and 30ms from the 
block cipher function) we can begin to process the first complete block of 
160 bits, while 156 bits are left in the SRTP cipher block queue.

While this can be addressed through prudent selection of cipher block size 
(e.g. n_b equal or less than desired multiple of the codec frame). It might 
be nice to highlight this block size consideration in the draft, as an 
encouragement to make SRTP implementations allow the block size to be 
configured (at least as a selection among preset choices) rather than being 
hard-coded in the implementation. Of course availability of crypto 
libraries for given block sizes will also affect such an implementation 
decision.

Another alternative could be padding of the cipher block following the 
output of each codec frame to avoid additional delay, but this would reduce 
the bandwidth efficiency of the implementation, and would be misleading in 
terms of the cryptographic strength as a function of block size.

Note that any tandem coding when SRTP is in play as described above will 
result in intolerable delays in most circumstances (and added delay of 60ms 
one way, or 120ms for talker echo annoyance calculations). Single coding 
will also be questionable with an additional 30ms of delay.

Regards,

Scott Keagy, CCIE# 3985
Product Manager, Enterprise Voice and Video Business Unit
Cisco Systems, Inc.
tel:+1-408-902-3902
mailto:[email-masked]

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

---

From: Mark Baugher <[email-masked]>
Date: Mon, 04 Nov 2002 20:35:32 -0800

hi Scott,

At 07:53 PM 11/4/2002 -0800, Scott Keagy wrote:
>ID). My apologies if this has already been discussed on the list (I've 
>been unsubscribed for a while). Specifically, I want to explore the 
>implications for a scenario like SRTP encrypting a G.723.1 codec output.
>
>If operating in a block cipher mode to offer increased security (as 
>opposed to a stream cipher mode), it seems that a significant amount of 
>delay can be incurred to wait for enough G.723.1 frames to form a complete 
>block against which to apply the block cipher algorithm. For example:

The two ciphers offered by SRTP are hybrid stream/block ciphers that 
operate on packets so there is no need to wait for a complete block (of 16 
bytes for the SRTP transforms) as the packet can be processed 
directly.  There should be no problem for block ciphers since the packet 
format will likely include the initialization vector and necessary padding 
so, again, the packet can be directly encrypted by the sending SRTP without 
any added delay.

>At 6.3kbps output: (6300 bps * .030 s) = 189 bits (actually 189 bits)

there is no problem even if only single byte is conveyed in the packet.

>In the good case where the cipher block size is smaller than a single 
>frame of the codec output, the block cipher incurs zero algorithmic delay 
>(which would be additive to the 37.5 ms algorithmic delay of the G.723.1 
>codec). In a bad case, where the cipher block size is greater than the 
>codec frame, then the cipher block processing cannot begin until the 
>cipher block is filled with two or more codec frames, so an additional 30 
>ms of algorithmic delay is introduced for every additional G.723.1 frame 
>required to fill the cipher block (even if only 2 bits of it are 
>required). This excludes the processing delay associated with actually 
>performing the calculations with the data stream.
>
>input. Now the frame is only 158 bits and the block cipher expects 160 
>bits before acting, so we must wait for another G.723.1 frame 30 ms later, 
>even though we'll only use 2 bits of it. So at 67.5 ms total algorithmic 
>delay (inclusive of 37.5ms from the G.723.1 coder function and 30ms from 
>the block cipher function) we can begin to process the first complete 
>block of 160 bits, while 156 bits are left in the SRTP cipher block queue.

It works like this:  Some number of media frames are assembled into an RTP 
packet, which SRTP may process by encrypting the payload.  SRTP will 
generate one 16-byte block if the length of the media frames is less than 
16 bytes.  In general, I expect that the number of blocks generated for the 
AES counter mode cipher will not equal the length of the payload - some of 
the bits will be "left over" and that's not a problem.  This is because 
SRTP's ciphers work on a stream of blocks.  Block ciphers can be designed 
so that there won't be any need to delay the packet to completely use a block.

>(e.g. n_b equal or less than desired multiple of the codec frame). It 
>might be nice to highlight this block size consideration in the draft, as 
>an encouragement to make SRTP implementations allow the block size to be 
>configured (at least as a selection among preset choices) rather than 
>being hard-coded in the implementation. Of course availability of crypto 

In general, you won't be able to arbitrarily change the block size of the 
cipher.

>output of each codec frame to avoid additional delay, but this would 
>reduce the bandwidth efficiency of the implementation, and would be 
>misleading in terms of the cryptographic strength as a function of block size.

Remember that we are not encrypting individual media frames as they are 
output from the codec but we're operating on one or more media frames (or a 
fragment) that are assembled in an RTP packet.  Even if we were operating 
on codec output and encrypting prior to packetization, AES counter mode 
will work without any algorithmic delay for the reasons I cited above.

Mark

>result in intolerable delays in most circumstances (and added delay of 
>60ms one way, or 120ms for talker echo annoyance calculations). Single 
>coding will also be questionable with an additional 30ms of delay.
>
>Regards,
>
>Scott Keagy, CCIE# 3985

---

From: Scott Keagy <[email-masked]>
Date: Mon, 04 Nov 2002 21:25:47 -0800

Thanks for clarification- if I'd read the draft more closely I would have 
noted early references to SRTP sitting between RTP and transport protocol 
in the stack.

At 08:35 PM 11/4/2002 -0800, Mark Baugher wrote:
>>I haven't noticed any discussion of algorithmic delay associated with 
>>SRTP (and only found one unrelated instance of a keyword search on delay 
>>in the ID). My apologies if this has already been discussed on the list 
>>(I've been unsubscribed for a while). Specifically, I want to explore the 
>>delay can be incurred to wait for enough G.723.1 frames to form a 
>>complete block against which to apply the block cipher algorithm. For example:
>
>so, again, the packet can be directly encrypted by the sending SRTP 
>without any added delay.
>
>
>
>>voice stream enters the G.723.1 coder. At T=37.5ms (plus processing 
>>delay) the output of the first G.723.1 frame is available for the block 
>>cipher input. Now the frame is only 158 bits and the block cipher expects 
>>160 bits before acting, so we must wait for another G.723.1 frame 30 ms 
>>later, even though we'll only use 2 bits of it. So at 67.5 ms total 
>>algorithmic delay (inclusive of 37.5ms from the G.723.1 coder function 
>>and 30ms from the block cipher function) we can begin to process the 
>>first complete block of 160 bits, while 156 bits are left in the SRTP 
>>cipher block queue.
>
>16 bytes.  In general, I expect that the number of blocks generated for 
>the AES counter mode cipher will not equal the length of the payload - 
>some of the bits will be "left over" and that's not a problem.  This is 
>because SRTP's ciphers work on a stream of blocks.  Block ciphers can be 
>designed so that there won't be any need to delay the packet to completely 
>use a block.
>
>
>>While this can be addressed through prudent selection of cipher block 
>>size (e.g. n_b equal or less than desired multiple of the codec frame). 
>>It might be nice to highlight this block size consideration in the draft, 
>>as an encouragement to make SRTP implementations allow the block size to 
>>be configured (at least as a selection among preset choices) rather than 
>output from the codec but we're operating on one or more media frames (or 
>a fragment) that are assembled in an RTP packet.  Even if we were 
>operating on codec output and encrypting prior to packetization, AES 
>counter mode will work without any algorithmic delay for the reasons I 
>cited above.
>
>Mark
>
>

---

From: Mats Näslund <[email-masked]>
Date: Tue, 05 Nov 2002 09:33:36 +0100

Hi

I would also like to add that even if there were block cipher
with a block size that could be reduced, a very small block size
is bad from security point of view as it opens up for so-called
"dictionary attacks".

Best,

/Mats

Scott Keagy wrote:
> Thanks for clarification- if I'd read the draft more closely I would 
> have noted early references to SRTP sitting between RTP and transport 
> protocol in the stack.
> 
>>> SRTP (and only found one unrelated instance of a keyword search on 
>>> delay in the ID). My apologies if this has already been discussed on 
>>> the list (I've been unsubscribed for a while). Specifically, I want 
>>> to explore the implications for a scenario like SRTP encrypting a 
>>> G.723.1 codec output.
>>>
>>> opposed to a stream cipher mode), it seems that a significant amount 
>>> of delay can be incurred to wait for enough G.723.1 frames to form a 
>> operate on packets so there is no need to wait for a complete block 
>> (of 16 bytes for the SRTP transforms) as the packet can be processed 
>> directly.  There should be no problem for block ciphers since the 
>> packet format will likely include the initialization vector and 
>> necessary padding so, again, the packet can be directly encrypted by 
>> the sending SRTP without any added delay.
>>
>>
>>
>>> At 5.3kbps output: (5300 bps * .030 s) = 159 bits (just checked the 
>>> spec, actually 158 bits)
>>> frame of the codec output, the block cipher incurs zero algorithmic 
>>> delay (which would be additive to the 37.5 ms algorithmic delay of 
>>> the G.723.1 codec). In a bad case, where the cipher block size is 
>>> greater than the codec frame, then the cipher block processing cannot 
>>> begin until the cipher block is filled with two or more codec frames, 
>>> so an additional 30 ms of algorithmic delay is introduced for every 
>>> additional G.723.1 frame required to fill the cipher block (even if 
>>> only 2 bits of it are required). This excludes the processing delay 
>>> associated with actually performing the calculations with the data 
>>> stream.
>>>
>>> Consider the case where the block cipher was based on 160 bit block ( 
>>> n_b =160 from your draft) for a 5.3kbps G.723.1 stream. At T=0, the 
>>> digitized voice stream enters the G.723.1 coder. At T=37.5ms (plus 
>>> processing delay) the output of the first G.723.1 frame is available 
>>> for the block cipher input. Now the frame is only 158 bits and the 
>>> block cipher expects 160 bits before acting, so we must wait for 
>>> another G.723.1 frame 30 ms later, even though we'll only use 2 bits 
>>> of it. So at 67.5 ms total algorithmic delay (inclusive of 37.5ms 
>>> from the G.723.1 coder function and 30ms from the block cipher 
>>> function) we can begin to process the first complete block of 160 
>>> bits, while 156 bits are left in the SRTP cipher block queue.
>>
>>
>> It works like this:  Some number of media frames are assembled into an 
>> RTP packet, which SRTP may process by encrypting the payload.  SRTP 
>> will generate one 16-byte block if the length of the media frames is 
>> less than 16 bytes.  In general, I expect that the number of blocks 
>> generated for the AES counter mode cipher will not equal the length of 
>> the payload - some of the bits will be "left over" and that's not a 
>> problem.  This is because SRTP's ciphers work on a stream of blocks.  
>> Block ciphers can be designed so that there won't be any need to delay 
>> the packet to completely use a block.
>>
>>
>>> size (e.g. n_b equal or less than desired multiple of the codec 
>>> frame). It might be nice to highlight this block size consideration 
>>> in the draft, as an encouragement to make SRTP implementations allow 
>>> the block size to be configured (at least as a selection among preset 
>>> choices) rather than being hard-coded in the implementation. Of 
>>> course availability of crypto libraries for given block sizes will 
>>> also affect such an implementation decision.
>>
>>
>> In general, you won't be able to arbitrarily change the block size of 
>> the cipher.
>>
>>
>>> Another alternative could be padding of the cipher block following 
>>> the output of each codec frame to avoid additional delay, but this 
>>> would reduce the bandwidth efficiency of the implementation, and 
>>> would be misleading in terms of the cryptographic strength as a 
>>> function of block size.
>>
>>
>> Remember that we are not encrypting individual media frames as they 
>> are output from the codec but we're operating on one or more media 
>> frames (or a fragment) that are assembled in an RTP packet.  Even if 
>> we were operating on codec output and encrypting prior to 
>> packetization, AES counter mode will work without any algorithmic 
>> delay for the reasons I cited above.
>>
>> Mark
>>
>>
>>> Note that any tandem coding when SRTP is in play as described above 
>>> will result in intolerable delays in most circumstances (and added 
>>> delay of 60ms one way, or 120ms for talker echo annoyance 
>>> calculations). Single coding will also be questionable with an 
>>> additional 30ms of delay.
>>>
>>> Regards,
>>>
>>> Scott Keagy, CCIE# 3985

-- 
--------------------------------------
Mats Näslund, PhD, Senior Specialist
Communications Security Lab
Ericsson Research
SE-16480 Stockholm, Sweden
Visiting adr: Torshamnsgatan 23, Kista
Phone/Fax: (+46 8) 58533739/4047020

---

From: Scott Keagy <[email-masked]>
Date: Tue, 05 Nov 2002 01:28:03 -0800

As a point of curiosity, how much different is a small block size for a 
brute-force attack (i.e. trying all permutations) than using a larger block 
size padded with well-known contents? I'm not familiar with cipher details, 
but it seems at a high level to have a similarly reduced set of input 
permutations that need to be guessed for the brute-force attack.

If content of the padded bits can be randomized then larger block sizes 
make sense on merit of increased cryptographic strength (to my limited 
understanding). This would also assume that a pointer or length field 
identifies the boundary between data bits and padding bits.

At 09:33 AM 11/5/2002 +0100, Mats Näslund wrote:
>>>>the list (I've been unsubscribed for a while). Specifically, I want to 
>>>>explore the implications for a scenario like SRTP encrypting a G.723.1 
>>>>codec output.
>>>>
>>>operate on packets so there is no need to wait for a complete block (of 
>>>16 bytes for the SRTP transforms) as the packet can be processed 
>>>format will likely include the initialization vector and necessary 
>>>padding so, again, the packet can be directly encrypted by the sending 
>>>SRTP without any added delay.
>>>
>>>
>>>
>>>>delay (which would be additive to the 37.5 ms algorithmic delay of the 
>>>>G.723.1 codec). In a bad case, where the cipher block size is greater 
>>>>than the codec frame, then the cipher block processing cannot begin 
>>>>until the cipher block is filled with two or more codec frames, so an 
>>>>additional 30 ms of algorithmic delay is introduced for every 
>>>>associated with actually performing the calculations with the data stream.
>>>>
>>>>another G.723.1 frame 30 ms later, even though we'll only use 2 bits of 
>>>>it. So at 67.5 ms total algorithmic delay (inclusive of 37.5ms from the 
>>>>G.723.1 coder function and 30ms from the block cipher function) we can 
>>>>begin to process the first complete block of 160 bits, while 156 bits 
>>>>are left in the SRTP cipher block queue.
>>>
>>>
>>>RTP packet, which SRTP may process by encrypting the payload.  SRTP will 
>>>generate one 16-byte block if the length of the media frames is less 
>>>than 16 bytes.  In general, I expect that the number of blocks generated 
>>>for the AES counter mode cipher will not equal the length of the payload 
>>>- some of the bits will be "left over" and that's not a problem.  This 
>>>is because SRTP's ciphers work on a stream of blocks.
>>>>It might be nice to highlight this block size consideration in the 
>>>>draft, as an encouragement to make SRTP implementations allow the block 
>>>>size to be configured (at least as a selection among preset choices) 
>>>>rather than being hard-coded in the implementation. Of course 
>>>>availability of crypto libraries for given block sizes will also affect 
>>>>such an implementation decision.
>>>
>>>
>>>output from the codec but we're operating on one or more media frames 
>>>(or a fragment) that are assembled in an RTP packet.  Even if we were

---

From: Mats Näslund <[email-masked]>
Date: Tue, 05 Nov 2002 11:01:23 +0100

Scott Keagy wrote:
> brute-force attack (i.e. trying all permutations) than using a larger 
> block size padded with well-known contents? I'm not familiar with cipher 
> details, but it seems at a high level to have a similarly reduced set of 
> input permutations that need to be guessed for the brute-force attack.

Clearly, if you are encrypting data were most of the messages are
less than a block long and you use a static padding, you will get
into problems of similar nature.

However, you will in practice probably use CBC or some chaining
mode. Thus, the IV (which will have "full" size) will add 128 bits
randomness, making hits in the database less likely.

With a very short block size, however, the randomness in the IV
might still not bring up the security to the level you would want.

> identifies the boundary between data bits and padding bits.

It seems that random padding would never hurt.

/Mats

>>>>> I haven't noticed any discussion of algorithmic delay associated 
>>>>> with SRTP (and only found one unrelated instance of a keyword 
>>>>> search on delay in the ID). My apologies if this has already been 
>>>>> discussed on the list (I've been unsubscribed for a while). 
>>>>> Specifically, I want to explore the implications for a scenario 
>>>>> like SRTP encrypting a G.723.1 codec output.
>>>>>
>>>>> opposed to a stream cipher mode), it seems that a significant 
>>>>> amount of delay can be incurred to wait for enough G.723.1 frames 
>>>>> to form a complete block against which to apply the block cipher 
>>>>> algorithm. For example:
>>>>
>>>>
>>>>
>>>>> In the good case where the cipher block size is smaller than a 
>>>>> single frame of the codec output, the block cipher incurs zero 
>>>>> algorithmic delay (which would be additive to the 37.5 ms 
>>>>> algorithmic delay of the G.723.1 codec). In a bad case, where the 
>>>>> cipher block size is greater than the codec frame, then the cipher 
>>>>> block processing cannot begin until the cipher block is filled with 
>>>>> two or more codec frames, so an additional 30 ms of algorithmic 
>>>>> delay is introduced for every additional G.723.1 frame required to 
>>>>> fill the cipher block (even if only 2 bits of it are required). 
>>>>> This excludes the processing delay associated with actually 
>>>>> Consider the case where the block cipher was based on 160 bit block 
>>>>> ( n_b =160 from your draft) for a 5.3kbps G.723.1 stream. At T=0, 
>>>>> the digitized voice stream enters the G.723.1 coder. At T=37.5ms 
>>>>> (plus processing delay) the output of the first G.723.1 frame is 
>>>>> available for the block cipher input. Now the frame is only 158 
>>>>> bits and the block cipher expects 160 bits before acting, so we 
>>>>> must wait for another G.723.1 frame 30 ms later, even though we'll 
>>>>> only use 2 bits of it. So at 67.5 ms total algorithmic delay 
>>>>> (inclusive of 37.5ms from the G.723.1 coder function and 30ms from 
>>>>> the block cipher function) we can begin to process the first 
>>>>> complete block of 160 bits, while 156 bits are left in the SRTP 
>>>>> cipher block queue.
>>>>
>>>>
>>>>
>>>> It works like this:  Some number of media frames are assembled into 
>>>> an RTP packet, which SRTP may process by encrypting the payload.  
>>>> SRTP will generate one 16-byte block if the length of the media 
>>>> frames is less than 16 bytes.  In general, I expect that the number 
>>>> of blocks generated for the AES counter mode cipher will not equal 
>>>> the length of the payload - some of the bits will be "left over" and 
>>>> that's not a problem.  This is because SRTP's ciphers work on a 
>>>> stream of blocks.
>>>> Block ciphers can be designed so that there won't be any need to 
>>>> delay the packet to completely use a block.
>>>>
>>>>
>>>>> While this can be addressed through prudent selection of cipher 
>>>>> block size (e.g. n_b equal or less than desired multiple of the 
>>>>> codec frame). It might be nice to highlight this block size 
>>>>> consideration in the draft, as an encouragement to make SRTP 
>>>>> implementations allow the block size to be configured (at least as 
>>>>> a selection among preset choices) rather than being hard-coded in 
>>>>> the implementation. Of course availability of crypto libraries for 
>>>>> given block sizes will also affect such an implementation decision.
>>>>
>>>>
>>>>
>>>> In general, you won't be able to arbitrarily change the block size 
>>>> of the cipher.
>>>>
>>>>

---

From: "David A. Mcgrew" <[email-masked]>
Date: Tue, 5 Nov 2002 03:30:52 -0800

Hi Scott,

it seems like there's already been some good discussion here, but I wanted to
make a quick comment: it is possible to generate the counter mode keystream
segment in parallel with other processing, since the inputs to that cipher are
predictable.  This fact can be used to eliminate most of the delay due to
encryption (in some systems, anyway :-)

David

> -----Original Message-----
> From: Scott Keagy [mailto:[email-masked]]
> Sent: Monday, November 04, 2002 7:54 PM
> To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: SRTP and algorithmic delay
>
>
> Folks:
>

---

From: Scott Keagy <[email-masked]>
Date: Tue, 05 Nov 2002 21:30:33 -0800

Hi David,

I'm stil lentry-level in all this stuff, but is your comment in reference 
to a stream cipher (as opposed to a block cipher)? If that is the case, 
then is a stream cipher easier to hack using fancy statistical techniques 
rather than trying a brute force attack?

On an unrelated note, I've thought about a consideration of voice traffic 
that could make brute-force attacks easier. Given predictable periods of 
silence being transmitted (assuming the vad and silence suppression are not 
used), then a hacker might be able to guess what the intended signal should 
look like part of the time- at least it is less random than other types of 
data because we know the amplitude of the signal will be no greater than 
the background noise about 40% of the time....Easier to exploit with G.711 
codecs than low bit-rate codecs... Definitely not as easy to abuse as 
expecting an encrypted ICMP error message response, but still seems like 
someone with a lot of brain power and time to explore it could prove that 
the advertised cryptographic strength is not quite as strong as assumed 
because of the contiguous packets of silent (or relatively silent periods). 
Would it be simpler to just look for expected bit strings in RTP/UDP/IP 
headers? Maybe this is pretty far-out, but wanted to bounce it off of 
people who understand the issues better than I.

Regards,
Scott

Regards,

Scott Keagy, CCIE# 3985

---

From: Mats Näslund <[email-masked]>
Date: Wed, 06 Nov 2002 11:58:03 +0100

Hi Scott,

David may want to add something (when the US wakes up),
but here is a quick answer:

Scott Keagy wrote:
> 
> I'm stil lentry-level in all this stuff, but is your comment in 
> reference to a stream cipher (as opposed to a block cipher)? If that is 
> the case, then is a stream cipher easier to hack using fancy statistical 
> techniques rather than trying a brute force attack?

I think David's comment argues in favor of streamciphers form
*efficiency* point of view: you can generate the keystream *before*
you see the plaintext, and with countermode you can even do parallel
processing when generating it. What David refers to as "predictable"
is the *input* to the streamcipher (the IV), not the output (or the key).

As for security, see below.

> On an unrelated note, I've thought about a consideration of voice 
> traffic that could make brute-force attacks easier. Given predictable 
> periods of silence being transmitted (assuming the vad and silence 
> suppression are not used), then a hacker might be able to guess what the 
> intended signal should look like part of the time- at least it is less 
> random than other types of data because we know the amplitude of the 
> signal will be no greater than the background noise about 40% of the 
> time....Easier to exploit with G.711 codecs than low bit-rate codecs... 
> Definitely not as easy to abuse as expecting an encrypted ICMP error 
> message response, but still seems like someone with a lot of brain power 
> and time to explore it could prove that the advertised cryptographic 
> strength is not quite as strong as assumed because of the contiguous 
> packets of silent (or relatively silent periods). Would it be simpler to 
> just look for expected bit strings in RTP/UDP/IP headers? Maybe this is 
> pretty far-out, but wanted to bounce it off of people who understand the 
> issues better than I.

This has come up before. As noted above, in a stream cipher the
keystream is generated *independently* of the plaintext. (The
keystream is then XORed onto the message.)

This means that the security of a stream cipher (if it indeed is
secure at all) is independent of the statistical distribution of
the plaintext. Therefore, (secure) streamciphers are designed so that
even if you observe one large "segement" of keystream (e.g. by knowing
what the corresponding plaintext is), previous and later segments
are still computationally indistingusihable from random bits,
hence "unpredictable".

cheers

/Mats

>> with SRTP
>> opposed
>> spec,
>> single frame
>> fill the
>> ( n_b
>> delay)
>> block size
>> reduce
>> will