FAQ
-
CPU: 2GHz, 64-bit instructions, 4 threads.
-
Memory: Minimum 1GB free RAM.
According to IETF's Argon2 Spec for protecting data at rest:
o Key derivation for hard-drive encryption, that takes 3 seconds on a 2 GHz CPU using 2 cores - Argon2id with 4 lanes and 6 GiB of RAM.
So we recommend 6GiB of RAM. Note however, that Argon2 only stretches passwords (i.e. adds computational overhead to make guessing passwords slower). If the login password is already strong (say 128 bits), Argon2 doesn't benefit from that much RAM in a meaningful way.
-
Networking: Non-metered internet connection (highly recommended)
-
OS: A 64-bit OS is required. The OS is the biggest bottleneck, so refer the system requirements of the OS for more information.
-
Software: Python 3.7 or 3.8 is required.
-
For data-diode isolated systems, please refer to the Wiki's preparation of hardware to check that the necessary modifications can be performed on the hardware, before purchasing it.
TFC attempts to be as easy to audit as possible, and readability is one of Python's core values. Python also ensures re-distribution of the program is always done as source code (yes, someone might distribute bytecode, but the decompilation is trivial). CPython is also audited and found well written and secure. It's also the case "the Python Software Foundation and the Python developer community take security vulnerabilities very seriously".
Limiting the direction of data flow with just one Tx-Rx pair and GND wire is certainly possible. It is, however, hard to guarantee the serial chip's behavior, i.e., that it cannot somehow read from Tx-pin or send from Rx-pin. Data diode limits direction of data flow with the fundamental laws of physics. This approach also eliminates power analysis attacks of Source and Destination Computer from Networked Computer and protects the split TCB from voltage spikes.
End-to-end encrypted apps are better because it is easier to get people use them. Why advocate something this complex?
End-to-end encryption on a networked system might be more usable, and it does increase the security of all users in a relative sense. However, unless the increased security stops the adversary, the benefit is inadequate. Security that stops determined attackers will always involve more rules, layers, and inconvenience.
TFC is a step back in usability and not a guaranteed solution, but its security architecture provides a level of security no app can ever provide. That being said, TFC is the most convenient tool for anyone who considers adversaries, that hack endpoints to defeat end-to-end encryption, part of their threat model.
There is no business model. TFC is FOSS+FHD for freedom. Here's the deal:
We pay
- for development out of our own pocket
- no rent on infrastructure as there is none (Tor Project manages the HSDirs etc.)
- no overhead costs for development as
- GitHub hosts the code
- The CI environments etc. are free for non-commercial use
In return, we get the feeling of contributing something actually worthwhile to the society.
You pay nothing with your data as none whatsoever is collected. Instead, you pay
- the required hardware from vendors of your own choosing
- the electricity bill for keeping the endpoint powered on when you want to be reachable
- the bill for your broadband connection
- with your time to learn how to use the system securely by reading the documentation
- hopefully with a donatation to the Tor project. This benefits everyone, including all TFC users as well as other great projects like Tor Browser, OnionShare, Cwtch.im, Briar, and SecureDrop.
In return, you get the most secure messaging system out there.
Computers, accessories, and components ordered from manufacturers or subcontractors or the finished products shipped to customers or retailers made by a company might be subjected to interdiction by nation-state actors. Additionally, a company selling the products might be coerced by the government to add a backdoor under the pretext of national security. Security-wise, it is better to distribute TFC design to users who can buy inconspicuous, commercial, off-the-shelf hardware of their choosing, and build the data diodes themselves. An ideal finished product is a well-written software and a guide on how to set up the hardware, install TFC, and use it securely.
Can TFC endpoint be used as an endpoint secure server from which data can be automatically requested?
Unfortunately, no. Making a usable endpoint secure chat system is comparable to putting the man on the moon. Making an endpoint secure server system is comparable to putting the man on the sun. Securing chats alone is a big goal and just because there are limitations doesn't mean there isn't huge value in doing what can be done -- protecting our communication.
See this issue for detailed dissection of the problem.
There is no definite answer as construction of the data diode by hand, the quality and physical distance of capacitors from the optocoupler, and the quality of TTL adapters all affect the error rate.
A well-built unit should be able to perform at around 1Mbps of sustained data transfer speed.
You should try to play with different settings for baudrate and error correction. Note that adding a lot of error correction will introduce a large amount of computational overhead for every sent and received packet.