[guardian-dev] The sound of an encrypted audio stream

Wed Jul 24 20:45:01 EDT 2013

Would you be willing to share the simple tests for word length
statistics you used with CryptoPhone?

Regarding the expense of this type of recovery, the UNC paper uses the
phrase "content independent" to describe a more realistic experiment
that could apply to a non-laboratory environment. The results are
underwhelming, though they show partial recovery around 15%

Then there's this section:

"we assume each packet contains a single frame.
However, some recently designed codecs, such as Skype’s
new codec (dubbed SILK), can vary the number of frames
per packet based on network conditions. It therefore remains
to be seen if the approach outlined herein can be adapted to
that setting; exploring that, however, requires a substantial
data collection effort that is beyond the scope of this work."

I still can't agree with the assertion that every VBR codec known and
unknown with a stream cipher applied to it is broken. This research
definitely shows a threat, but a threat that requires a small army
with many content-dependent constraints.

I think the most interesting part about the UNC paper is their
"content dependent" results show 45% recovery on a corpus of 6300
words where human transcription on acoustic speech averages at 67%! So
if you say “She had your dark suit in greasy wash water all year” over
an encrypted VBR codec stream in a female American English dialect
from the New England territory of the USA, you are a little under
50/50 in terms of the security of your call.

Frank, do you know of any research like this for dialects of the
German language?

-lee

On Wed, Jul 24, 2013 at 8:08 PM, Frank Rieger <frank at ccc.de> wrote:
> 2009: http://www.cs.jhu.edu/~cwright/voip-vbr.pdf
> 2011: http://www.cs.unc.edu/~amw/resources/hooktonfoniks.pdf
>
> And that is just the published stuff. We have ruled out VR codecs 2003 for CryptoPhone after running some simple tests (word length statistics) already. Basing your threat model for any crypto system on "might help today against a script-kiddie" is irresponsible for obvious reasons. VBR does not give a sufficient advantage in telephony to even go near that risk.
>
> Greetings from Berlin,
>
> Frank
>
> ---
>
>
> On 25.07.2013, at 01:28, Lee Azzarello wrote:
>
>> Hello Frank,
>>
>> Are you referring to the two papers published through American
>> universities on the subject? I'm looking for a way to evaluate the
>> development of this science since I don't know of any generic
>> utilities that a script kiddie could use to do phrase recovery on a
>> SRTP stream.
>>
>> From the content of one paper, it sounds like the science is in the
>> development process, rather than a solution to bring truth to the
>> assertion that "encryption over a VBR codec is broken." If you have
>> any conclusive publications on the subject could you share them?
>>
>> Thanks,
>> Lee
>>
>> On Wed, Jul 24, 2013 at 7:18 PM, Frank Rieger <frank at ccc.de> wrote:
>>> VBR codecs should under no circumstances be used for encrypted calls. The science for recovering enough structure to gain partial content information is way too well developed to ignore this. This has been a constant point of trouble with ZRTP-solutions and needs to be handled (crudely) at the phone software level or (better) with a patch to the repsective ZRTP library that rejects VBR codecs based on the header information.
>>>
>>> Best regards,
>>>
>>> Frank Rieger
>>>
>>> ---
>>>
>>> On 23.07.2013, at 22:47, Lee Azzarello wrote:
>>>
>>>> Hello all,
>>>>
>>>> There have been some conversations recently on IRC and on the web
>>>> about VBR audio codecs and plaintext recovery.
>>>>
>>>> It's an interesting conversation and one which will change a lot in
>>>> our times. While I was testing some video call clients, I saw a bug
>>>> between a custom build of Linphone on Android and a nightly of Jitsi
>>>> on OS X where Linphone tried to play back the encrypted audio through
>>>> the speaker without first decrypting it.
>>>>
>>>> This is what a SRTP audio stream sounds like to a wiretap. The codec
>>>> is speex at 16 kHZ, I believe it is VBR but I'm not certain.
>>>>
>>>> http://ge.tt/9FG7Tem/v/0?c
>>>>
>>>> -lee
>>>> _______________________________________________
>>>> Guardian-dev mailing list
>>>>
>>>> Post: Guardian-dev at lists.mayfirst.org
>>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>>>
>>>> To Unsubscribe
>>>>       Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>>>       Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/frank%40ccc.de
>>>>
>>>> You are subscribed as: frank at ccc.de
>>>>
>>>
>>> _______________________________________________
>>> Guardian-dev mailing list
>>>
>>> Post: Guardian-dev at lists.mayfirst.org
>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>>
>>> To Unsubscribe
>>>        Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>>        Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/lee%40guardianproject.info
>>>
>>> You are subscribed as: lee at guardianproject.info
>> _______________________________________________
>> Guardian-dev mailing list
>>
>> Post: Guardian-dev at lists.mayfirst.org
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>
>> To Unsubscribe
>>        Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>        Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/frank%40ccc.de
>>
>> You are subscribed as: frank at ccc.de
>>
>
> _______________________________________________
> Guardian-dev mailing list
>
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>         Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/lee%40guardianproject.info
>
> You are subscribed as: lee at guardianproject.info