Re: Real-time sound cyphering algorithm

From: David Eather (eather_at_tpg.com.au)
Date: 05/30/05 

Date: Tue, 31 May 2005 00:28:50 +1000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<snip>

Warning. Sarcastic mode should only be turned on when God mode is
correctly engaged,otherwise the recipient is likely to slip into Slap
Down mode without warning. (Words I may yet regret)

BO wrote>
> So, correct me if I'm wrong:

DE wrote>
Is that sarcastic mode I read?

BO wrote>
your solution is to transmit the
> sum of payload-sound plus a 20dB larger crypto-pseudo-random
> noise signal. Then the receiver subtracts off the crypto signal,
> to get the plaintext plus any noise on the transmission. For the
> sound to "be easily distinguished", we want the plaintext sound
> to be 20dB above the noise on the transmission channel. To get
> the payload 20dB above the noise, and the crypto-stream 20dB
> above the payload, we need an audio carrier with a signal-to-
> noise of 40dB, which is 10,000-to-1 in sound power.

IIRC, when I went to school, audio volume was measured in dB - spl
(sound pressure level, which I noted in the pervious post) which is
20 x log10 and not 10 x log10 which is a measure for comparing power
- - you did not do your basic research. Try -

http://en.wikipedia.org/wiki/Sound_unit

Forty dB is a factor of 100.

BO wrote>
> So, correct me if I'm wrong:
<snip>

You are wrong and you are corrected.

As I also mentioned, people interested in the signal can follow if
the signal to noise is 1 dB. I suspect my suggestion can do a little
better than that (my expectation would be +3 to +10 db, perhaps more
with a bit of fiddling). I made 2 assumptions. The first was that
the receiver was interested in the message (or else there is no point
in sending it), and second, that the message was not going to be the
collected works of Emmanuel Kant. Is that unreasonable?

>
> Modern digital methods offer vastly better performance. We can
> transmit easily-intelligible speech at a fraction of the power,

You have not thought about this at all have you? You've just flopped
out the "correct" answer without regard to the circumstance..

The OP implied the transmition of the sound data should occur in real
time when he said:

OP wrote>
I need the cyphered sound to be audible, but not understandable

DE wrote>
This real-time requirement is further suggested by his (OP's) report
of his experiments which appear to be conducted in real time. (If
real time transmition is not an issue then the simplest solution is
to stretch out the transmition time and frequency double the source
as much as necessary to compensate - I assume this was thought of and
discarded)

How are you going to send your data? fiberoptic, radio, coax, UTP?
As another poster pointed out a speaker used for acoustic transmition
has all sorts of phase shifts which will be unpredictable and
unrepeatable unless you want to specify exactly which speaker (not
which brand - which one), sound card, microphone and which
temperature, pressure and humidity conditions apply. You could only
use the most crude forms of phase shift modulation, if any. You'll
be *lucky* if you get an unreliable 20k bits per second. If you use
all of that bandwidth you could just squeeze in a highly compressed
sound and some serious error correction.

> or high-fi stereo music at the same power. Google "turbo codes"
> along with "dB" for more.

Sure, I am aware of turbo codes, use in space craft etc, etc, never
quite got around the math of them (turbo codes), didn't have so much
trouble with all that error correcting stuff that you can do with
shift registers and such - Real Simple Codes. Useful, even if, like
me, you don't have the mind of Solomon. (Too subtle?)

I didn't think that the OP's requirements warranted a complex or
exact result. The OP seemed to have quite limited goals and
resources in mind - but then again, I do know one person who thought
it a good idea to hunt mice with a 12g shotgun (true).
>
>
> The digital method also offers better security than does adding
> pseudo-random noise.

Yes of course. I said that such an approach would be a "perfect
solution" But how well does it fit within the problem put by the OP?

>Both rely on the security of a
> cryptosystem, but the analogue method also assumes that no useful
> information is available in a signal 20dB below the noise.
> "Considered inaudible," "in audio engineering," does not imply
> the level of confidentiality required in cryptography.

What security level was suggested by the OP? 2**64? 2**128? or
something unintelligible to others hearing the source?

OP wrote>
I need the cyphered sound to be audible, but not understandable

DE wrote>
The OP further defined his security boundary with this -

OP wrote>
I tried classical cypher or modifications on the stream:
  -XOR-ing it with a 1 or 4 bytes key.

DE wrote>
The OP specifies "not understandable" with a 1 to 4 byte key

BO wrote>
> So, correct me if I'm wrong:
<snip>

You are wrong and you are corrected.

BO wrote>
>-20dB
> certainly limits the bit-rate, but leaking slowly isn't good
> enough.
>
>
> > The constrains given by the OP don't give much room for a
> "perfect"
> > result - processing in real time and no feedback and it is
> probably
> > safe to assume it is a one time project for an individual.
>
> Cheap mass-market (or used) PC's can do the digital processing,
> and cheap commodity audio systems can handle the analog I/O. In
> terms of software, the modern methods are sophisticated, but the
> hard parts are already done.

Before your post I had already agreed that such a system as you
describe would give a perfect result. It is in every way the
"perfect" and "correct" answer.

The OP talks about security parameters like "not understandable" with
a 1 to 4 byte keys and using classical ciphers.

My roughed out concept is much simpler than yours.
Which one more closely fits the stated requirements of the OP?
Which one is the OP more likely to be able to implement?

OP wrote>
" I tried classical cypher or modifications on the stream:
  -XOR-ing it with a 1 or 4 bytes key. "

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBQpsiRJS9Fk5okqe7EQKP7gCfdYNb1lpgPIouNmzJrxVSnMdAdY8AoLpU
3WBJqwf4FKqHNe1sIuYQEf6F
=KEIB
-----END PGP SIGNATURE-----

Quantcast