I. Concept
The goal is to allow communications over an unsecured audio channel. The gizmo needed is a headset connected to a little computer which is connected via a long wire to an audio jack.1 This gizmo captures the audio signal, encrypts it, and passes the encrypted audio signal over an analog channel. To the sender’s and recipient’s untrusted device, the cypheraudio is nothing more than noise. And so unless the recipient has the corresponding gizmo + key, they will only hear static.
The beauty is that this gizmo will work with any device normally used for phone calls.2 You can plug it into any computer or dumbphone. Your correspondent can plug his into whatever shitware he is using.3
II. Implementation
What are the hardware requirements to encrypt/decrypt fast enough for a real-time phone call?
Most microphones sample at 44.1kHz with a 2 byte depth. Let's be safe and leave room for header information, so say we need to encrypt at 100KBps. My Mac’s (2.3GHz processor) GPG 1.4.23 can encrypt 100KB in about .015s and decrypt the same in about .02s. So the napkin calculation seems to show that this device is feasible without adding much latency to comms.
It would also be possible for the gizmos to use one time pads. The correspondents would ‘charge’ their gizmos with an OTP key before making a phone call.4 This would greatly reduce the computational load and complexity on the hardware device itself. It also allows for more transparency. Creating a verifiable device5 that can perform asymmetric public private key encryption seems quite difficult. But creating a device that simply takes an OTP key and performs the necessary XOR’s seems doable. 6
III. Prototyping
The tool can be simulated in software.7 The data flow in one direction is GIZMO -> Untrusted Device -> Network -> Untrusted Device -> GIZMO. All data passed over the various connections has a chance of corruption, especially over the network. So the first step in realizing this product is to create a pipeline with simulated data loss and create the encrypt/decrypt protocol that mitigates that data loss to a reasonable degree.
- The audio jack could be a USB, USBc, or whatever port Crapple is forcing upon its users at the given moment [↩]
- This is why the long wire is important. You need to be far away from the untrusted device’s own microphone. One could place the untrusted device next to a source of white noise for extra protection. [↩]
- Whatscrap, Noise- I mean Signal, and Shillegram promise end-to-end encryption, but even if you trust their software (only God knows why you would) they still run on top of devices backdoored by Crapple, Goolag, and perhaps a 3rd party hacker as well. [↩]
- A 16 GB Key would give 22 hours of comms 16,000,000,000 / (60 * 60 * 100,000 * 2). [↩]
- Like FUCKGOATS [↩]
- The puzzle becomes - how do you sync up the encrypting and decrypting devices?
One way to do this this is to break the audio signal into fixed sized packets with headers. The first part of the header contains the index into the OTP used to decrypt the rest of the packet. How do we ensure that this index is faithfully transmitted and what do we do with dropped bits within packets? I still need to work out some of these questions. [↩]
- The hardware device can be prototyped without any special equipment. Ideally, one would have two computers and two cables - each cable connecting to the audio out of one device and to the audio in of the other device. [↩]
Relevant discussion from jwrd logs, pasted below.
[00:31] jfw: whaack: it seems to me the trouble with your attempt to recreate the dialup modem over modern phone signals is that those are anything but analog channels. besides packet loss you'll have lossy voice compression codecs to get past
[00:32] whaack: Oh man that is a real problem that did not occur to me
[00:34] whaack: So the only way this could possibly work is if the protocol designs packets such that they're able to handle the lossy voice compression codecs... which seems ~ impossible
[00:34] jfw: should certainly be possible to get a telegraph-level bitrate out of it but real-time voice seems unlikely
[00:35] whaack: There also may be multiple different codecs to deal with
[00:38] jfw: in general you can assume that they'll preserve only what the human auditory apparatus can distinguish. so, sine waves, longer pulses or whatever should work, "noise" or even multiple overlaid frequencies not so much.
[00:39] jfw: VOIP protocols had to add side channels to simulate dial-tones for interactive menu systems, because those use a two-frequency code (DTMF) which doesn't pass reliably over the compressed digital channel.
[00:39] whaack: it seems this one is used for whattscrap https://opus-codec.org/
[00:47] whaack: I'm not sure i fully grok. So VOIP needed a way to send certain tones, but were unable to due to compression used over digital channels, so they created this thing called side channels (what are these?) In order to send these specific tones?
[00:50] jfw: well voip means you're working with tcp and/or udp. on top of this you can define logical channels however you like: voice, control, etc. so, when you use the number pad e.g. on a SIP phone or client, instead of sending the traditional beeps as audio, they're sent as a digital control signal and synthesized on the other end if it's bridged into a true analog phone line.
[00:52] whaack: gotcha
[00:54] jfw: the things I almost wish I didn't know...
[00:57] whaack: well I am grateful that you could immediately share this inside
[00:58] whaack: insight*
[00:58] whaack: This certainly makes the task a little more challenging, if not downright impossible
[01:00] whaack: It looks like if I embark on this task I'm going to start by trying to get a encrypted voice communication over a channel where I can ensure that no lossy codexs are being applied
[01:00] jfw: why the interest in encrypted audio anyway? (not that thought experiments aren't fun and all)
[01:03] whaack: It bothers me that it seems like there's such an easy solution out there to have private phone calls but to my mind none exist. And it seems like a nice little challenge to make one
[01:05] jfw: philosophically though, it seems possibly an attempt at a technical solution to the social problem of people not getting with the program on computer text, irc, gpg etc.
[01:06] whaack: I also thought that this gadget might be something people would be interested in buying
[01:07] jfw: people clearly do buy phones; perhaps one with more credible encryption might sell
[01:08] whaack: I think the isolation of the device that encrypts is important. I don't think people are going to give up their shit phones with all the bells and whistles it comes with
[01:09] whaack: All that said I'm not really interested in any sort of catering to people too lazy to 'get with the program'
[01:09] whaack: I just personally would like to be able to make private phone calls and it's a simple enough challenge
[01:10] jfw: the isolation would be important indeed
[01:10] jfw: on the practical side, you're likely to run into the usual
[01:10] jfw: "mountains of horrible code" mess on trying to put the pieces together
[01:11] jfw: not that that's a reason not to do things, just to be aware of what you're biting off
[01:12] whaack: I understand it's a big task for the ideal tool that interfaces with all sorts of devices - I thought that before you even mention the codec part
[01:14] jfw: but even just the "pipe an audio stream into gpg and pull it out the other end with acceptable latency" might not work just like that, dunno. could be interesting to try at least.
[01:14] whaack: That's exactly what I plan to try
[01:19] whaack: bbl making some fish tacos
I tried (unsuccessfully) to build a very similar item in 2017. There was to be FG for the OTP generator, audio jack, etc.
The boojum: to send ciphered bits in something like real time, you need to somehow overcome the lossy compression forced on you by the cellular modem and carrier.
Getting even 1200 baud (bare minimum for "robot voice"-flavoured ciphered audio) across GSM voice channel would get you there (you may be able to do it via fountain codes) but AFAIK no one's yet admitted to having pulled this off.
@Stanislav
Cool to see that you also thought to do it via the OTP route.
Yes that problem of the lossy compression seems to be the main hassle that I overlooked in this article.
I think getting 'robot voice' working would be a nice achievement, but it would really kill any value this item might have on the market. I'll have to look into what fountain codes are.
The difficulty of this problem would give protection from competitors for some time if one managed to find a good solution.
@whaack
There was a paper (which I unfortunately cannot find just now) where author claimed (IIRC) 1200 baud, having mechanically "evolved" an "alphabet" of N mutually distinguishable, after compressor mutilation, waveforms which conveyed B bits of info each.
You may want to obtain two GSM modems with digital voice i/o (check the data sheet, most 3/4G modems only offer analogue voice, you want the kind which presents as two USB devices: modem and "sound card"), a cheapo SIM for each, and could try to replicate this.