Mobile voice cryptography
Bubba
in a nutshell, is there any available (preferably Java based, since most
cellulars nowadays support Java) application that allows client to client
voice encryption/decryption?
It has come to my attention that there are certain 3rd party cellular
accessories that use "random rolling code" (I have virtually no experience
in cryptography so this is just quote) for encryption making it
"impervious to 3rd party decoding". How solid are those statements and are
those "contraptions" really efficient?
Any hint would be appreciated.
Best regards,
--
Everything will be okay, in the end.
If it's not okay - it's not the end!
� http://math2.ath.cx �
Ilmari Karonen
>
> in a nutshell, is there any available (preferably Java based, since most
> cellulars nowadays support Java) application that allows client to client
> voice encryption/decryption?
I've no idea. Sorry. Try Google?
> It has come to my attention that there are certain 3rd party cellular
> accessories that use "random rolling code" (I have virtually no experience
> in cryptography so this is just quote) for encryption making it
> "impervious to 3rd party decoding". How solid are those statements and are
> those "contraptions" really efficient?
"Random rolling code" sounds like a funny way of saying "stream
cipher", which, if properly implemented, can indeed be secure.
However, properly implementing a stream cipher is not a trivial
exercise, and one should not assume that a particular product is
secure merely because it is using one.
Indeed, using nonstandard terminology and not providing a detailed
description of the system used could be considered potential warning
signs that the product in question might not be as secure as the
designers would like to have you believe.
--
Ilmari Karonen
To reply by e-mail, please replace ".invalid" with ".net" in address.
Bubba
>> in a nutshell, is there any available (preferably Java based, since
>> most cellulars nowadays support Java) application that allows client
>> to client voice encryption/decryption?
>
> I've no idea. Sorry. Try Google?
Did some light research prior to posting, no particular success, though.
There are certain software products that use 3G package protocols
(GPRS/UMTS and such), but I can make the same thing for free with Skype,
for example. In other words, it is nothing more that VoIP with encryption.
That is not a solution I am looking for.
What I was inquiring about was a regular GSM call and "standard issue"
software package. Hypothetically, is that requirement sane to be asked for
in the first place (Java based software that would handle GSM voice
crypting on the fly)?
> "Random rolling code" sounds like a funny way of saying "stream
> cipher", which, if properly implemented, can indeed be secure.
> However, properly implementing a stream cipher is not a trivial
> exercise, and one should not assume that a particular product is
> secure merely because it is using one.
I suspected something like that.
> Indeed, using nonstandard terminology and not providing a detailed
> description of the system used could be considered potential warning
> signs that the product in question might not be as secure as the
> designers would like to have you believe.
My point exactly; even without any particular knowledge about the
technology, some suspicion arises.
Thank you for your reply.
Peter Fairbrother
> Ilmari Karonen's log on stardate 23 lip 2009
>
>>> in a nutshell, is there any available (preferably Java based, since
>>> most cellulars nowadays support Java) application that allows client
>>> to client voice encryption/decryption?
>> I've no idea. Sorry. Try Google?
>
> Did some light research prior to posting, no particular success, though.
> There are certain software products that use 3G package protocols
> (GPRS/UMTS and such), but I can make the same thing for free with Skype,
Skype encryption is closed - they promised to send me details some time
ago, but haven't - so it's hard to trust. I think Skype can get the keys
if they want to, but I don't know for sure.
> for example. In other words, it is nothing more that VoIP with encryption.
> That is not a solution I am looking for.
The solution you are looking for pretty well has to be VOIP with
encryption, as mobile operators don't pass voice bits in the right way -
and they only encrypt the link between user and mast, whereas you are
looking for end-to-end encryption.
-- Peter Fairbrother
Bubba
>> Did some light research prior to posting, no particular success,
>> though. There are certain software products that use 3G package
>> protocols (GPRS/UMTS and such), but I can make the same thing for
>> free with Skype,
>
> Skype encryption is closed - they promised to send me details some
> time ago, but haven't - so it's hard to trust. I think Skype can get
> the keys if they want to, but I don't know for sure.
Well, it was a mere example, not a serious consideration.
>> for example. In other words, it is nothing more that VoIP with
>> encryption. That is not a solution I am looking for.
>
> The solution you are looking for pretty well has to be VOIP with
> encryption, as mobile operators don't pass voice bits in the right
> way - and they only encrypt the link between user and mast, whereas
> you are looking for end-to-end encryption.
This would imply, in other words, that the device I am being offered is
useless (since it functions as client to client encryption, only hardware
based)?
Technically, though, it would be possible to sample 3.1kHz GSM sound
range, modulate it by a certain pattern (making it impossible to interpret
by human) and then demodulate it on the other side, right? Even by making
simple reversible changes you can make a normal speech unrecognizable to
human ear.
Now it only remains to be seen weather that can be done on the fly with
purely software solution...
Peter Fairbrother
> Peter Fairbrother's log on stardate 24 lip 2009
>
>>> Did some light research prior to posting, no particular success,
>>> though. There are certain software products that use 3G package
>>> protocols (GPRS/UMTS and such), but I can make the same thing for
>>> free with Skype,
>> Skype encryption is closed - they promised to send me details some
>> time ago, but haven't - so it's hard to trust. I think Skype can get
>> the keys if they want to, but I don't know for sure.
>
> Well, it was a mere example, not a serious consideration.
>
>>> for example. In other words, it is nothing more that VoIP with
>>> encryption. That is not a solution I am looking for.
>> The solution you are looking for pretty well has to be VOIP with
>> encryption, as mobile operators don't pass voice bits in the right
>> way - and they only encrypt the link between user and mast, whereas
>> you are looking for end-to-end encryption.
>
> This would imply, in other words, that the device I am being offered is
> useless (since it functions as client to client encryption, only hardware
> based)?
Probably, but it depends on the device and your threat model.
>
> Technically, though, it would be possible to sample 3.1kHz GSM sound
> range, modulate it by a certain pattern (making it impossible to interpret
> by human) and then demodulate it on the other side, right? Even by making
> simple reversible changes you can make a normal speech unrecognizable to
> human ear.
Unrecognisable is not the same thing as secure...
STUs don't use it for instance, they need ISDN/web connections.
>
> Now it only remains to be seen weather that can be done on the fly with
> purely software solution...
>
It can be done, and it has been, most famously iirc in WW2 in a
conversation between Churchill and Roosevelt using two gramophone
records with identical random noise being added to/subtracted from the
speech. Synchronisation was very hard then, but could be done now fairly
easily.
However for real security today VOIP is by far your best and cheapest
bet; a mobile capable of this is cheap enough and 3G is becoming
ubiquitous, and satellite is nearly so unless you are in polar regions.
If you are working in regions where there is only analogue telephone
service, or in a situation where only analogue telephone lines can be
used, the situation may be different - but I don't know of any suppliers
of systems which will do that securely.
-- Peter Fairbrother
Paul Rubin
> What I was inquiring about was a regular GSM call and "standard issue"
> software package. Hypothetically, is that requirement sane to be asked for
> in the first place (Java based software that would handle GSM voice
> crypting on the fly)?
I looked into doing this a long time ago and it didn't appear
possible, because the java applets don't have access to the voice
packets, at least on the phones I know of. Encrypting SMS messages is
much easier and that has been done many times. Voice encryption is
feasible with some so-called "smart" phones set up for internet data
service. There are again quite a few programs that can do it.
I'm not sure what it takes to get point-to-point data through a GSM
voice channel, though I have the impression that it can be done. In
that case, you could use a separate computer (maybe a handheld PDA) to
convert and encrypt the voice data, and just use your phone to move
the bits over the phone network. That is probably more secure anyway,
from the doctrine of red-black separation.
John E. Hadstate
"Peter Fairbrother" <zenad...@zen.co.uk> wrote in message
news:4a417878$0$18244$da0f...@news.zen.co.uk...
> Bubba wrote:
>>
>> Technically, though, it would be possible to sample 3.1kHz
>> GSM sound range, modulate it by a certain pattern (making it
>> impossible to interpret by human) and then demodulate it on
>> the other side, right? Even by making simple reversible
>> changes you can make a normal speech unrecognizable to human
>> ear.
Theoretically, yes. Whether it's technically feasible depends
on the technical details: mainly available computing power to
encrypt and decrypt, and bandwidth to send what is going to be
an essentially uncompressible signal between the two endpoints.
Then there's another issue: once you achieve a secure voice
communications channel, are you using it in such a way as to
compromise security at either end? In other words, what's the
point of a secure channel if one or both of you are using your
cell phones in unsecure places?
>
> Unrecognisable is not the same thing as secure...
>
> STUs don't use it for instance, they need ISDN/web
> connections.
>
This is incorrect, not only for STUs, but also for their later
siblings like STEs and Omnis. They all are designed for secure
voice communications over plain old analog voice circuits, and
I have used them all in this configuration.
Richard Herring
<nick...@banelli.biz.invalid> writes
>Technically, though, it would be possible to sample 3.1kHz GSM sound
>range, modulate it by a certain pattern (making it impossible to interpret
>by human) and then demodulate it on the other side, right?
Only if GSM's speech compression was reversible.
It isn't, so if your "modulated by a certain pattern" sound doesn't have
the statistics of normal speech assumed by the compression, what comes
out at the far end is likely to be very different from what you put in.
--
Richard Herring
David R. Tribble
>> in a nutshell, is there any available (preferably Java based, since
>> most cellulars nowadays support Java) application that allows client
>> to client voice encryption/decryption?
>
Peter Fairbrother wrote:
> The solution you are looking for pretty well has to be VOIP with
> encryption, as mobile operators don't pass voice bits in the right way -
> and they only encrypt the link between user and mast, whereas you are
> looking for end-to-end encryption.
I was going to ask essentially the same question:
Are there any [iPhone] apps for encrypted digital voice
conversations end-to-end (i.e., both the caller and the
callee would need to run the same app on their ends)?
Obviously, this would have to involve some kind of PKI
library and a way to exchange public keys at the start
of a call connection.
I don't know the details of the iPhone architecture, so I'm not
sure if user apps have full access the the voice data stream,
allowing them to insert themselves between the receiver/transmitter
codec streams.
-drt
rossum
<juergen.nie...@arcor.de> wrote:
>Richard Herring <junk@[127.0.0.1]> wrote:
>
>> Only if GSM's speech compression was reversible.
>
>It's not?
>
>I'm pretty sure I hear people talk to me via mobile phone - so surely
>the voice data gets decompressed in some way ;-)
>
>Juergen Nieveler
IIRC the compression is lossy, MP3 style. It leaves out parts of the
original signal that our ears/brains tend to ignore. We can hear it
perfectly well, but it is not an exact duplicate of the original
waveform.
rossum
Richard Herring
Nieveler <juergen.nie...@arcor.de> writes
>Richard Herring <junk@[127.0.0.1]> wrote:
>
>
It's not.
>
>I'm pretty sure I hear people talk to me via mobile phone
But I bet you don't get the impression they are there in the room with
you.
> - so surely
>the voice data gets decompressed in some way ;-)
The compression is lossy. It discards parts of the spectrum on the
assumption that they carry no information (or redundant information)
needed to reconstruct intelligible human speech. If you modulate the
speech, that assumption is invalidated.
--
Richard Herring
Armence
> On 24 Jun 2009 19:53:21 GMT, Juergen Nieveler
>
> >Richard Herring <junk@[127.0.0.1]> wrote:
>
> >> Only if GSM's speech compression was reversible.
>
> >It's not?
>
> >I'm pretty sure I hear people talk to me via mobile phone - so surely
> >the voice data gets decompressed in some way ;-)
>
> >Juergen Nieveler
>
> IIRC the compression is lossy, MP3 style. It leaves out parts of the
> original signal that our ears/brains tend to ignore. We can hear it
> perfectly well, but it is not an exact duplicate of the original
> waveform.
>
> rossum
Then, you just need to use an algorithm that will find that
acceptable. If you're using a stream cipher which generates a key-
stream and then xors the keystream with the plaintext, loosing the
least significant bit of ciphertext will only after the least
significant bit of plaintext. (Assuming you keep synchronization)
Also, if the GSM compression is performed on your phone, you can just
encrypt after compression...