About 20 years ago I saw construction plans for an analogue telephoner scrambler in the local radio-amateur magazine. It worked on the principle of frequency spectrum reversal - low frequencies became high and vice-versa. Primitive and highly ineffective against government snooping but good enough against your kids/parents/spouse/great aunt eavesdropping on the parallel line. The voice would become an incomprehensible screeching noise that, even for those knowing how it was generated, was impossible to understand without a descrambler. Yet it stayed in the same frequency spectrum as the original voice and as such was transmitted over a normal telephone line without any additional equipment. Another advantage was that the scrambling was symmetric, i.e. the scrambler and the descrambler were the same thing.

I could not find the plans in a 2 minute duckduckgo (Google for the clueless ones) session but I found at least two dozen commercial products, some of them looking like they are based on the same design.

I imagine something like that should be easy to make a pulseaudio plugin for. The other party could then use a similar plugin or a simple black box.

You touched on some very good points (estel).

The vpn/encryption is merely redundancy, and an extra blanket in the event vpns aren't as (relatively) secure as we think. Back doors, weak passcodes/encryption methods, etc, etc.

And yes, over a vpn link i guess you wouldn't need a voip gateway, since they are on the same "virtual" lan in a sense.

I think it would be fantastic if someone devised a small pass through box, along with the hardware/software to go along with it, that encrypted/decrypted your average ptsn phone data end to end. Something cheap, easy to use, and simple for the masses. Like the digital converter box from the analog tv switchover a few years back.

Obviously without the federal backing, but with all this nsa data mining stuff in the news, you might just get enough public support to bi&#h-slap the intelligence agencies and see how they react.

If you wanted to cut out the simple/easy, i bet you could whip something up with an arduino relatively cheaply that would do that too.

More of an activism/symbolic thing that the people are not ok with dragnets and databases of all our personal data. Be it phone metadata, content, or the fiber-splitters on the IP backbone lines att (and almost certainly the rest of the us telecos) have let the nsa operate since 2006.

You want a simple black-box product?

http://www.homespy.com/12_HS_MG_CELLSCRAMBLER.php
http://www.surveillance-safety.com/c...-scrambler.htm
https://duckduckgo.com/?q=phone+scrambler

A few years ago I for a short while worked on a design using an Atmel(same as on an Arduino) based plug and play encryption widget for VHF walkie talkies that was jacked in between an external mic/speaker and the radio which encrypted the Speex codec based audio stream. The biggest hurdle for my group was a secure and verified but quick handshake. The other issue was when there was a bad signal instead of getting static you would just loose the signal until you could make a good crypto handshake.
A plugin like this would work also fine for POTS if you had the correct matching circuits, or use a voice modem to import the audio to the computer.
I did RF issues not programming so I don't know exactly how it was packaged.

anyone looked @ porting redphone from android?

Instead of external things, we could just use our trusty N900 - using bytes-> tones conversion, it could send pre-encrypted data over any analog voice, be it internal GSM modem (aka normal call), or 5$ PSTN phone super-easily modified - replacing speaker and mic with 4-part 2.5mm jack, that we would put into N900 headphone socket. N900's sound output would go to PSTN phone mic input, and PSTN speaker output, would be redirected to N900's mic input.

N900 would take our encrypted (by whatever software we like) data (be it file, voice message, whatever), and convert bytes to tones. Tones would get send via voice link, and transformed into data on another N900, at opposite side of conversation.

In every case, both or one of N900's could get replaced by computer with same FOSS software installed (our data-to-tones converter).

Tones are quite resistant to noise (that's why they were used in early times of telephony, when lines were not so clear), and of course, data->tones transformation would contain adjustable % of "repair data", like some zip archives (in case part of message was translated with mistakes). Benefit of this approach, is that we don't care about integrating encryption into tones - we're just plain sending data as tones, not caring if bad guys are able to decode them into bytes, easily. The thing is, that data is encrypted *before* getting transformed into tones (and decrypted *after* transformation back to data, at receiving side).

It would be rather similar to sending "mail" than real-time conversation - I don't think you can send comprehensive set of tones fast enough, to make it real-time.

Additional benefit, is that we can send it by *any* means of sound transfer - modified PSTN phone is just and example, it can be ham radio, walkie-talkie - whatever. This way, we regain possibility of p2p data transfer, even if whole internet and mobile/PSTN telephony gets shut down (or some of them, selectively). In narrow-band of 8khzsound, we have quite a lot clearly distinct tones, so data->tones transfer could be quite effective.

I'm just not sure, if there already is a FOSS data-> tones converter (as said, it doesn't need to offer any real encryption, just brain dead conversion, as effective/redundant as possible). If there *is*, we're 95% advanced with fully functional project.

/Estel

// Edit

In case of total blackout and need to send data over longer distance - where even establishing relatively clear voice channel isn't possible (but super noisy link, that we can abuse to send *some* sounds) - think ham radio over loooong distance - we could also use reduced set of tones (like 2 or three distinct ones), to achieve same thing, just muuuch slower.

Super extreme case, is when even tones are totally incomprehensible, but *changes* are possible - I know that HAM people use it, sometimes, to talk via morse code, over extremely weak links (changes in noise pattern can be interpreted as morse signals). This could be used to transfer *very* small files, using their HEX representation (or some more efficient conversion to A-Z 1-0 symbols) via morse. We already have text-to-morse-to-led automatic converter - no reason, why it wouldn't be possible (and easy) to make it generate loud noise, instead of flash blinks.

You wouldn't want to send megabytes of data this way, but would still allow to send *data* (sloooooooowly) in some super-extreme situations.

/Estel

Estel, if you want FSK or PSK data over soundcard fldigi will do most of the work in most popular modes, for more network oriented traffic ax25 protocol will permit even tcp/ip over soundcard. These are well supported by OSS. These are both intended for low bandwidth radio so will easily fit in GSM voice channel. These are available for chroot debian on the repos right now. In the amateur radio repos there is even a very low bandwith app, WSJT, which averages tones over minutes for bouncing signals using the moon as the communication satellite, it is possible to connect worldwide using a 100w VHF or UHF amp, a preamp, a SSB radio, and a long yaggi made from grounding wire and a piece of wood or plastic pipe.

This looks as a good candidate then the other options being discussed though it does only a tad of what we want

Thanks a lot - coincidentally, just yesterday I've been through long articles about that moon-reflected signals. Awesome stuff. It seems, (from other threads), like you know many things about HAM radios - this could be invaluable, as my knowledge about this topic is purely theoretical.

I'll take a look into those Debian programs - if they do what we need to do, we just need talented GUI programmer (hint: Copernicus ) to bundle all existing components into one send-receive Maemo's native program, and we're there

/Estel

While WSJT for sure uses audio signal from audio port output (= is what we need for those super-extreme situations digital communication via very low signal with very small bandwidth), I'm not sure if ax25 is suitable for over-PSTN or generally, over-audio data stream?

@nokiabot - use PM for your personal ham education, please. And if you ask me, HAM licensing suck big time - pirate life for me