Apple is going to beat all competitors

Ian Stirling OpenMoko at
Fri Sep 7 22:44:47 CEST 2007

Shawn Rutledge wrote:
> On 9/7/07, Raphael Jacquot <sxpert at> wrote:
>>it appear those things are so expensive that I couldn't find any price
>>for it. (searching for "secure cell phone" on google)
>>also, it appears that none of those things can talk to one another, each
>>doing it's little thing.
>>now, if we can have something similar to an STUIII phone, with public
>>keys and stuff (think either using gpg or ca-cert keys), we're on to
>>something that could become a standard.
> It's easy to think first of doing it over a data connection.  But I
> can imagine more of a signal-processing approach.  There is a hash
> function which generates a hopping sequence, and for each hop, some
> different kind of scrambling is applied (processing the audio signal
> through various kinds of filters, convolutions etc.)  So it's an
> audio-to-audio conversion, and fits in the same bandwidth, but the
> audio being sent is unintelligible noise,

Which the GSM codec - because that's what it is designed to do - doesn't 
bother to code very accurately, as it is designed to code voice signals.

Add to this that even if you can predict the code, this is fragile in 
terms of error coding, because the codec is designed so that single bit 
errors make little difference to the voice output, but will make large 
errors in a non-voice like signal.
It is in principle possible to do this, given perfect modeling of the 
codec, infinite computation power, even on channels with bit errors, but 
  not in practice.

It is possible to do this - there was a paper of getting 1300 
bits/second through two GSM codecs in series using a data-driven voice 
synth, and a voice analyser on the other end.

Needless to say - you don't get outstanding quality from 1300bits/second.

More information about the community mailing list