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. [↩]