The development of TFC is currently on hold. As the available code is not supported by an OS that can receive latest security updates, installation of TFC on new systems is not recommended. No vulnerability has been found from the current version, thus existing users do not need to take any action.
Tinfoil Chat (TFC) is a high assurance encrypted messaging system that operates on top of existing IM clients. The free and open source software is used together with free hardware to protect users from passive eavesdropping, active MITM attacks and remote CNE practised by organized crime and nation state attackers.
XSalsa20 encryption and Poly1305-AES MACs provide end-to-end encrypted communication with deniable authentication: Symmetric keys are either pre-shared, or exchanged using X25519, the base-10 fingerprints of which are verified via out-of-band channel. TFC provides per-packet forward secrecy with hash ratchet the KDF of which chains SHA3-256, Blake2s and SHA256.
The software is used in hardware configuration that provides strong endpoint security: Encryption and decryption are separated on two isolated computers. The split TCB interacts with a third, networked computer through unidirectional serial interfaces. Direction of data flow is enforced with free hardware design data diodes; Lack of bidirectional channels to isolated computers prevents insertion of malware to the encrypting computer and exfiltration of keys and plaintexts from the decrypting computer -- even with exploits against zero-day vulnerabilities in software and operating systems running on the TCB halves.
TFC supports multiple IM accounts per user to hide the social graph of communicating parties, even during end-to-end encrypted group conversations.
TFC allows a group or two parties to defeat metadata about quantity and schedule of communication with traffic masking, where messages and background file transmission is inserted into a constant stream of encrypted noise traffic.
How it works
TFC uses three computers per endpoint. Alice enters her messages and commands to Transmitter program running on her transmitter computer (TxM), a TCB separated from network. The Transmitter program encrypts and signs plaintext data and relays the ciphertext from TxM to her networked computer (NH) trough a serial interface and a hardware data diode.
Messages and commands received to NH are relayed to IM client (Pidgin or Finch), and to Alice's receiver computer (RxM) via another serial interface and data diode. The Receiver program on Alice's RxM authenticates, decrypts and processes the received messages and commands.
The IM client sends the packet either directly or through Tor network to IM server, that then forwards it directly (or again through Tor) to Bob.
IM client on Bob's NH forwards packet to nh.py plugin program, that then forwards it to Bob's RxM (again through serial interface and data diode). Bob's Receiver program on his RxM then authenticates, decrypts, and processes the packet.
When Bob responds, he will type the message to his transmitter computer and in the end, Alice reads the message from her receiver computer.
Why keys can not be exfiltrated
Malware that exploits an unknown vulnerability in RxM can infiltrate the system, but is unable to exfiltrate keys or plaintexts, as data diode prevents all outbound traffic.
Malware can not infiltrate TxM as data diode prevents all inbound traffic. The only data input to TxM is the public key of contact (e.g.
5J8 C2h AVE Wv2 cGz oSd oQv Nkm 9tu ABP qwt Kz8 ou4 xvA HGx HUh sJC), which is manually typed by the user.
The NH is assumed to be compromised: all sensitive data that passes through it is always encrypted and signed.
Optical repeater inside the optocoupler of the data diode (below) enforces direction of data transmission with the laws of physics.
Supported Operating Systems
TxM and RxM
- *buntu 17.04 (64-bit)
- Tails 3.1
- *buntu 17.04 (64-bit)