Apple is going to beat all competitors
OpenMoko at mauve.plus.com
Fri Sep 7 22:44:47 CEST 2007
Shawn Rutledge wrote:
> On 9/7/07, Raphael Jacquot <sxpert at sxpert.org> 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