Tinfoil Chat
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
launchers 1.17.08 Aug 29, 2017
src 1.17.08 Aug 30, 2017
tests 1.17.08 Aug 30, 2017
.coveragerc 1.17.08 Aug 29, 2017
.travis.yml 1.17.08 Aug 30, 2017
LICENSE.md 1.17.08 Aug 29, 2017
README.md Update readme May 1, 2018
dd.py 1.17.08 Aug 29, 2017
install.sh 1.17.08 Aug 30, 2017
install.sh.asc 1.17.08 Aug 30, 2017
nh.py 1.17.08 Aug 29, 2017
requirements-nh.txt 1.17.08 Aug 29, 2017
requirements.txt 1.17.08 Aug 29, 2017
tfc.png 0.17.04 Apr 10, 2017
tfc.py 1.17.08 Aug 29, 2017


Tinfoil Chat

Build Status Coverage Status

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

  1. 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.

  2. 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.

  3. 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)

More information

Threat model
Security design

    Data diode (breadboard)
    Data diode (perfboard)

    How to use

Update Log