Encrypting a voice stream when it's silent ?

[Skybuck Flying]

Hello,

I just created a very simple application, which broadcasts voice/wave
buffers/stream to receivers.

I simply added some encryption (aes/rijndael) in stream mode (cbc).

The idea of this encryption is ofcourse to keep whatever is said secret.

However I am in doubt if the encryption can be broken during silent moments
?

What if a potential attacker can somehow detect such a silent moment ?

The attacker would then know the plaintext sort of... and this is always bad
?!

What do you guys think ?

Is AES safe for "silent moments in voice stream" or is it totally unsafe and
something should be added ?!?

Is there an easy solution ?

(Also which mode would be safest for voice stream:
CBC, CFB8bit, CFBblock, OFB, CTR ?)

Bye,
Skybuck.

[rossum]

On Thu, 18 Oct 2012 11:55:01 +0200, "Skybuck Flying"

<Window...@DreamPC2006.com> wrote:

>Hello,
>
>I just created a very simple application, which broadcasts voice/wave
>buffers/stream to receivers.
>
>I simply added some encryption (aes/rijndael) in stream mode (cbc).

I would think that CTR mode is better as a stream mode.

>
>The idea of this encryption is ofcourse to keep whatever is said secret.
>
>However I am in doubt if the encryption can be broken during silent moments
>?
>
>What if a potential attacker can somehow detect such a silent moment ?
>
>The attacker would then know the plaintext sort of... and this is always bad
>?!
>
>What do you guys think ?
>
>Is AES safe for "silent moments in voice stream" or is it totally unsafe and
>something should be added ?!?

AES is completely safe. If there is a "silent moment", then the
attacker will know the plaintext (plainspeech?) and can run a known
plaintext attack. AES is safe against known plaintext attacks.
Knowing the plaintext does not allow the attacker to recover the key.

Any good cypher will resist a known plaintext attack.

>
>Is there an easy solution ?
>
>(Also which mode would be safest for voice stream:
>CBC, CFB8bit, CFBblock, OFB, CTR ?)

I would suggest either AES-CTR or Salsa20. Both will allow you to
paralleise the encryption across as many processors as you have
available. That will obviate any issues with the speed of encryption.
YMMV.

rossum

>
>Bye,
> Skybuck.
>
>
>

[Peter Fairbrother]

On 18/10/12 10:55, Skybuck Flying wrote:
> Hello,
>
> I just created a very simple application, which broadcasts voice/wave
> buffers/stream to receivers.
>
> I simply added some encryption (aes/rijndael) in stream mode (cbc).

??? CBC is not a stream mode.

> The idea of this encryption is of course to keep whatever is said secret.

>
> However I am in doubt if the encryption can be broken during silent
> moments ?

No, it shouldn't be breakable, and silent moments should not be detectable.


You are of course correct to assume that detection of silent moments is
a severe security breach, and you should check that the voice encoder
produces a constant rate stream of bits - if it does not then at the
least speech patterns can be recognised, well enough to identify an
individual speaker for practical (and potentially for legal) purposes,
and some data about content can be derived as well.

I have heard skype has this vulnerability, though I cannot confirm that.
in that it uses a variable rate compression encoder. Not only can
individuals be recognised, but useful data about the words spoken can be
extracted, just from looking at the data rate, especially when the
patterns of speech of the speaker are known.



This requirement for a constant rate bitstream makes compression very
difficult, and does not fit in well with many transmission systems - for
instance, cellphones employ compression and switching techniques so that
in general the transmission is in effect half-duplex, only one-way at
any point in time, switching direction as needed.

They often assume only one person is speaking at a time (must have been
designed by men), or sometimes just that there is no need to transmit
when a person is not speaking.

In many cases you will need to use a data circuit, not a voice circuit.

[]

To get back on point a bit, first if you are using a constant rate
encoder which is constantly connected to a microphone then background
and other noise will ensure that the plaintext signal is not a series of
0000's.

Not that that matters much, as AES is able to encode a series of 0000s
without that being detectable anyway.

[]


As to choice of mode, it's hard to say without knowing more. You don't
seem to have any authentication - if you use a stream mode like CTR then
the output could be xored with something by an adversary to eg whisper
lies in the background...


-- Peter Fairbrother

[Skybuck Flying]

"Peter Fairbrother" wrote in message
news:50802ad7$0$10742$5b6a...@news.zen.co.uk...

On 18/10/12 10:55, Skybuck Flying wrote:
> Hello,
>
> I just created a very simple application, which broadcasts voice/wave
> buffers/stream to receivers.
>
> I simply added some encryption (aes/rijndael) in stream mode (cbc).

"
??? CBC is not a stream mode.
"

Indeed CBC seemed to fail over the internet.

Does AES have a streaming mode ?

"
As to choice of mode, it's hard to say without knowing more. You don't
seem to have any authentication - if you use a stream mode like CTR then
the output could be xored with something by an adversary to eg whisper
lies in the background...
"

Ok so CTR is supposed to be a streaming mode...

I will try that next... but I will have to switch to UDP anyway, because
TCP/IP requires port forwarding for NAT devices, and some people don't know
how to do that... at least with UDP this can be somewhat automated on the
application side.

But I will first try AES CTR + TCP/IP to see it in action ;)

Bye,
Skybuck.