[jitsi-users] VBR Audio codecs


#1

Are any of the codecs Jitsi uses for audio calls variable bit rate, and if so,
which ones?
I ask because of the findings in the following paper:
Uncovering Spoken Phrases in Encrypted Voice over IP Conversations
http://www.cs.unc.edu/~fabian/papers/tissec2010.pdf


#2

Opus, Silk and Speex are all VBR. If I recall correctly however, the paper
you mention is quite specific to speex.

--sent from my mobile

···

On 25 Jan 2014 3:04 AM, "Asha'man" <ashaman@necryptoconsulting.com> wrote:

Are any of the codecs Jitsi uses for audio calls variable bit rate, and if
so,
which ones?
I ask because of the findings in the following paper:
Uncovering Spoken Phrases in Encrypted Voice over IP Conversations
http://www.cs.unc.edu/~fabian/papers/tissec2010.pdf
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#3

Thanks Asha'man,
this is a rather interesting paper.
They did the experiments with speex, but I don't believe that this is
necessarily specific to speex. However, I don't know enough about the
other relevant codecs to guess whether they are affected by this
particular method or not. I guess this could be figured out rather
easily. I personally am not to worried though, there are several
rather simple countermeasures possible.
I also don't think that it would work as well in practice, for a number
of reasons. However, some organizations might have refined this
technique, so taking countermeasures is probably a good idea.

Regards,
Philipp

···

On Fri, 24 Jan 2014 21:00:31 -0500 Asha'man <ashaman@necryptoconsulting.com> wrote:

Are any of the codecs Jitsi uses for audio calls variable bit rate,
and if so, which ones?
I ask because of the findings in the following paper:
Uncovering Spoken Phrases in Encrypted Voice over IP Conversations
http://www.cs.unc.edu/~fabian/papers/tissec2010.pdf

--
JID: murks@jit.si


#4

It seems to me like it would be better to have those codecs disabled by
default, unless I'm missing something. My knowledge in this area is limited at
best. It's unfortunate that they are the highest quality codecs available.

···

On Saturday 25 January 2014 07:30:41 Emil Ivov wrote:

Opus, Silk and Speex are all VBR. If I recall correctly however, the paper
you mention is quite specific to speex.

--sent from my mobile

On 25 Jan 2014 3:04 AM, "Asha'man" <ashaman@necryptoconsulting.com> wrote:
> Are any of the codecs Jitsi uses for audio calls variable bit rate, and if
> so,
> which ones?
> I ask because of the findings in the following paper:
> Uncovering Spoken Phrases in Encrypted Voice over IP Conversations
> http://www.cs.unc.edu/~fabian/papers/tissec2010.pdf
> _______________________________________________
> users mailing list
> users@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/users


#5

It seems to me like it would be better to have those codecs disabled by
default, unless I'm missing something.

I think you might be. I just mentioned in my previous mail that this
paper is known to be very specific to speex. Codecs like opus and silk
work very differently and personally I have never seen any indications
that the same concerns would apply to them.

(FWIW, future support of bundle and rtcp-mux are going to make such
concerns completely irrelevant.)

Emil

···

On Sat, Jan 25, 2014 at 11:45 AM, Asha'man <ashaman@necryptoconsulting.com> wrote:

My knowledge in this area is limited at
best. It's unfortunate that they are the highest quality codecs available.

On Saturday 25 January 2014 07:30:41 Emil Ivov wrote:

Opus, Silk and Speex are all VBR. If I recall correctly however, the paper
you mention is quite specific to speex.

--sent from my mobile

On 25 Jan 2014 3:04 AM, "Asha'man" <ashaman@necryptoconsulting.com> wrote:
> Are any of the codecs Jitsi uses for audio calls variable bit rate, and if
> so,
> which ones?
> I ask because of the findings in the following paper:
> Uncovering Spoken Phrases in Encrypted Voice over IP Conversations
> http://www.cs.unc.edu/~fabian/papers/tissec2010.pdf
> _______________________________________________
> users mailing list
> users@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#6

Are any of the codecs Jitsi uses for audio calls variable bit rate,
and if so, which ones?
I ask because of the findings in the following paper:
Uncovering Spoken Phrases in Encrypted Voice over IP Conversations
http://www.cs.unc.edu/~fabian/papers/tissec2010.pdf

Thanks Asha'man,
this is a rather interesting paper.
They did the experiments with speex, but I don't believe that this is
necessarily specific to speex. However, I don't know enough about the
other relevant codecs to guess whether they are affected by this
particular method or not. I guess this could be figured out rather
easily. I personally am not to worried though, there are several
rather simple countermeasures possible.

Could you elaborate as to the simple countermeasures? Is they something
that can be directly integrated in Jitsi or combined with other
XMPP/Jingle/SIP apps?

I also don't think that it would work as well in practice, for a number
of reasons. However, some organizations might have refined this
technique, so taking countermeasures is probably a good idea.

Regards,
Philipp

~A

···

On 2014-01-25 12:48, Philipp �berbacher wrote:

On Fri, 24 Jan 2014 21:00:31 -0500 > Asha'man <ashaman@necryptoconsulting.com> wrote:


#7

It's basically the same stuff that's described in the paper, padding in
srtp for example. While technically simple I don't know whether this
would cause compatibility problems. I guess the stuff that Emil
mentioned in his answer is also something to the same effect.

Note that I'm no expert on any of this.

Regards,
Philipp

···

On Sat, 25 Jan 2014 15:10:38 +0100 A L <mail@lechevalier.se> wrote:

On 2014-01-25 12:48, Philipp Überbacher wrote:
> On Fri, 24 Jan 2014 21:00:31 -0500 > > Asha'man <ashaman@necryptoconsulting.com> wrote:
>
>> Are any of the codecs Jitsi uses for audio calls variable bit rate,
>> and if so, which ones?
>> I ask because of the findings in the following paper:
>> Uncovering Spoken Phrases in Encrypted Voice over IP Conversations
>> http://www.cs.unc.edu/~fabian/papers/tissec2010.pdf
> Thanks Asha'man,
> this is a rather interesting paper.
> They did the experiments with speex, but I don't believe that this
> is necessarily specific to speex. However, I don't know enough
> about the other relevant codecs to guess whether they are affected
> by this particular method or not. I guess this could be figured out
> rather easily. I personally am not to worried though, there are
> several rather simple countermeasures possible.
Could you elaborate as to the simple countermeasures? Is they
something that can be directly integrated in Jitsi or combined with
other XMPP/Jingle/SIP apps?

> I also don't think that it would work as well in practice, for a
> number of reasons. However, some organizations might have refined
> this technique, so taking countermeasures is probably a good idea.
>
> Regards,
> Philipp

~A

--
JID: murks@jit.si


#8

Are any of the codecs Jitsi uses for audio calls variable bit rate,
and if so, which ones?
I ask because of the findings in the following paper:
Uncovering Spoken Phrases in Encrypted Voice over IP Conversations
http://www.cs.unc.edu/~fabian/papers/tissec2010.pdf

Thanks Asha'man,
this is a rather interesting paper.
They did the experiments with speex, but I don't believe that this
is necessarily specific to speex. However, I don't know enough
about the other relevant codecs to guess whether they are affected
by this particular method or not. I guess this could be figured out
rather easily. I personally am not to worried though, there are
several rather simple countermeasures possible.

Could you elaborate as to the simple countermeasures? Is they
something that can be directly integrated in Jitsi or combined with
other XMPP/Jingle/SIP apps?

I also don't think that it would work as well in practice, for a
number of reasons. However, some organizations might have refined
this technique, so taking countermeasures is probably a good idea.

Regards,
Philipp

~A

It's basically the same stuff that's described in the paper, padding in
srtp for example. While technically simple I don't know whether this
would cause compatibility problems. I guess the stuff that Emil
mentioned in his answer is also something to the same effect.

Note that I'm no expert on any of this.

Alright, I thought there was something users could do. I guess doing a
VPN connection somewhere first would be an option, although impractical
for most users.

~A

···

On 2014-01-25 15:34, Philipp Überbacher wrote:

On Sat, 25 Jan 2014 15:10:38 +0100 > A L <mail@lechevalier.se> wrote:

On 2014-01-25 12:48, Philipp Überbacher wrote:

On Fri, 24 Jan 2014 21:00:31 -0500 >>> Asha'man <ashaman@necryptoconsulting.com> wrote:

Regards,
Philipp


#9

Also, the paper you mention applies to speex.

--sent from mobile

···

On 25 Jan 2014 3:37 PM, "A L" <mail@lechevalier.se> wrote:

On 2014-01-25 15:34, Philipp Überbacher wrote:
> On Sat, 25 Jan 2014 15:10:38 +0100 > > A L <mail@lechevalier.se> wrote:
>
>> On 2014-01-25 12:48, Philipp Überbacher wrote:
>>> On Fri, 24 Jan 2014 21:00:31 -0500 > >>> Asha'man <ashaman@necryptoconsulting.com> wrote:
>>>
>>>> Are any of the codecs Jitsi uses for audio calls variable bit rate,
>>>> and if so, which ones?
>>>> I ask because of the findings in the following paper:
>>>> Uncovering Spoken Phrases in Encrypted Voice over IP Conversations
>>>> http://www.cs.unc.edu/~fabian/papers/tissec2010.pdf
>>> Thanks Asha'man,
>>> this is a rather interesting paper.
>>> They did the experiments with speex, but I don't believe that this
>>> is necessarily specific to speex. However, I don't know enough
>>> about the other relevant codecs to guess whether they are affected
>>> by this particular method or not. I guess this could be figured out
>>> rather easily. I personally am not to worried though, there are
>>> several rather simple countermeasures possible.
>> Could you elaborate as to the simple countermeasures? Is they
>> something that can be directly integrated in Jitsi or combined with
>> other XMPP/Jingle/SIP apps?
>>
>>
>>> I also don't think that it would work as well in practice, for a
>>> number of reasons. However, some organizations might have refined
>>> this technique, so taking countermeasures is probably a good idea.
>>>
>>> Regards,
>>> Philipp
>> ~A
> It's basically the same stuff that's described in the paper, padding in
> srtp for example. While technically simple I don't know whether this
> would cause compatibility problems. I guess the stuff that Emil
> mentioned in his answer is also something to the same effect.
>
> Note that I'm no expert on any of this.

Alright, I thought there was something users could do. I guess doing a
VPN connection somewhere first would be an option, although impractical
for most users.

~A

>
> Regards,
> Philipp
>

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#10

It all depends on the capabilities of your adversary. There is no
security as such, there is only protection against this and protection
against that. I'm pretty sure that the principle behind this attack was
not discovered in 2010, I guess that a fair number of people were aware
of it long before then. As a consequence I imagine that a number of
potential adversaries have developed similar methods.

I'm not too bothered because I'm sure that the real world attack would
be a fair bit harder than in this setup. The researchers here worked
with distinct, known phrases that were also rather long. They also did
not contain pauses. In the real world there are a lot more phrases,
maybe not all of them known. The phrases might be a lot shorter,
thus harder to distinguish from each other, and there may be pauses at
odd places, so the phrase might not correspond to a sentence. All
those things might make it a lot harder to actually make sense of the
data, but probably not impossible.
Padding to a small set of packet lengths would greatly reduce the
amount of information available to the attacker and thus hopefully
making the attack unfeasible.

Again, this is just my not terribly well founded opinion.

As a user you can switch to some fixed bandwidth codec, but those are
typically older and use a rather low bandwidth all the time, resulting
in a relatively bad speech quality. But maybe it's good enough for your
use case.

Regards,
Philipp

···

On Sat, 25 Jan 2014 15:36:39 +0100 A L <mail@lechevalier.se> wrote:

On 2014-01-25 15:34, Philipp Überbacher wrote:
> On Sat, 25 Jan 2014 15:10:38 +0100 > > A L <mail@lechevalier.se> wrote:
>
>> On 2014-01-25 12:48, Philipp Überbacher wrote:
>>> On Fri, 24 Jan 2014 21:00:31 -0500 > >>> Asha'man <ashaman@necryptoconsulting.com> wrote:
>>>
>>>> Are any of the codecs Jitsi uses for audio calls variable bit
>>>> rate, and if so, which ones?
>>>> I ask because of the findings in the following paper:
>>>> Uncovering Spoken Phrases in Encrypted Voice over IP
>>>> Conversations http://www.cs.unc.edu/~fabian/papers/tissec2010.pdf
>>> Thanks Asha'man,
>>> this is a rather interesting paper.
>>> They did the experiments with speex, but I don't believe that this
>>> is necessarily specific to speex. However, I don't know enough
>>> about the other relevant codecs to guess whether they are affected
>>> by this particular method or not. I guess this could be figured
>>> out rather easily. I personally am not to worried though, there
>>> are several rather simple countermeasures possible.
>> Could you elaborate as to the simple countermeasures? Is they
>> something that can be directly integrated in Jitsi or combined with
>> other XMPP/Jingle/SIP apps?
>>
>>
>>> I also don't think that it would work as well in practice, for a
>>> number of reasons. However, some organizations might have refined
>>> this technique, so taking countermeasures is probably a good idea.
>>>
>>> Regards,
>>> Philipp
>> ~A
> It's basically the same stuff that's described in the paper,
> padding in srtp for example. While technically simple I don't know
> whether this would cause compatibility problems. I guess the stuff
> that Emil mentioned in his answer is also something to the same
> effect.
>
> Note that I'm no expert on any of this.

Alright, I thought there was something users could do. I guess doing a
VPN connection somewhere first would be an option, although
impractical for most users.

~A

--
JID: murks@jit.si


#11

They could use a constant bitrate codec like PCMU or G722 (and thus make
a significant sacrifice in sound quality and bandwidth)

Regards,
Boris

···

On 25/01/14 15:36, A L wrote:

Alright, I thought there was something users could do. I guess doing a
VPN connection somewhere first would be an option, although impractical
for most users.


#12

Also, the paper you mention applies to speex.

To be clear here: The paper used speex as a sample codec. All codecs based
on CELP (Code-Excited
Linear Prediction) or similar techniques are affected. This includes Opus
and SILK.

The slides are better understandable than the paper:
http://www.cs.unc.edu/~amw/resources/hooktonfoniks_slides-extended.pdf

And the best non-technical countermeasure is to make non-uniform noise in
the background (like banging on a pan).

Ingo


#13

Both Opus and SILK come with FEC, which should already add a level of
scrambling. They are also reacting to packets loos which wouldn't be easily
predictable by an eavesdropper. All in all I think the chances of
successful eavesdropping here are comparable to the chance of me swimming
through "La Manche" while singing the free software song.

--sent from my mobile

···

On 25 Jan 2014 4:26 PM, "Ingo Bauersachs" <ingo@jitsi.org> wrote:

> Also, the paper you mention applies to speex.

To be clear here: The paper used speex as a sample codec. All codecs based
on CELP (Code-Excited
Linear Prediction) or similar techniques are affected. This includes Opus
and SILK.

The slides are better understandable than the paper:
http://www.cs.unc.edu/~amw/resources/hooktonfoniks_slides-extended.pdf

And the best non-technical countermeasure is to make non-uniform noise in
the background (like banging on a pan).

Ingo

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#14

How about if Jitsi offers a way to inject some random pattern in the conversation that other side of the jitsi can also detach?

···

25.01.2014, 19:26, "Ingo Bauersachs" <ingo@jitsi.org>:

�Also, the paper you mention applies to speex.

To be clear here: The paper used speex as a sample codec. All codecs based
on CELP (Code-Excited
Linear Prediction) or similar techniques are affected. This includes Opus
and SILK.

The slides are better understandable than the paper:
http://www.cs.unc.edu/~amw/resources/hooktonfoniks_slides-extended.pdf

And the best non-technical countermeasure is to make non-uniform noise in
the background (like banging on a pan).

Ingo

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users