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.

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.

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.

[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