"Symon" <symon_brewer@hotmail.com> schrieb im Newsbeitrag news:43d7a88d$0$15784$14726298@news.sunsite.dk...> > "Antti Lukats" <antti@openchip.org> wrote in message > news:dr88pm$kcp$01$1@news.t-online.com... >> >> receiving voice converted from analog domain, encrypting in digital >> domain and converting into analog domain to be transmitted over an analog >> channel of the same bandwidth is not trivial at least. It is not >> something I would call 'simple'. Our mileage may vary, but I doubt there >> are anyone who would say 'simple' about transmitting encrypted voice over >> low bandwith analog media. If you think its simple go ahead and do it. >> Why wasting timing talking about something that is simple? My advice >> still is that it is of such complexity that you should forget it. If you >> do it wrong then it will be either not secure or not reliable. Doing it >> possible isnt so complex, but being secure, reliable without quality loss >> or analog bandwidth increase is REALLY complex task. >> >> -- >> Antti Lukats >> http://www.xilant.com >> > Antti, > Why can't you use this scheme? Rx voice -> digitise -> MP3 compression -> > encrypt -> a plain old 56 kbps dial-up modem ? > Cheers, Syms. >you can - but doing that with an PLD isnt something I call simple ;) -- Antti Lukats http://www.xilant.com
encryption
Started by ●January 25, 2006
Reply by ●January 25, 20062006-01-25
Reply by ●January 25, 20062006-01-25
"Antti Lukats" <antti@openchip.org> wrote in message news:dr89le$mo5$01$1@news.t-online.com...> "Symon" <symon_brewer@hotmail.com> schrieb im Newsbeitrag >> Antti, >> Why can't you use this scheme? Rx voice -> digitise -> MP3 compression -> >> encrypt -> a plain old 56 kbps dial-up modem ? >> Cheers, Syms. >> > you can - but doing that with an PLD isnt something I call simple ;) > >OK, I understand! And I agree. :-) Cheers, Syms.
Reply by ●January 25, 20062006-01-25
Jan Panteltje wrote:> On a sunny day (25 Jan 2006 05:28:15 -0800) it happened > allanherriman@hotmail.com wrote in > <1138195695.581945.80890@g44g2000cwa.googlegroups.com>: > > >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. > > 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. > > > > >Regards, > >Allan > >P.S. how did you know it was a sunny day here? > 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.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
Reply by ●January 25, 20062006-01-25
Antti Lukats wrote:> 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.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
Reply by ●January 26, 20062006-01-26
Symon wrote:> <allanherriman@hotmail.com> wrote in message > news:1138195695.581945.80890@g44g2000cwa.googlegroups.com... > >>P.S. how did you know it was a sunny day here? >> > > 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.stmYou 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...)
Reply by ●January 27, 20062006-01-27
"John Williams" <jwilliams@itee.uq.edu.au> wrote in message news:newscache$i29qti$1kl$1@lbox.itee.uq.edu.au...> Symon wrote: > >> <allanherriman@hotmail.com> wrote in message >> news:1138195695.581945.80890@g44g2000cwa.googlegroups.com... >> >>>P.S. how did you know it was a sunny day here? >>> >> >> 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 > > 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...) >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.
Reply by ●January 28, 20062006-01-28
On Fri, 27 Jan 2006 11:20:42 +1000, John Williams <jwilliams@itee.uq.edu.au> wrote:>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...)I walk out my front door and I look at the MCG. Regards, Allan
Reply by ●January 28, 20062006-01-28
Allan Herriman <allanherriman@hotmail.com> writes:> > I walk out my front door and I look at the MCG. >When the rain doesn't obscure it.... :-)
Reply by ●January 28, 20062006-01-28
On Fri, 27 Jan 2006 11:47:52 -0000, "Symon" <symon_brewer@hotmail.com> wrote:>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.All you need is "Bluff your way in Cricket" ISBN 1-85304-045-2 Philip LBW Freidin
Reply by ●September 5, 20082008-09-05
hi i want some help i m in my final year of avionics engg i have been give a project to develop a fpga based encryption module for voice comunication can u help me in it yusufil...@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 > > thanks > > > yusuf
