The bulk CNE is a problem. In previous article I discussed how to achieve end point security with three computer setup and data diodes. Tinfoil Chat or TFC, is the author’s FOSS suite of programs written in Python (auditability and inability to distribute insecure binaries was a priority), that makes real-time chat possible with the described setup. Here’s the visualization of TFC-CEV:
TFC-CEV addresses many problems in current end-to-end encryption. First of all, keys are generated by mixing /dev/(u)random with entropy obtained from free circuit design HWRNG. TFC-CEV uses four additive ciphers to create provably secure cascading encryption:
TFC-CEV encrypts messages with Keccak-CTR (512-bit key), XSalsa20 (256-bit key), Twofish-CTR (256-bit key) and AES-GCM (256-bit key). Authentication is done with three algorithms: GMAC in AES GCM (256-bit key), HMAC-SHA512 (512-bit key) and SHA3-512 MAC (1144-bit key).
XSalsa20, Twofish and AES use the first 256 bits of their 512-bit keys. HMAC-SHA512 and Keccak-CTR both use the entire 512-bit key. SHA3-MAC uses the first 1144 bits of three individual 512-bit keys. All eight 512-bit keys are individually hashed through SHA3-512 hash function after each message to provide forward secrecy.
TFC has three main programs, (Tx.py, Rx.py and NH.py) that move data unidirectionally between the two data diode channels. NH.py also talks to Pidgin IM client. (The main reason Pidgin was chosen was because it’s included with Tails.) Past vulnerabilities of Libpurple are not a problem as TFC assumes NH is in complete control of HSA. In addition to main programs, key generation is done with a set of additional programs.
TFC is also the first(..?) program to provide trickle connection, where TxM outputs a contant stream of messages to recipient. This prevents any adversary who inserts malware into NH or RxM from finding out when, and how much communication is actually taking place. The receiving device does not display noise messages so it doesn’t have noticable effect on the conversation. These noise messages are only sent if user has not added messages to queue. It’s actually a bit more complicated than that since TFC also transmits commands directly from TxM to RxM, encrypted with it’s dedicated set of keys: Every command with volatile effect or one that contains private information is encrypted with the same technique as messages. Before outputting the command packet, the trickle connection independently flips a coin to decide whether to output it, or a noise message. The same goes with messages. Before sending a message (or a part of it), the coin is flipped to decide whether a noise command packet is sent instead.
You can read about TFC in more detail from the links below
The feedback on project has been very positive, excluding the feedback on my cocky title “zero-day immune” from/r/netsec, but I’m glad someone got the idea.
The project has received a lot of constructive critisism too. It’s always a learning process to get things right but in the end it has been worth it; To quote security researcher Nick P:
Far as Tinfoil Chat, I’ve recommended it heartily as a project to use and improve. Markus Ottela took what he learned from prior work and our comments at Schneier’s blog (esp on data diodes & physical separation) to create a unique, solid design. He’s been posting on the blog for feedback for months, we’ve suggested many risk mitigations (eg polyciphers, continuous transmission), and he’s integrated about every one into his system. Most just ignore such things or make excuses: Markus is 1 in a 1,000 in (a) applying what’s proven and (b) not letting problems become legacy “features.”