Legionlabs
What?
Objectives:
- Implement E2E encrypted chat over MQTT using AES-256 GCM.
- Implement ephemeral key exchange & compute a shared secret with ML-KEM
- Each device is paired to another, on boot they will find each other & exchange keys with HMAC-like authentication.
- Runs on an ESP32 (S or S3) as a peripheral to a computer that has no Internet connection of its own
- Should have basic protection against message replay
- Should a serial+USB peripheral, so that it may be used with computers both ancient and modern. This means it will need an (optional) PCB that adds a real serial port.
Features:
- Plug it in to a device that doesn't have Internet access. Now it can connect to WiFi, but only for the purposes of engaging in E2E encrypted chat with exactly one other device. No other connectivity is permitted. The device doesn't even know how to engage in other connectivity.
- This simplifies endpoint security. Since it's only allowed & capable of doing one thing, and that one thing is completely on public channels, it's pretty easy to detect if it's doing anything else.
- By implementing chat over public MQTT servers, there's no single central provider.
- It is intended to be controlled by a software application that provides a UI etc. suitable for the host device.
There's no TLS support presently. I may add it later, but overall the device doesn't rely on trusting the broker.
Why?
I was quite ill recently, and in my fever-dreams I recalled a device: The IBM Selectric-251, a fictional typewriter from a sci-fi television show called Fringe.
The nature of my madness mandates that I create the devices that claw their way out of my dreams. Also, my C++ is not very good, and this was an opportunity to work on it a bit. As such, I didn't see much point of using AI to write any code, all hallucinations are entirely my own (re: fever-dreams).
In the television show, two "quantum-entangled" typewriters function such that what you type in one comes out the other, regardless of where they are and without the possibility of the message being intercepted.
Since the device from the television show functions via magical "quantum-entanglement", and real-life quantum entanglement doesn't work that way, we'll need to "entangle" them via some other method. So instead I use two arrays of 32 bytes generated by:
tr -dc A-Za-z0-9 </dev/urandom | head -c 32; echo
One array identifies the local device, the other array identifies the remote device. These are never used for encryption, because then an attacker that obtains one of the devices could decrypt all prior communications.
So instead, these identifiers are used to:
- Compute two MQTT channels, optionally with a user-specified modifier like the first 7 digits of the Unix timestamp
- Authenticate (with something HMAC-like) a handshake that performs ML-KEM key exchange
The computed channels have two purposes:
- To obfuscate traffic analysis if the user wishes to do so.
- Prevent message replay. An attacker could replay an old connection, which would not let them impersonate you or decrypt your messages, but would make it difficult to connect up the two devices.
Once the key exchange is complete, the devices have an ephemeral shared secret suitable for performing AES-GCM. For simplicity, GCM is used to authenticate all future messages. I added a session message counter (encrypted along with the plaintext) to prevent message replay.
This design offers several advantages over the fictional Selectric 251:
- It exists
- It uses 256 bit encryption, which is 5 bits more than 251 (I presume that's what the '251' indicates)
- It's compatible with more than just electric typewriters
- It's better than quantum, it's post-quantum!
A weakness of the system is that anyone possessing the 32-byte identifiers on the device can impersonate the owner (although they would also need to know your channel-hopping scheme, and they cannot decrypt prior communications). So, store your devices somewhere safe.
Szaja
Noah Pena
MachineMan
Sam P