The Physical Layer -- Modem-to-Modem Over POTS

The foundation is establishing a raw serial data pipe between two points over the Public Switched Telephone Network. You're essentially treating the phone network as an analog transport medium.On the originating side (the caller), you'd issue standard Hayes AT commands. Something along these lines: initialize the modem with AT&F to load factory defaults, then configure parameters -- ATS0=0 to disable auto-answer, AT&D2 so DTR dropping hangs up, &C1 for carrier-detect tracking, and &K3 to enable hardware flow control (RTS/CTS). Then dial with ATDT5551234. On the answering side, you'd set S0=1 or S0=2 to auto-answer after one or two rings, with matching flow-control and DTR settings. Once the handshake completes -- that unmistakable screech of modulating carriers negotiating modulation scheme, error correction
(V.42/MNP), and data compression (V.42bis/MNP5) -- you have a transparent serial bitstream. Typically you'd be working at speeds anywhere from 2400 bps (V.22bis) up to 33,600 bps (V.34) or 56,000 bps (V.90, though that only works asymmetrically with a digital endpoint at the central office). Additionally, v.92 supports 48.8 kbps symmetric. Crucially, once the carrier is established, the modems are largely invisible to the data -- they present a serial port abstraction to the DTE (your computer or terminal). Everything you write to the serial port goes out over the phone line. This transparency is what makes layering encryption on top feasible. One important consideration: you'll want hardware flow control (RTS/CTS) rather than XON/XOFF software flow control, because XON/XOFF reserves two byte values (0x11 and 0x13) for flow control signaling. If your encryption produces ciphertext that happens to contain those bytes, software flow control would interpret them as control signals and corrupt your stream. Hardware flow control operates on dedicated RS-232 signal lines and is therefore opaque to the data bytes, making it essential for encrypted communications over modems.

The Data Link Layer -- Raw Serial vs. PPP

From here, you have two broad architectural choices for what runs over that serial pipe.Option A: Raw Serial Stream---You treat the modem connection as a direct serial link -- just a byte pipe. Your terminal software on each end handles encryption and decryption of the byte stream before it hits the serial port and after it comes back. This is the simplest approach and maps well to the traditional BBS paradigm, where terminal software communicates directly over a COM port. The downside is that there's no framing, error detection, or addressing -- you rely entirely on the modem's built-in error correction (V.42 LAP-M or MNP4) for link integrity.Option B: PPP Over Serial---You establish a Point-to-Point Protocol session over the serial link. PPP gives you proper frame delimiting (flag bytes 0x7E), CRC checksums, and importantly, the ability to negotiate network-layer protocols. With PPP running, you can assign IP addresses to each end of the link and treat the modem connection as a network interface. This opens up the possibility of running standard network protocols -- including SSH -- over the link. On a Linux or Unix system, you'd use pppd with something like pppd /dev/ttyS0 38400 noauth local :192.168.1.1 on one side and pppd /dev/ttyS0 38400 noauth defaultroute :192.168.1.2 on the other. The noauth flag skips PAP/CHAP since you're presumably doing your own authentication via the encryption layer. Once PPP is up, you have routable IP connectivity over the modem, and you can tunnel anything you like through it.PPP with HDLC-like framing also gives you byte-stuffing (escaping flag and control characters), which solves the XON/XOFF problem at the protocol level if you're stuck with software flow control for some reason -- though you'd still want hardware flow control for performance reasons.

The Encryption Layer

This is where things get interesting, and there are several distinct approaches ranging from hardware to pure software.Approach 1: Inline Hardware Encryptors (Type 1 / COMSEC Gear)The most physically secure option involves placing dedicated encryption hardware between the DTE (computer) and the DCE (modem) on each side of the link. In military and government contexts, these are called Inline Encryption Devices or Transmission Security (TRANSEC) equipment. The concept is simple: your terminal connects to the encryptor's DTE port, and the encryptor's DCE port connects to the modem. All traffic passing through is encrypted before it hits the phone line. The far end has an identical device performing the inverse operation. The terminal and modem are completely unaware that encryption is occurring.Historical examples include the TSEC/KG-84 family, which was used for serial data encryption over various communications links, and the KIV-7 which performed a similar function for bulk data. These devices typically used classified algorithms and were controlled under crypto-ignition keys. In the commercial/unclassified space, companies like Cylink and Security Dynamics produced inline encryptors for serial links.The advantage of this approach is that the encryption is physically isolated -- there's no software running on the terminal that could be compromised to leak keys. The disadvantage, obviously, is obtaining the hardware and the cost. For a hobbyist or researcher, surplus COMSEC gear sometimes appears on the secondary market, though key material and documentation are typically unavailable.Approach 2: Software Stream Encryption in Terminal Software. This is the most accessible approach for someone building a retro-style secure BBS link. You write (or modify) terminal software on each end that performs encryption on the data stream before writing it to the serial port, and decryption after reading from the serial port.The key design decision here is cipher choice. You want a stream cipher or a block cipher operating in a stream mode (like CTR or OFB), because: first, stream ciphers preserve the real-time character-by-character nature of terminal communication. You don't need to buffer entire blocks before encrypting. A user presses a key, the byte is encrypted immediately, and it goes out over the wire. The remote end decrypts it immediately and displays the character. This is essential for interactive BBS use where you need responsive full-duplex character echoing.Second, stream ciphers have no error propagation properties -- a corrupted bit in the ciphertext only affects the corresponding bit in the recovered plaintext, not subsequent blocks. V.42 error correction largely prevents corruption, but resilience is still valuable.Good candidates for the cipher include ChaCha20 (modern, fast, well-analyzed), AES-256 in CTR mode (widely trusted, hardware acceleration on many platforms), or for a more period-appropriate feel, RC4 (historically used in SSL, though now deprecated due to vulnerabilities), or even a one-time pad if you can solve the key distribution problem and your throughput is low enough.Salsa20 or ChaCha20 is probably the ideal choice for a new implementation. It's fast even on modest hardware, has a simple key/nonce setup, and is resistant to timing attacks unlike AES (which matters if your terminal software runs on a shared system). You'd initialize with a 256-bit key and a unique nonce per session, then XOR the keystream against your plaintext bytes.The critical cryptographic concern is nonce/key management. Each session must use a fresh random nonce -- never reuse a (key, nonce) pair, or you expose the XOR of two plaintexts. The key itself should be established out-of-band (pre-shared on paper, exchanged via a different channel, or derived through a key agreement protocol).For key exchange, you could implement a simple Diffie-Hellman key agreement at the start of the session: after the modems connect, before entering encrypted mode, the two sides exchange DH parameters and derive a shared secret. However, this is vulnerable to a man-in-the-middle attack unless you have authentication -- you'd want pre-known public keys or a fingerprint verification step (similar to how SSH's host key fingerprints work on first connection). For added period authenticity, you could use RSA key exchange -- generate ephemeral RSA keypairs, exchange public keys, and one side encrypts a random session key with the other's public key.Approach 3: SSH Over PPP" If you went the PPP route in step 2, you can simply run SSH over the link. Once PPP gives you IP connectivity, you ssh from one machine to the other. SSH provides strong encryption (AES, ChaCha20-Poly1305), authenticated key exchange (curve25519-sha256 or similar), forward secrecy, and a secure shell session that handles terminal emulation properly. This is the most robust approach in terms of cryptographic soundness, because you're benefiting from decades of security review of the SSH protocol. You also get features like port forwarding -- you could set up a SOCKS proxy or local port forwarding over SSH, creating a true tunnel through the POTS connection. Any TCP service on the remote network could be accessed through the SSH tunnel. The practical setup would look like: modem connects, PPP establishes IP link (say 192.168.1.1 - 192.168.1.2), then ssh -L 2323:localhost:23 user@192.168.1.2 forwards the remote telnet BBS port to local port 2323. You connect your terminal emulator to localhost:2323 and you're interacting with the remote BBS through an encrypted SSH tunnel riding on a PPP-over-modem-over-POTS link. For a full tunnel rather than just a single port, you could use SSH's -w option for TUN/TAP device forwarding, or use -D for a dynamic SOCKS proxy. Either way, you've created a VPN-like overlay network through a dial-up modem connection. Approach 4: stunnel Wrapping a Serial Connection Stunnel is a program designed to wrap arbitrary TCP connections in TLS. While it's normally used for TCP, with some creativity it can be combined with a serial-to-TCP bridge. You'd run a small program on each side that bridges the serial port (connected to the modem) to a localhost TCP socket, then run stunnel on each side to encrypt the TCP connection with TLS. The terminal software connects to the local stunnel endpoint rather than directly to the serial port. This is somewhat convoluted compared to approach 3, but it has the advantage of using a well-reviewed TLS implementation rather than custom crypto code. You'd benefit from TLS's certificate-based mutual authentication, cipher suite negotiation, and key exchange. Approach 5: Modified BBS Software with Built-in EncryptionSome BBS software packages were aware of the need for secure communications, particularly in the FidoNet world where echomail and netmail traversed untrusted phone networks across geopolitical boundaries.In a custom or modified BBS setup, the BBS software itself could perform encryption. When a caller connects, the BBS could enter a secure mode -- exchanging keys, then switching the terminal I/O through an encryption layer. The caller's terminal software would need a matching decryption layer.Historically, some systems used PGP to encrypt individual messages or files transferred over the BBS, but this operated at the message level rather than creating a session-level tunnel.

Practical ANSI-BBS Considerations

ANSI-BBS communication involves escape sequences -- sequences beginning with ESC (0x1B) and bracket [ followed by parameters and a final letter, like ESC[2J (clear screen) or ESC[31m (set foreground color to red). These are just bytes in the stream, and since encryption operates on the byte stream below the application layer, ANSI codes pass through transparently. The encryption layer neither knows nor cares whether a given byte is part of an ANSI sequence or displayable text. However, there are some practical considerations for terminal timing. ANSI sequences often have tight timing expectations, especially for cursor positioning and screen redraw operations. If your encryption layer introduces significant buffering or latency, you might see screen rendering glitches on complex ANSI art. Stream ciphers with immediate byte-at-a-time processing avoid this entirely -- you encrypt and transmit each byte as soon as it arrives, preserving the original timing characteristics of the BBS session. Another consideration is that some BBS software used in-band signaling for certain functions -- sending special characters or sequences to trigger file transfer modes (XMODEM, YMODEM, ZMODEM, Kermit). Since encryption makes these bytes indistinguishable from any other ciphertext, you need to ensure that your encryption layer is truly transparent and that the endpoint software (not the modem or any intermediate system) handles protocol recognition. This is another reason to favor the DTE-level encryption approaches (hardware inline or terminal software) over anything that might involve modem-level intelligence.ZMODEM in particular is worth noting because it's a streaming binary protocol that includes its own framing and error recovery. As long as your encryption layer passes all bytes through faithfully (which it should -- ciphertext is just bytes), ZMODEM will operate correctly over the encrypted link, providing encrypted file transfers within your already-encrypted session.

A Complete Reference Architecture

Putting it all together, here's what a complete, practical system might look like for someone who wants to build this today: each station consists of a computer running Linux or a similar Unix-like OS, connected via RS-232 (or a USB-to-serial adapter) to an external hardware modem -- something like a USRobotics Courier or Sportster, a Hayes Optima, or a MultiTech modem. The modem connects to a standard analog telephone line. On the software side, each station runs pppd to establish a PPP link over the serial port once the modems connect. One side is configured to dial out (with a chat script that sends the ATDT command), and the other is configured to answer (auto-answer via S0). Once PPP is up, SSH is initiated over the link, providing an encrypted tunnel. The BBS software runs on the answering side, accessible via the SSH session or through SSH port forwarding.For authentication, SSH public key authentication prevents MITM attacks -- each side has the other's public key in ~/.ssh/authorized_keys. For extra paranoia, you could additionally require a passphrase or even a physical token.If you wanted to skip the PPP layer and go with a simpler architecture, you could use socat to bridge the serial port with an SSL/TLS connection: socat
OPENSSL-LISTEN:443,cert=server.pem,key=server.pem,reuseaddr,fork SERIAL:/dev/ttyS0,b38400,raw on the answering side, and socat SERIAL:/dev/ttyS0,b38400,raw OPENSSL:remote.host:443,cert=client.pem,key=client.pem on the calling side. Then your terminal emulator (SyncTERM, OpenTOMM, or whatever you prefer) connects to the local socat endpoint rather than directly to the serial port.

Historical Context and Limitations

During the height of the BBS era (late 1980s through mid-1990s), encrypted modem communication was rare but not unknown. Government and military users had access to classified COMSEC equipment. In the civilian sphere, some businesses used proprietary encrypted modem links for sensitive data transmission. Privacy advocates and cypherpunks discussed the concept extensively, and tools like PGPfone (Phil Zimmermann's encrypted voice-over-modem software from 1995) demonstrated the concept of end-to-end encryption over POTS, albeit for voice rather than data. The Clipper Chip controversy of 1993-1996 is particularly relevant here -- it was an attempt by the US government to mandate hardware encryption in telecommunications devices (including modems) with key escrow, allowing law enforcement access. The backlash from privacy advocates and the cypherpunk movement directly motivated development of freely available strong encryption tools. For the enthusiast looking to build something like this today, the main challenge isn't cryptographic -- strong algorithms are freely available and well-implemented. The main challenge is the physical infrastructure: POTS lines are becoming scarce as telecom providers transition to VoIP and fiber, and analog line characteristics (noise, impedance, frequency response) can affect modem reliability. If you have access to two analog lines or can loop two modems back through a PBX or analog phone simulator, the exercise is very much doable and is a fascinating exploration of layered communications security.Would you like me to dive deeper into any particular layer of this stack -- perhaps the specifics of implementing a stream cipher in terminal software, the AT command sequence for a particular modem model, or the PPP/SSH configuration in more detail?

Cheers!
-warmfuzzy/SilentPartner

--- Mystic BBS v1.12 A49 2023/04/30 (Linux/64)
* Origin: thE qUAntUm wOrmhOlE, rAmsgAtE, uK. bbs.erb.pw (700:100/37)

On 02 Aug 2026, warmfuzzy said the following...

The Physical Layer -- Modem-to-Modem Over POTS

The foundation is establishing a raw serial data pipe between two points over the Public Switched Telephone Network. You're essentially treating the phone network as an analog transport medium.On the originating side (the caller), you'd issue standard Hayes AT commands. Something along these lines: initialize the modem with AT&F to load factory defaults, then configure parameters -- ATS0=0 to disable auto-answer, AT&D2 so
DTR dropping hangs up, &C1 for carrier-detect tracking, and &K3 to
enable hardware flow control (RTS/CTS). Then dial with ATDT5551234. On the answering side, you'd set S0=1 or S0=2 to auto-answer after one or two rings, with matching flow-control and DTR settings. Once the
handshake completes -- that unmistakable screech of modulating carriers negotiating modulation scheme, error correction (V.42/MNP), and data compression (V.42bis/MNP5) -- you have a transparent serial bitstream. Typically you'd be working at speeds anywhere from 2400 bps (V.22bis)
up to 33,600 bps (V.34) or 56,000 bps (V.90, though that only works asymmetrically with a digital endpoint at the central office). Additionally, v.92 supports 48.8 kbps symmetric. Crucially, once the carrier is established, the modems are largely invisible to the data -- they present a serial port abstraction to the DTE (your computer or terminal). Everything you write to the serial port goes out over the phone line. This transparency is what makes layering encryption on top feasible. One important consideration: you'll want hardware flow
control (RTS/CTS) rather than XON/XOFF software flow control, because XON/XOFF reserves two byte values (0x11 and 0x13) for flow control signaling. If your encryption produces ciphertext that happens to
contain those bytes, software flow control would interpret them as
control signals and corrupt your stream. Hardware flow control operates
on dedicated RS-232 signal lines and is therefore opaque to the data bytes

The Data Link Layer -- Raw Serial vs. PPP

From here, you have two broad architectural choices for what runs over that serial pipe.Option A: Raw Serial Stream---You treat the modem connection as a direct serial link -- just a byte pipe. Your terminal software on each end handles encryption and decryption of the byte
stream before it hits the serial port and after it comes back. This is the simplest approach and maps well to the traditional BBS paradigm, where terminal software communicates directly over a COM port. The downside is that there's no framing, error detection, or addressing -- you rely entirely on the modem's built-in error correction (V.42 LAP-M
or MNP4) for link integrity.Option B: PPP Over Serial---You establish a Point-to-Point Protocol session over the serial link. PPP gives you
proper frame delimiting (flag bytes 0x7E), CRC checksums, and importantly, the ability to negotiate network-layer protocols. With PPP running, you can assign IP addresses to each end of the link and treat the modem connection as a network interface. This opens up the possibility of running standard network protocols -- including SSH -- over the link. On a Linux or Unix system, you'd use pppd with something like pppd /dev/ttyS0 38400 noauth local :192.168.1.1 on one side and
pppd /dev/ttyS0 38400 noauth defaultroute :192.168.1.2 on the other.
The noauth flag skips PAP/CHAP since you're presumably doing your own authentication via the encryption layer. Once PPP is up, you have
routable IP connectivity over the modem, and you can tunnel anything
you like through it.PPP with HDLC-like framing also gives you byte-stuffing (escaping flag and control characters), which solves the XON/XOFF problem at the protocol level if you're stuck with software flow

The Encryption Layer

This is where things get interesting, and there are several distinct approaches ranging from hardware to pure software.Approach 1: Inline Hardware Encryptors (Type 1 / COMSEC Gear)The most physically secure option involves placing dedicated encryption hardware between the DTE (computer) and the DCE (modem) on each side of the link. In military
and government contexts, these are called Inline Encryption Devices or Transmission Security (TRANSEC) equipment. The concept is simple: your terminal connects to the encryptor's DTE port, and the encryptor's DCE port connects to the modem. All traffic passing through is encrypted before it hits the phone line. The far end has an identical device performing the inverse operation. The terminal and modem are completely unaware that encryption is occurring.Historical examples include the TSEC/KG-84 family, which was used for serial data encryption over
various communications links, and the KIV-7 which performed a similar function for bulk data. These devices typically used classified algorithms and were controlled under crypto-ignition keys. In the commercial/unclassified space, companies like Cylink and Security Dynamics produced inline encryptors for serial links.The advantage of this approach is that the encryption is physically isolated -- there's
no software running on the terminal that could be compromised to leak keys. The disadvantage, obviously, is obtaining the hardware and the cost. For a hobbyist or researcher, surplus COMSEC gear sometimes
appears on the secondary market, though key material and documentation are typically unavailable.Approach 2: Software Stream Encryption in Terminal Software. This is the most accessible approach for someone building a retro-style secure BBS link. You write (or modify) terminal software on each end that performs encryption on the data stream before writing it to the serial port, and decryption after reading from the serial port.The key design decision here is cipher choice. You want a stream cipher or a block cipher operating in a stream mode (like CTR or OFB), because: first, stream ciphers preserve the real-time character-by-character nature of terminal communication. You don't need
to buffer entire blocks before encrypting. A user presses a key, the
byte is encrypted immediately, and it goes out over the wire. The remote end decrypts it immediately and displays the character. This is
essential for interactive BBS use where you need responsive full-duplex character echoing.Second, stream ciphers have no error propagation properties -- a corrupted bit in the ciphertext only affects the corresponding bit in the recovered plaintext, not subsequent blocks.
V.42 error correction largely prevents corruption, but resilience is
still valuable.Good candidates for the cipher include ChaCha20 (modern, fast, well-analyzed), AES-256 in CTR mode (widely trusted, hardware acceleration on many platforms), or for a more period-appropriate feel, RC4 (historically used in SSL, though now deprecated due to vulnerabilities), or even a one-time pad if you can solve the key distribution problem and your throughput is low enough.Salsa20 or
ChaCha20 is probably the ideal choice for a new implementation. It's
fast even on modest hardware, has a simple key/nonce setup, and is resistant to timing attacks unlike AES (which matters if your terminal software runs on a shared system). You'd initialize with a 256-bit key
and a unique nonce per session, then XOR the keystream against your plaintext bytes.The critical cryptographic concern is nonce/key management. Each session must use a fresh random nonce -- never reuse a (key, nonce) pair, or you expose the XOR of two plaintexts. The key
itself should be established out-of-band (pre-shared on paper, exchanged via a different channel, or derived through a key agreement
protocol).For key exchange, you could implement a simple Diffie-Hellman key agreement at the start of the session: after the modems connect, before entering encrypted mode, the two sides exchange DH parameters and derive a shared secret. However, this is vulnerable to a
man-in-the-middle attack unless you have authentication -- you'd want pre-known public keys or a fingerprint verification step (similar to how SSH's host key fingerprints work on first connection). For added period authenticity, you could use RSA key exchange -- generate ephemeral RSA keypairs, exchange public keys, and one side encrypts a random session
key with the other's public key.Approach 3: SSH Over PPP" If you went
the PPP route in step 2, you can simply run SSH over the link. Once PPP gives you IP connectivity, you ssh from one machine to the other. SSH provides strong encryption (AES, ChaCha20-Poly1305), authenticated key exchange (curve25519-sha256 or similar), forward secrecy, and a secure shell session that handles terminal emulation properly. This is the
most robust approach in terms of cryptographic soundness, because you're benefiting from decades of security review of the SSH protocol. You also get features like port forwarding -- you could set up a SOCKS proxy or local port forwarding over SSH, creating a true tunnel through the POTS connection. Any TCP service on the remote network could be accessed through the SSH tunnel. The practical setup would look like: modem connects, PPP establishes IP link (say 192.168.1.1 - 192.168.1.2), then ssh -L 2323:localhost:23 user@192.168.1.2 forwards the remote telnet BBS port to local port 2323. You connect your terminal emulator to localhost:2323 and you're interacting with the remote BBS through an encrypted SSH tunnel riding on a PPP-over-modem-over-POTS link. For a full tunnel rather than just a single port, you could use SSH's -w
option for TUN/TAP device forwarding, or use -D for a dynamic SOCKS proxy. Either way, you've created a VPN-like overlay network through a dial-up modem connection. Approach 4: stunnel Wrapping a Serial Connection Stunnel is a program designed to wrap arbitrary TCP
connections in TLS. While it's normally used for TCP, with some creativity it can be combined with a serial-to-TCP bridge. You'd run a small program on each side that bridges the serial port (connected to
the modem) to a localhost TCP socket, then run stunnel on each side to encrypt the TCP connection with TLS. The terminal software connects to
the local stunnel endpoint rather than directly to the serial port.
This is somewhat convoluted compared to approach 3, but it has the advantage of using a well-reviewed TLS implementation rather than custom crypto code. You'd benefit from TLS's certificate-based mutual authentication, cipher suite negotiation, and key exchange. Approach 5: Modified BBS Software with Built-in EncryptionSome BBS software packages were aware of the need for secure communications, particularly in the Fido

Practical ANSI-BBS Considerations

ANSI-BBS communication involves escape sequences -- sequences beginning with ESC (0x1B) and bracket [ followed by parameters and a final
letter, like ESC[2J (clear screen) or ESC[31m (set foreground color to red). These are just bytes in the stream, and since encryption operates on the byte stream below the application layer, ANSI codes pass through transparently. The encryption layer neither knows nor cares whether a given byte is part of an ANSI sequence or displayable text. However, there are some practical considerations for terminal timing. ANSI sequences often have tight timing expectations, especially for cursor positioning and screen redraw operations. If your encryption layer introduces significant buffering or latency, you might see screen rendering glitches on complex ANSI art. Stream ciphers with immediate byte-at-a-time processing avoid this entirely -- you encrypt and
transmit each byte as soon as it arrives, preserving the original
timing characteristics of the BBS session. Another consideration is
that some BBS software used in-band signaling for certain functions -- sending special characters or sequences to trigger file transfer modes (XMODEM, YMODEM, ZMODEM, Kermit). Since encryption makes these bytes indistinguishable from any other ciphertext, you need to ensure that
your encryption layer is truly transparent and that the endpoint
software (not the modem or any intermediate system) handles protocol recognition. This is another reason to favor the DTE-level encryption approaches (hardware inline or terminal software) over anything that
might involve modem-level intelligence.ZMODEM in particular is worth noting because it's a streaming binary protocol that includes its own framing and error recovery. As long as your encryption layer passes all bytes through faithfully (which it should -- ciphertext is just bytes), ZMODEM will operate correctly over the encrypted link, providing encrypte

A Complete Reference Architecture

Putting it all together, here's what a complete, practical system might look like for someone who wants to build this today: each station consists of a computer running Linux or a similar Unix-like OS,
connected via RS-232 (or a USB-to-serial adapter) to an external
hardware modem -- something like a USRobotics Courier or Sportster, a Hayes Optima, or a MultiTech modem. The modem connects to a standard analog telephone line. On the software side, each station runs pppd to establish a PPP link over the serial port once the modems connect. One side is configured to dial out (with a chat script that sends the ATDT command), and the other is configured to answer (auto-answer via S0). Once PPP is up, SSH is initiated over the link, providing an encrypted tunnel. The BBS software runs on the answering side, accessible via the SSH session or through SSH port forwarding.For authentication, SSH
public key authentication prevents MITM attacks -- each side has the other's public key in ~/.ssh/authorized_keys. For extra paranoia, you could additionally require a passphrase or even a physical token.If you wanted to skip the PPP layer and go with a simpler architecture, you could use socat to bridge the serial port with an SSL/TLS connection: socat OPENSSL-LISTEN:443,cert=server.pem,key=server.pem,reuseaddr,fork SERIAL:/dev/ttyS0,b38400,raw on the answering side, and socat SERIAL:/dev/ttyS0,b38400,raw OPENSSL:remote.host:443,cert=client.pem,key=client.pem on the calling side. Then your terminal emulator (SyncTERM, OpenTOMM, or whatever you prefer) connects to the local socat endpoint rather than directly to the

Historical Context and Limitations

During the height of the BBS era (late 1980s through mid-1990s),
encrypted modem communication was rare but not unknown. Government and military users had access to classified COMSEC equipment. In the
civilian sphere, some businesses used proprietary encrypted modem links for sensitive data transmission. Privacy advocates and cypherpunks discussed the concept extensively, and tools like PGPfone (Phil Zimmermann's encrypted voice-over-modem software from 1995)
demonstrated the concept of end-to-end encryption over POTS, albeit for voice rather than data. The Clipper Chip controversy of 1993-1996 is particularly relevant here -- it was an attempt by the US government to mandate hardware encryption in telecommunications devices (including modems) with key escrow, allowing law enforcement access. The backlash from privacy advocates and the cypherpunk movement directly motivated development of freely available strong encryption tools. For the enthusiast looking to build something like this today, the main
challenge isn't cryptographic -- strong algorithms are freely available and well-implemented. The main challenge is the physical
infrastructure: POTS lines are becoming scarce as telecom providers transition to VoIP and fiber, and analog line characteristics (noise, impedance, frequency response) can affect modem reliability. If you
have access to two analog lines or can loop two modems back through a
PBX or analog phone simulator, the exercise is very much doable and is
a fascinating exploration of layered communications security.Would you like me to dive deeper into any particular layer of this stack --
perhaps the specifics of implementing a stream cipher in terminal software, the AT command sequence for a particular modem model, or the PP

Cheers!
-warmfuzzy/SilentPartner

--- Mystic BBS v1.12 A49 2023/04/30 (Linux/64)
* Origin: thE qUAntUm wOrmhOlE, rAmsgAtE, uK. bbs.erb.pw (700:100/37)

--- Mystic BBS v1.12 A49 2023/04/30 (Linux/64)
* Origin: thE qUAntUm wOrmhOlE, rAmsgAtE, uK. bbs.erb.pw (700:100/37)