encryption

hi,

I would like to implement a secure channel over an unsecure medium.

mic(voice) => A/D conv =>digital, unsecure, unknown comm link => D/A
conv =>voice
analog           Host A/D     digital
                 "other side"

I do not want to encrypt data at the device's digital side
because it is unsecure, and I dont know how to interfere digital data
I don not have access to embedded software, source code etc.
(maybe just after host A/D converter and emulating Host A/D converter
to device,,,maybe) and
every encryption algorithm implemented here can be broken at the other
side I guess.

What I want to do is ;

mic(voice) => A/D conv + cpld or fpga + D/A conv =>A/D conv => unknown
comm link
analog              ecrypt + scramble digital data          voice like
encrypted signal

The Device will see voice freq signal and will transmit them through
channel as if they are real voices.
At this point adding some noise may help a lot.
a little bit noise may fool attackers but human still can understand
what is said.


questions:

what is possible weakness of this system?
I am sure it can be still broken but
how easy to break it?
What kind of tools/approaches  "they" are using ?
Is cpld enough for general data encryption?
(data is human voice so  8Kbps.)
encrytion should be easy so the hacking also....
they: whatever you say  

thanks 


yusuf

I forgot to tell.
Of course at the other side of the link there will be a decryption unit
to convert analog encrypted voice into real voice.

Due to word wrap some text are not aligned in previous post . sorry..

yusuf

yusufilker@gmail.com wrote:

> hi,
> 
> I would like to implement a secure channel over an unsecure medium.
> 
> mic(voice) => A/D conv =>digital, unsecure, unknown comm link => D/A
> conv =>voice
> analog           Host A/D     digital
>                  "other side"
> 
> I do not want to encrypt data at the device's digital side
> because it is unsecure, and I dont know how to interfere digital data
> I don not have access to embedded software, source code etc.
> (maybe just after host A/D converter and emulating Host A/D converter
> to device,,,maybe) and
> every encryption algorithm implemented here can be broken at the other
> side I guess.
> 
> What I want to do is ;
> 
> mic(voice) => A/D conv + cpld or fpga + D/A conv =>A/D conv => unknown
> comm link
> analog              ecrypt + scramble digital data          voice like
> encrypted signal

Such scrambling may produce a lot of higher frequencies
which after being filtered out by the equipment and the
line result in data loss.

Rene

yusufilker@gmail.com wrote:
> hi,
>
> I would like to implement a secure channel over an unsecure medium.
>
> mic(voice) => A/D conv =>digital, unsecure, unknown comm link => D/A
> conv =>voice
> analog           Host A/D     digital
>                  "other side"
>
> I do not want to encrypt data at the device's digital side
> because it is unsecure, and I dont know how to interfere digital data
> I don not have access to embedded software, source code etc.
> (maybe just after host A/D converter and emulating Host A/D converter
> to device,,,maybe) and
> every encryption algorithm implemented here can be broken at the other
> side I guess.
>
> What I want to do is ;
>
> mic(voice) => A/D conv + cpld or fpga + D/A conv =>A/D conv => unknown
> comm link
> analog              ecrypt + scramble digital data          voice like
> encrypted signal
>
> The Device will see voice freq signal and will transmit them through
> channel as if they are real voices.
> At this point adding some noise may help a lot.
> a little bit noise may fool attackers but human still can understand
> what is said.
>
>
> questions:
>
> what is possible weakness of this system?
> I am sure it can be still broken but
> how easy to break it?
> What kind of tools/approaches  "they" are using ?
> Is cpld enough for general data encryption?
> (data is human voice so  8Kbps.)
> encrytion should be easy so the hacking also....
> they: whatever you say


This would be the minimum required to make a "professional-grade" voice
encryptor:


mic => ADC => compress => encrypt => frame =+
                                            |
                                            modem <=> comm link
                                            |
spkr <= DAC <= decompress <= decrypt <= deframe


The compression (i.e. bit rate reduction) is needed because the voice
band modem won't get anything like the 64kbps required by A or mu law
8kHz audio.
Compression is already used for applications such as VOIP and mobile
phones for similar reasons.
For example, G.729 can reduce speech to 8 kbit/s.

The framing is needed because you'll probably use block based
encryption, and something needs to synchronise the blocks.
You will also need to inject and extract packets for key management,
etc.

Note that if the comm link has significant tx-rx crosstalk (e.g. if
it's a regular two wire phone line) you will require a DSP based
crosstalk canceller to get decent modem performance.


The compression, encryption and voice band modem functions could be
carried out in a regular DSP chip.
You will not be able to do this in a CPLD.
Trying to do this in an FPGA might be possible, but so is banging your
head against a wall.


Ask in news:comp.dsp about the modem and compression functions.
Ask in news:sci.crypt about the encrypt and decrypt functions.  (Also
ask about the impact of bit errors in the modem.)

Regards,
Allan

yusufilker@gmail.com wrote:
> hi,

Howdy yusuf,  see below...

> I would like to implement a secure channel over an unsecure medium.
>
> mic(voice) => A/D conv =>digital, unsecure, unknown comm link => D/A
> conv =>voice
> analog           Host A/D     digital
>                  "other side"
>
> I do not want to encrypt data at the device's digital side
> because it is unsecure,

Why do you think it is unsecure?  Hopefully a professor isn't telling
you that, as I believe it's how most governmental and non-governmental
encryption is done.

> and I dont know how to interfere digital data
> I don not have access to embedded software, source code etc.
> (maybe just after host A/D converter and emulating Host A/D converter
> to device,,,maybe) and
> every encryption algorithm implemented here can be broken at the other
> side I guess.

What makes you say that "every encryption algorithm implemented here
can be broken at the other side"?  Why is it easy to break "here" and
not somewhere else?

> What I want to do is ;
>
> mic(voice) => A/D conv + cpld or fpga + D/A conv =>A/D conv => unknown
> comm link
> analog              ecrypt + scramble digital data          voice like
> encrypted signal

I'm not sure what a "voice like" encrypted signal would be, but I'm
pretty sure that if someone could tell that it was voice like, it will
not be secure.  I'm also not sure what the purpose of all the A/D's and
D/A's are, but that's a side issue that doesn't seem important to the
rest of the discussion, so I'll just skip it.

> The Device will see voice freq signal and will transmit them through
> channel as if they are real voices.
> At this point adding some noise may help a lot.
> a little bit noise may fool attackers but human still can understand
> what is said.

I believe that adding randomness (noise) to the input signal/data that
is about to be encrypted is bordering on security by obscurity, which
in theory, adds little to no real protection to a determined attacker.
In practice, you might be able to argue otherwise (maybe that every
little bit of security helps?) - but know that modern cryptographers
like to rely one thing and one thing only: the length of the key.  They
typically use algorithms that are known and respected industry wide.
They use algorithms that have been peer reviewed many times over many
years.

> questions:
>
> what is possible weakness of this system?
> I am sure it can be still broken but how easy to break it?
> What kind of tools/approaches  "they" are using ?

With absolutely no disrespect intended, if you don't know what the
strengths or weaknesses are of a system you are trying to design, or
what kind of attackes someone might make on it, I'm afraid that a
Usenet posting or two probably isn't going to help (even if it were
from an experienced cryptographer, which I'm not).

> Is cpld enough for general data encryption?
> (data is human voice so  8Kbps.)
> encrytion should be easy so the hacking also....

Compressing human voice down to 8 kbit/s requires a little bit of
horsepower.  It would not surprise me if it was beyond the capabilities
of a CPLD, or if it is possible, would require an experienced coder
that is very efficient in how they implement algorithms.

Have fun,

   Marc

On a sunny day (25 Jan 2006 04:20:40 -0800) it happened
allanherriman@hotmail.com wrote in
<1138191640.397630.147570@o13g2000cwo.googlegroups.com>:

>This would be the minimum required to make a "professional-grade" voice
>encryptor:
>
>
>mic => ADC => compress => encrypt => frame =+

Do not forget the anti-aliasing lowpass before the ADC.

>Marc Randolph" <mrand@my-deja.com> schrieb im Newsbeitrag 
>news:1138192752.155593.278520@z14g2000cwz.googlegroups.com...
> yusufilker@gmail.com wrote:
>> hi,
>
> Howdy yusuf,  see below...
>
>> I would like to implement a secure channel over an unsecure medium.
>>
>> mic(voice) => A/D conv =>digital, unsecure, unknown comm link => D/A

Transmitting encrypted voice over band-limited analog link is VERY VERY 
complicated task. If you want secure and reliable connection over analog 
link that does not reduce the quality (eg provides almost the same bandwidth 
as clear channel) then calculate at least one man-year development time. 
Probably more.

I have hacked an secured digital sound transmittion standard once a long 
time ago. It is amazing what has to be done to digitized voice in order to 
hide its nature of being voice data. Anything that is from our world eg 
sound, voice, captured image keeps its characteristics after large amount of 
distortion applied, things like bit swapping/interleaving, xor patterns do 
not change almost anything - methods exist to recover the original.


-- 
Antti Lukats
http://www.xilant.com 

"Antti Lukats" <antti@openchip.org> wrote in message 
news:dr7sh4$2qa$00$1@news.t-online.com...
>
> Transmitting encrypted voice over band-limited analog link is VERY VERY 
> complicated task. If you want secure and reliable connection over analog 
> link that does not reduce the quality (eg provides almost the same 
> bandwidth as clear channel) then calculate at least one man-year 
> development time. Probably more.
>
> I have hacked an secured digital sound transmittion standard once a long 
> time ago. It is amazing what has to be done to digitized voice in order to 
> hide its nature of being voice data. Anything that is from our world eg 
> sound, voice, captured image keeps its characteristics after large amount 
> of distortion applied, things like bit swapping/interleaving, xor patterns 
> do not change almost anything - methods exist to recover the original.
>
>
Although, I think I could get a Linux box with a sound card and a modem to 
send an encrypted MP3 compressed stream over POTS in a lot less than a year. 
Cheap too! You could use ssh and send it over the internet. Perhaps you 
could run Linux on the FPGA's PowerPC?
Cheers, Syms. 

And the low noise preamp, and the low pass filter and power amp for the
speaker, and the DSP-based acoustic echo cancellation, and the analog
noise generator (for the keys) and the controlling microprocessor (if
not using the DSP chip for this) and the power supply components, and
... and ... and.

Naturally, one leaves out some irrelevant details.

Regards,
Allan
P.S. how did you know it was a sunny day here?

Antti Lukats wrote:
> >Marc Randolph" <mrand@my-deja.com> schrieb im Newsbeitrag
> >news:1138192752.155593.278520@z14g2000cwz.googlegroups.com...
> > yusufilker@gmail.com wrote:
> >> hi,
> >
> > Howdy yusuf,  see below...
> >
> >> I would like to implement a secure channel over an unsecure medium.
> >>
> >> mic(voice) => A/D conv =>digital, unsecure, unknown comm link => D/A
>
> Transmitting encrypted voice over band-limited analog link is VERY VERY
> complicated task. If you want secure and reliable connection over analog
> link that does not reduce the quality (eg provides almost the same bandwidth
> as clear channel) then calculate at least one man-year development time.
> Probably more.
>
> I have hacked an secured digital sound transmittion standard once a long
> time ago. It is amazing what has to be done to digitized voice in order to
> hide its nature of being voice data. Anything that is from our world eg
> sound, voice, captured image keeps its characteristics after large amount of
> distortion applied, things like bit swapping/interleaving, xor patterns do
> not change almost anything - methods exist to recover the original.

Obviously, if a design uses poor crypto, then it can be cracked without
too much diffculty.
Even "good" crypto (e.g. AES) can be misused.  It's quite hard to get
right in practice.

I rather like the wikipedia entry on Block Cypher modes of operation
that shows a striking flaw in ECB.
http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

I'm guessing that CTR mode would suit the OP's application.

Regards,
Allan