DYI Landline Encryption

[Bohrium]

Here's an idea I came up with for a telephone encryptor:

An A/D converter streams bits of phone microphone audio into a microcontroller. The microcontroller then dumps these into memory until it fills up with 128 bits. When it has done so the microcontroller encrypts those bits (as one block) using the AES algorithm and the recipients key. The microcontroller then spits out the ciphertext as a stream of bits to another A/D converter which goes out to the telephone line.

Simultaneously the reverse is happening on the speaker, except it uses your key.

By using two keys for each channel of communication the security is greatly increased. Also, the faster the microcontrollers and the A/D converters, the higher the sound quality. Both parties must have one of the devices, and also know each others keys for the system to work.

The idea is still in brain storming phase. Anybody think it would work? Any suggestions?

[TheFallen]

yes. The possibility is there. But the AES algorithm. I'd love to have a look at it.

You'll also want to figure how much memory it will take to write that in C (for microcontrollers) How many variables you'd need, and other bits. It's could be a very interesting project. You've also got to figure in some lag into the communications, oh and degradation of quality, high quality A/D converters are expensive.

[s25]

Sounds pretty good, I agree with the key but could you make it work with a gpg encrypted key so you need a pass as well? That should make it more secure as in your lines don't need to be simply captured you must be captured also? Is it within your ability to make such a thing work?

[Bohrium]

s25: Do you mean encrypting the keys for transmission with gpg?
I believe this is certainly within grasp, the circuit is pretty simple so it's just a programming challenge. Either I'll try to do it in C, or if I'm feeling adventurous I might try ASM.

[TheFallen]

FUCK!

I had a really good post there, taking weeks to post a message now...
*stabs the internet*

What I was goign to say was:

voice -> mic -> A/D -> uC -> D/A -> Telephone line ~~~squiggly mess
~~~ Telephone line -> A/D -> uC -> D/A ->speaker -> voice

I'd just transmit the digital squawks, it'd be easier, you lose an A/D and a D/A. I'll give you it makes it more blatant you're using a method of encryption, but good A/D D/As are expensive. It'd also be more tolerant to interference. With that change:


voice -> mic -> A/D -> uC -> Telephone line ~~~squiggly mess
~~~ Telephone line -> uC -> D/A ->speaker -> voice

Both people would need to allow for delays as the uC did it's work, but using the right code and hardware that'd could be significantly reduced.

I think the biggest problem with be the keys, you'd need to enter them with the phone number, or perhaps have a phone book in the encryption device? But they still need to be entered at least once. And they're not short, look at s25's

For all that effort, I'd just use an IM client with encryption, say Miranda IM with OTR (off the record). I've used it with s25 and I'm happy to say it's a piece of piss, on windows! :O

[Bohrium]

Some PIC microcontrollers have USB capabilities. Perhaps the keys could be stored on a flash drive and plugged into the unit. Then the proper key could be selected from a simple LED display or the like.