encryption

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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


Re: encryption
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


Re: encryption

Quoted text here. Click to load it

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

Re: encryption
Quoted text here. Click to load it


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


Re: encryption
On a sunny day (25 Jan 2006 04:20:40 -0800) it happened
snipped-for-privacy@hotmail.com wrote in

Quoted text here. Click to load it

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



Re: encryption
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?


[OT]Re: encryption
Quoted text here. Click to load it
He's obviously been following the cricket now that Holland have qualified
for the world cup. It looks sunny at the SCG in the picture of Jayasuriya
after he hit a century!
http://news.bbc.co.uk/sport1/hi/cricket/4634280.stm
Cheers, Syms.



Re: [OT]Re: encryption

Quoted text here. Click to load it

You know, there's just not enough talk about cricket on comp.arch.fpga.

Perhaps a new group - comp.arch.fpga.cricket?

John (who travels past the 'Gabba every day on the way to work...)

Re: [OT]Re: encryption
Quoted text here. Click to load it
I'm not sure I'd get to work too often if I had that route to travel. Is the
Gabba WiFi'd?
As for comp.arch.fpga.cricket , I notice a lot of discussion on here about
stuff like metastability in asynchronous fifos, running Linux on FPGA
processors, EULAs/IP litigation. If we can't grasp simple concepts like
that, I'm not sure we're ready to step up to the complexity of the LBW laws
just yet.
Cheers mate, Syms.



Re: [OT]Re: encryption
Quoted text here. Click to load it

All you need is "Bluff your way in Cricket" ISBN 1-85304-045-2

Philip LBW Freidin


Re: [OT]Re: encryption
On Fri, 27 Jan 2006 11:20:42 +1000, John Williams

Quoted text here. Click to load it

I walk out my front door and I look at the MCG.

Regards,
Allan

Re: [OT]Re: encryption

Quoted text here. Click to load it

When the rain doesn't obscure it.... :-)



Re: encryption
On a sunny day (25 Jan 2006 05:28:15 -0800) it happened
snipped-for-privacy@hotmail.com wrote in

Quoted text here. Click to load it

You wrote:
<quote>
 This would be the minimum required to make a "professional-grade" voice
 encryptor:
<quoted>
So tha twas not very professional, as i tshows no knowledge of signal processing.



Quoted text here. Click to load it
I only know you reply to me because of the headers, you forgot to qute
what and who you are replying to.
Not very professional either.

As for the sunny day, try a suitable reference frame.


Re: encryption
Quoted text here. Click to load it
processing.
Quoted text here. Click to load it

Hi Jan,

I don't understand these personal attacks.  What did I do to you?  As
for your "no knowledge" comment, my body of work in a number of fields
(incl. signal processing) speaks for itself and needs no defending.

Have you considered switching to decaf?

Regards,
Allan


Re: encryption

snipped-for-privacy@hotmail.com yazdi:
Quoted text here. Click to load it

Device has its own speaker (and related dsp functions, power, power amp
etc).
LNA, analog LPF, no need to control it is freee running continuous
process.
How to enter encryption keys still thinking about it..


Re: encryption
Quoted text here. Click to load it

Howdy yusuf,  see below...

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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?

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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).

Quoted text here. Click to load it

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


Re: encryption
Quoted text here. Click to load it

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



Re: encryption
Quoted text here. Click to load it
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.



Re: encryption
Quoted text here. Click to load it

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


Re: encryption
Quoted text here. Click to load it

If you digitize voice at a constant bit rate, any reasonable encryption
algorithm with feedback (not ECB mode) will make it impossible to determine
that the encrypted data is voice (vs. something else of the same bit rate)
unless the attacker has the key or can break the cryptosystem.

Single DES (56-bit keey) is not sufficient only because a brute-force
key seach is possible.  AES, triple DES, or many other algorithms would
be suitable.  Personally, I would use triple DES, as DES has withstood
much more cryptanalysis than has yet been applied to AES.

The real problem with secure voice communication is not the encryption
per se; for practical purposes that is a solved problem.  The major
difficulty is key distribution; if you don't do that well, the system
will be susceptible to man-in-the-middle attacks.

Eric

Site Timeline