Tinfoil Chat OTP
TFC-OTP is a high assurance encryption plugin for Pidgin IM client, built on free and open source hardware and software. Secure by design implementation protects data in transit against passive and active attacks as well as the end points against untasked targeted attacks practiced by TLAs such as the NSA, GCHQ and BKA.
Encryption is done with one-time pad that provides perfect secrecy even if the adversary has unlimited computing power. Need more convenience?
Authentication is done with unconditionally secure one-time MAC that prevents existential forgeries even if adversary has unlimited computing power.
Keys are generated with an open circuit design hardware random number generator that feeds truly random entropy which after whitening is optionally XORred with /dev/(u)random to create the keyfiles. Forward secrecy is obtained by overwriting key in both ends immediately after use.
Endpoints are secured by separating encryption and decryption on two TCB-devides that interact with the network client through data-diode enforced unidirectional channels. Removing the bidirectional channel prevents exfiltration of keys and plaintexts with remote attacks regardless of existing software zero-day vulnerabilities in the OS of TCBs.
Metadata about when and how much communication is taking place can be hidden by sending a constant stream of encrypted data to receiving TCB units.
How it works
In TFC, Alice enters her message into Tx.py running on her Transmitter Module (TxM), a TCB separated from network. Tx.py encrypts the message and signs the ciphertext. TxM then relays the packet to Network Handler (NH) through RS-232 interface and a data diode.
The NH.py script running on Alice's NH (left side of screen) listens to packets from TxM's serial port, and forwards message to Pidgin (right side of NH screen) via dbus IPC. A copy of the packet is also sent to her Receiver Module (RxM, another TCB separated from network) through RS-232 interface and a data diode, where the the ciphertext is authenticated, decrypted, displayed and optionally also logged.
Pidgin sends the packet either directly or through Tor network to IM server, that then forwards it directly (or again through Tor) to Bob.
On the Bob's NH, the script NH.py receives Alice's packet from Pidgin via dbus and forwards it through RS-232 interface and another data diode to his RxM, where the ciphertext is authenticated, decrypted, displayed and optionally also logged. When the Bob responds, he will send the message using his TxM and in the end Alice reads the message from her RxM.
Why keys can not be exfiltrated
Malware can reach RxM, but it can't get the keys out as data diode prevents outbound traffic.
Malware never reaches TxM as data diode prevents inbound traffic.
The NH is assumed to be compromised, but unencrypted data never touches it.
The optical gap of the data diode (below) physically blocks back channels.
Detailed information
Whitepaper: https://cs.helsinki.fi/u/oottela/tfc.pdf