Searching \ for 'interesting concept' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=interesting+concept
Search entire site for: 'interesting concept'.

Truncated match.
PICList Thread
'interesting concept'
1999\03\28@212436 by Ryan Pogge

flavicon
face
found this on a newsgroup
is it possible?

--snip--
I wish to build a device which could intercept an analogue signal and
convert it.

A/D Converter > PIC circuit > D/A Converter

The idea I have is to develop a "black box" which could effectively scramble
a telephone conversation making it totally private.  I would use the PIC
processor to perform the encryption.

I have written source code in 8086 which compresses data at bit level, I
don't think it would be convert.

My question being, could a single PIC processor work fast enough to perform
the algorithm in real-time?, I would assume 11Khz mono signal capabilities
would be sufficient.


Regards

1999\03\28@215003 by list

flavicon
face
I would be very interested in this project.!!!!!

spam_OUTTomTakeThisOuTspamcomtronix.com

> found this on a newsgroup
> is it possible?
>
> --snip--
> I wish to build a device which could intercept an analogue signal and
> convert it.
>

1999\03\28@221736 by Ryan Pogge

flavicon
face
I know it sound awsome =]
I just saw it on a newsgroup and copyed and pasted it to here....
I just thought maybee it would inspire someone to do it.
Shouldent be too hard... I have too many other projects though..not enough
time.

{Quote hidden}

1999\03\28@222948 by Wagner Lipnharski

picon face
In real you don't need to convert much, just scramble it in time, or
revert polarity for odd and even byte count readings.  11ksps
(samples/second) in 8 bits is pretty enough for telephone conversations,
you can store 20 or more bytes, then transmit them in a different
sequence.  The only problem will be to send the sync code to the
receiver so they could synchronize and decode the cripto correctly. :)
Wagner.

Ryan Pogge wrote:
{Quote hidden}

1999\03\28@225854 by Regulus Berdin

picon face
A XOR scrambling/descrambling will do.  Synchronization is not needed.

regards,
Reggie

Wagner Lipnharski wrote:
>
> In real you don't need to convert much, just scramble it in time, or
> revert polarity for odd and even byte count readings.  11ksps
> (samples/second) in 8 bits is pretty enough for telephone conversations,
> you can store 20 or more bytes, then transmit them in a different
> sequence.  The only problem will be to send the sync code to the
> receiver so they could synchronize and decode the cripto correctly. :)

--
e-mail: rberdinspamKILLspambigfoot.com
ICQ#:   31651436
URL:    http://www.bigfoot.com/~rberdin

1999\03\28@235558 by Tjaart van der Walt

flavicon
face
Ryan Pogge wrote:
>
> found this on a newsgroup
> is it possible?
>
> --snip--
> I wish to build a device which could intercept an analogue signal and
> convert it.
>
> A/D Converter > PIC circuit > D/A Converter
>
> The idea I have is to develop a "black box" which could effectively scramble
> a telephone conversation making it totally private.  I would use the PIC
> processor to perform the encryption.

This can indeed be done, but watch out for bandwidth
increase in the scrambled audio, because your telephone
company still chops the signal at 3kHz...

A Scenix SX will give you extra horsepower for the
encryption and the decryption.

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
.....tjaartKILLspamspam.....wasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
| Mobile : EraseMEtjaartspam_OUTspamTakeThisOuTsms.wasp.co.za  (160 text chars) |
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\03\29@091030 by Andres Tarzia

flavicon
face
mmm... letme see... I'd use a 20Mhz part like the 16C74 or a similar one.
A/D conversion time should be something like 16us (microseconds, please
don't start another thread on units here). That's enough for over 60000+
conversions per second. For telephony applications, 8000 conversions per
second is enough, so you have 125us to "process" each byte. That is about
625 instruction cycles in a 20Mhz part. Of course, that includes interrupts,
main program, and everything else.

Depending on how you plan to actually transmit the data over the phone line,
I'd say that you have a good chance of making it.

Now that I think about it, how on earth do you encode the digital data for
transmitting? Use a modem to handle the connection?

Regards
Andres Tarzia
Technology Consultant, SMART S.A.
e-mail: atarziaspamspam_OUTsmart.com.ar

{Original Message removed}

1999\03\29@104813 by Wagner Lipnharski

picon face
Yes, you are right.
The timed scramble is just to increase substantially the security.

There are some formulas and algorithms that can track the human voice
based on tendencies and known wave sequences. Something like that is
used to compress human voice, as well, to identify voice commands.

I you take a phone talking recording scrambled only with XOR, a computer
program based on that algorithms can find the XOR used in some time. A
timed scrambled takes much longer.

Some military systems use side band codification, frequency (pitch)
modulation, timed scramble and coded waves (a set of pre-programed waves
at each side, it just send the wave name whenever the system recognize a
similarity with that wave).

For common and simple scramble (to avoid someone to hear the
conversation at the extension phone or with clips at the phone wires), a
simple XOR system works pretty well.

Regulus Berdin wrote:
{Quote hidden}

1999\03\29@111735 by Wagner Lipnharski

picon face
Well, you don't need to worry about how many conversions the PIC would
do, it needs to do something bigger than 8ksps... if you think that the
middle of the phone line freq band is around 1.5kHz, it would give you
aprox 6 samples per senoid, well, not sooo bad.

The PIC would be reading the ADC, XORing the byte, send it to the DAC,
it can do it in 8ksps, 12ksps or 20ksps, doesn't matter, higher the
better, you don't need to limit the PIC speed doing this.  The only
problem (already said by Tjaart) is that you will deform the sound wave
from its original characteristics, creating sharp angles and big phase
changes, this is purelly high frequency, and the phone circuits will
just "cut" that.  So, if your sound encripted signal is a stable flat
signal and the scramble routine XOR a reading and the output will be a
square pulse of 125us, (1/8000) chances are the phone lines will clip
that pulse, it will not arrive at the destination.

To understand it better, just make a list of 256 numbers, from zero to
255, and print at the side of each entry its correspondent XOR value.
Now imagine a senoidal signal that travels from 0 to 255 (8 bits ADC)
and plot how the output XOrid signal would be based on the XOR values.
Imagine that senoidal signal is 2kHz, so anything that would be faster
than twice that senoid would start to be clipped... what would arrive at
the other phone?

Modems use that technique to produce higher transfer rate, using only
2400 baud rate, it modulates in phase and amplitude a senoidal signal of
only 2400Hz.  But they use lots of high frequency filters and things at
the reception, to just recreate the original transmited signal...

So, probably a good cripto unit is just use two 28800bps modems, huh? :)

Wagner.

Andres Tarzia wrote:
{Quote hidden}

> {Original Message removed}

1999\03\29@131604 by Gerhard Fiedler

picon face
At 11:16 03/29/99 -0500, Wagner Lipnharski wrote:
>So, probably a good cripto unit is just use two 28800bps modems, huh? :)

28.8kbps <= 3.6kBps, that's 1.8kHz at most, without compression. you
probably can understand each other -- =if= you get a 28.8k connection :)

ge

1999\03\29@141809 by Wagner Lipnharski

picon face
Yes, the quality is really bad, you can check it out with RealAudio
radio stations transmitting (online) audio, it looks like a very old and
terrible phonograph...
They use some compression and other things, but it doesn't help much.
Wagner.

Gerhard Fiedler wrote:
>
> At 11:16 03/29/99 -0500, Wagner Lipnharski wrote:
> >So, probably a good cripto unit is just use two 28800bps modems, huh? :)
>
> 28.8kbps <= 3.6kBps, that's 1.8kHz at most, without compression. you
> probably can understand each other -- =if= you get a 28.8k connection :)
>
> ge

1999\03\29@141819 by Arnie Grubbs

flavicon
face
At 09:18 PM 3/28/99 -0500, you wrote:
>--snip--
>I wish to build a device which could intercept an analogue signal and
>convert it.
>
>A/D Converter > PIC circuit > D/A Converter
>
>The idea I have is to develop a "black box" which could effectively scramble
>a telephone conversation making it totally private.  I would use the PIC
>processor to perform the encryption.
>

    Another way to do voice scrambleing would be to do frequency inversion
of the audio around a central inversion frequency. The inversion freq.
should be varied continualy to prevent decoding with simple circuits.

This could be done with a few op-amps and cmos analog switches and
of course a PIC to generate the frequency to drive the analog circuits and
also to calculate the pseudo-random numbers used to vary the inversion freq.
If I remember right, you would only need 3 IC's other than the  µ controler.

The PIC would also be in charge of sync'ing up with the 'other end' of the
conversation.  the number of bit's used to 'seed' the pseudo-random would
be the number of different 'scramble codes' that your device could use.

Since the µcontroler is not tied up doing a lot of A/D, math, and communicating
with a D/A,   the speed of the processor is not that critcal.  A  PIC with
a slower
clock speed could do it

I have a schematic of  such a device, used on voice scrambleing of 2 way radio,
it uses a 6805, but the analog section could be used with a PIC instead of
the '05.
This circuit used a data burst every so couple of seconds to insure the Rx
end stayed in sync.
so there is also the circuitry to do the data burst and also some to mute
the data burst so
that the RX end does not have to listen to the burst.

 Anyone interested in this drawing drop me a note   off list  and I will
send you the analog
portion of the schematic.  Its about an 80k JPEG.

1999\03\29@173316 by William Chops Westfield

face picon face
   >So, probably a good cripto unit is just use two 28800bps modems, huh? :)

   28.8kbps <= 3.6kBps, that's 1.8kHz at most, without compression. you
   probably can understand each other -- =if= you get a 28.8k connection :)

28.8kbps is half of the bandwidth normally allocated to a voice call in the
USA.  I understand you can get intelligable voice at 8kbps.  So, yeah,
reasonable "casual" scrambling could be achieved by digitizing and sending
via data modem...

BillW

1999\03\29@175811 by Gerhard Fiedler

picon face
At 14:31 03/29/99 -0800, William Chops Westfield wrote:
>28.8kbps is half of the bandwidth normally allocated to a voice call in the
>USA.

how do you mean that? 28.8kbps is no bandwidth, though it may use one...

>I understand you can get intelligable voice at 8kbps.

have you tried that? without a good compression/decompression algorithm?
simple 8bit sampling at, say, 4ksps (which gives an upper limit of 2kHz)
makes for 32kbps. so in order to understand something with only 8kbps, you
have to employ some serious compression (which in a short term average has
a min. 4:1 ratio). not impossible, but maybe not so easy either (for a PIC
in a handheld=low power device).

ge

1999\03\29@181239 by William Chops Westfield

face picon face
   > 28.8kbps is half of the bandwidth normally allocated to a
   > voice call in the USA.

   how do you mean that? 28.8kbps is no bandwidth, though it may use one...

Huh?  28.8kbps is exactly a bandwidth.  A normal phone conversation uses
56kbps of digital bandwidth on a TDM "fabric" between the speaker and
listener.

   >I understand you can get intelligable voice at 8kbps.

   have you tried that? without a good compression/decompression
   algorithm?  simple 8bit sampling at, say, 4ksps (which gives an upper
   limit of 2kHz) makes for 32kbps. so in order to understand something
   with only 8kbps, you have to employ some serious compression (which in
   a short term average has a min. 4:1 ratio). not impossible, but maybe
   not so easy either (for a PIC in a handheld=low power device).

Yes, to get 8k and reasonable quality you need pretty good compression.  I
don't know about "serious" compression, though - I've gotten the impression
that you can buy chips (not too expensive, either) that will change voice
into an 8kbps bitstream.  Keep in mind that the quality of a typical phone
call is pretty good - WAY above "intelligable" - you can SING over the
phone and people who know you can still recognize your voice.  You can get
(moderately poor) VIDEO over a full 56k...

BillW

1999\03\29@191230 by Gerhard Fiedler

picon face
At 15:11 03/29/99 -0800, William Chops Westfield wrote:
>    how do you mean that? 28.8kbps is no bandwidth, though it may use one...
>
>Huh?  28.8kbps is exactly a bandwidth.  A normal phone conversation uses
>56kbps of digital bandwidth on a TDM "fabric" between the speaker and
>listener.

i thought of bandwidth more in the traditional sense of "width of a
frequency band", where the 28.8kbps would be transmitted in 3 point
something kHz bandwidth. (BTW, the data rate on a PSTN digital channel is
64kbps: 8000 8bit samples/s -- the 56kbps on a V.90 transmission stem
primarily from limitations of the DAC on the receiver side.)


>Yes, to get 8k and reasonable quality you need pretty good compression.  I
>don't know about "serious" compression, though

in my use of the word, "serious" compression was meant to mean "pretty
good" compression. (seemingly, this expression is not quite clear to
everyone, but excuse me: i'm no native speaker, and i may use every now and
then expressions which need a "good will" interpretation.)

>you can buy chips (not too expensive, either) that will change
>voice into an 8kbps bitstream.

know of any?

ge

1999\03\29@192831 by wagnerl

picon face
> >you can buy chips (not too expensive, either) that will change
> >voice into an 8kbps bitstream.
>
> know of any?

... perhaps a nice AtMega103 with the internal 10bits ADC... :)
   but first we need to define if it would be 8kbps or 8kBps...
   or 8ksps...  hehe
Wagner

1999\03\30@070217 by mlsirton

flavicon
face
Hi,

> > >you can buy chips (not too expensive, either) that will change
> > >voice into an 8kbps bitstream.
> > know of any?

These are generally known as codecs (coders/decoders?) and are
targetted specifically for telephony applications.  TI makes quite a
few and so does National Semiconductor, search their web sites for
codec and you should come up with quite a few devices.  Usually you
get on-chip filters too.

I've had this idea regarding voice encryption and since I'll probably
never do anything with it here it is:
1. Sample a voice segment
2. FFT
3. permutate the result according to your key (shuffle it around)
4. Reverse FFT
5. Output
6. Generate next key.

The resulting signal is still within the same band (i.e. no out of
band frequencies are added), synchronization can be achieved either
by timing from the beginning of the session or by "marking" each
segment with some frequency domain code.  Decoding is ofcourse the
reverse permutation.

Anyone got code for FFT on a PIC?

What do you think?

Guy - RemoveMEmlsirtonTakeThisOuTspaminter.net.il

1999\03\30@073003 by Andres Tarzia

flavicon
face
Guy,

That seems like a good idea.
The problem is that you DON'T have a "perfect" analog channel. What will you
do with noise? That will affect the transmitted signal. The receiver will
have a different signal than the transmitter intended.
In "normal" telephony, you may hear "clicks" or other strange noises, but
that is not critical, only annoying.
But if you transmit "scrambled" audio, then what will happen if the signal
is altered in transit? You will FFT, descramble and reverse FFT a different
signal, and I think that the output from that will be meaningless...

Sorry to play the devil's advocate...

Regards,
Andres Tarzia
Technology Consultant, SMART S.A.
e-mail: spamBeGoneatarziaspamBeGonespamsmart.com.ar

{Original Message removed}

1999\03\30@075452 by Tjaart van der Walt

flavicon
face
Guy Sirton wrote:
>
> Hi,
>
> > > >you can buy chips (not too expensive, either) that will change
> > > >voice into an 8kbps bitstream.
> > > know of any?

With a good comparator, you can probably do it in a PIC. If you ask
Walter very nicely, he might post his amazing A/D bitstream sampling
method. As a side-effect, you also get the bitstream equivalent of
the analogue value.

I've been tempted to post it a few times, but it is Walters' call.


--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
TakeThisOuTtjaartEraseMEspamspam_OUTwasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
| Mobile : RemoveMEtjaartspamTakeThisOuTsms.wasp.co.za  (160 text chars) |
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\03\30@083447 by Walter Banks

picon face
----------
From: Tjaart van der Walt <tjaartEraseMEspam.....WASP.CO.ZA>

> > > >you can buy chips (not too expensive, either) that will change
> > > >voice into an 8kbps bitstream.
> > > know of any?

> With a good comparator, you can probably do it in a PIC. If you ask
> Walter very nicely, he might post his amazing A/D bitstream sampling
> method. As a side-effect, you also get the bitstream equivalent of
> the analogue value.

> I've been tempted to post it a few times, but it is Walters' call.


It is on Byte Craft's WEB site at
  http://www.bytecraft.com/addaconv.html

Walter Banks

1999\03\30@083702 by mlsirton

flavicon
face
Hi,

On 30 Mar 99 at 9:30, Andres Tarzia wrote:
<snip>
> The problem is that you DON'T have a "perfect" analog channel. What will you
> do with noise? That will affect the transmitted signal. The receiver will
> have a different signal than the transmitter intended.

Sure.  But you do have a "reasonable" analog channel (how's that for
a theoretical definition?).  The receiver will have a "close enough"
copy of the original signal.  In practice if we look at the signal in
the same point of time (relative to start) it's "highly likely" that
a frequency component present in the original signal will also be
present on the other end.  (How else would we hear each other...)
We need to choose a large enough "block" size so occasional jitters
in the time domain will only affect the edges of the block (or code
the blocks in some manner). Our frequency bins should also be large
enough to withstand some frequency domain distortion.

> In "normal" telephony, you may hear "clicks" or other strange noises, but
> that is not critical, only annoying.

Yeah, these clicks will just be in different frequencies, who knows,
it might even improve the perceived quality...  We can market this as
a click removal device... :-)

> But if you transmit "scrambled" audio, then what will happen if the signal
> is altered in transit? You will FFT, descramble and reverse FFT a different
> signal, and I think that the output from that will be meaningless...

Altered in what way?  Since we can still understand each other over
the phone it shows we have something to work with.

> Sorry to play the devil's advocate...
That's ok...

Just to try the concept it should be pretty easy to simulate the
system.  Start with sampled voice, "encrypt", send through a
simulated phone line (add clicks, jitters, some noise etc.),
"decrypt" and see what gives...

Since there's a lot of redundancy in the voice signal it can take
quite a bit of torture and still be intelligible (sp?) ...  This is
also a weakness since it gives the breakers more to work with.

Guy

1999\03\31@132328 by Mik Kim

picon face
Sorry, but that encryption won't work in 8kbps codecs. From what little
I know, the codecs work on vocal track model of human speech generation
using only few poles for formants (resonance points of "tubes"). If you
permute the signal, you lose the formant characteristics and the output
won't be well coded by all pole model.

Since the codecs code speech information rather than the whole
bandwidth, changing the speech will have some detrimental effects. This
is why the codec based phones are so poor for complex sounds, such as
music (and high pitched sound, but that's another story). Your
encryption could work (maybe) using waveform coders, like 32kbps ADPCM
or 64k mu/a-law.

A better encryption would be to take the data after speech coding and
then permute. Such systems are already used in cell phones; GSM uses
conventional cryptography (I think AC5), and CDMA has encryption
"built-in" to its modulation scheme.

Again, I'm not sure about any of this, but it sounds reasonable.
Afterall, what does an unemployed bum know anyway?

Date:    Tue, 30 Mar 1999 13:57:17 +0000
From:    Guy Sirton <EraseMEdansoftspamMAIL.INTER.NET.IL>
Subject: Re: interesting concept

Hi,

> > >you can buy chips (not too expensive, either) that will change
> > >voice into an 8kbps bitstream.
> > know of any?

These are generally known as codecs (coders/decoders?) and are
targetted specifically for telephony applications.  TI makes quite a
few and so does National Semiconductor, search their web sites for
codec and you should come up with quite a few devices.  Usually you
get on-chip filters too.

I've had this idea regarding voice encryption and since I'll probably
never do anything with it here it is:
1. Sample a voice segment
2. FFT
3. permutate the result according to your key (shuffle it around)
4. Reverse FFT
5. Output
6. Generate next key.

The resulting signal is still within the same band (i.e. no out of
band frequencies are added), synchronization can be achieved either
by timing from the beginning of the session or by "marking" each
segment with some frequency domain code.  Decoding is ofcourse the
reverse permutation.

Anyone got code for FFT on a PIC?

What do you think?

Guy - RemoveMEmlsirtonEraseMEspamEraseMEinter.net.il


Get Your Private, Free Email at http://www.hotmail.com

1999\03\31@135255 by tefan Ranguelov

flavicon
face
Hi !




Ryan Pogge wrote:

> I wish to build a device which could intercept an analogue signal and
> convert it.
>
> A/D Converter > PIC circuit > D/A Converter
>

This implies for the whole chain :

A/D 1 -> PIC 1 -> D/A 1 -> Phone Line -> A/D 2 -> PIC 2 -> D/A 2

While transmitted over the phone line, some noise will be added,
maybe the signal will get amplified. The A/D 2 will sample the signal
not syncronus to D/A1. So PIC2 will never see the same samples as
sent by PIC1. If this small changes run trough the XOR
they will be distributed over the whole amplitude range - small
changes in the Phone line - large changes in the signal. I have not
tried it, but i don't thing XOR is a god choice.

(For scrambling ASCII Text XOR is definitly not a secure encription)

There are some technics for scrambling audio. So you can split the
signal in some frequency bands and permutate them. This can be done
either digital with FFT or analog with filters for separating the bands
and mixers for shifting or mirroring the frequency bands. Since this
method exists for years i don't know how secure it is.


The bandwith of the phone line is limited at 3,4 kHz, so the signal
can be sampled with 8 ksamples/s , each sammple 8 bit, nonlinear.
( gives 64 kbytes/s )

What about this arangement :

A/D -> Processor 1 -> Modem -> Phone Line -> Modem -> Processor 2 -> D/A

So Processor 2 will see exactly the same bytes sent by Processor 1.
( I dont say PIC 1 because i am not sure if it can be all don by a PIC)

The Processor have first to compress the audio signal to a bit rate that
can be transported over the modem and then aplay an encryption
algorithm.

This is exactly what the program PGPPhone does on a PC. You may search
for
it on the WEB to see how they do this.

For a compressiom algorithm you may look at :

http://kbs.cs.tu-berlin.de/~jutta/toast.html

For the encryption you may use every well-known symeric algorithm like
3DES, Blowfisch, RC5 or IDEA.

With a Public key algorithm you even coul'd transfer a key befor a
communication.

For cryptography algorithms you may search the WEB, at :

http://www.informatik.hu-berlin.de/~ranguelo/list.html#Hack

I have collected some links. A good starting point is :

http://www.counterpane.com/publish.html





Just my 2 cents ...
st.


'interesting concept'
1999\04\02@032018 by Dr. Imre Bartfai
flavicon
face
Hi,
the described approach convinces me as I had also doubt agains XOR w/o any
resynchronisation. Could somebody recommend some kind of modem chip to
integrate into the described application?
Imre


On Wed, 31 Mar 1999, Stefan Ranguelov wrote:

{Quote hidden}

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...