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.
No. It just means the pinned version of at least one dependency is not the latest release anymore.
Each dependency in non-developer installation configurations uses a pinned hash, which means that the user uses the same exact dependency as us. This protects users from targeted attacks where e.g. crypto libraries are replaced with backdoored versions during installation. (It does not protect against backdoors injected to the actual library however.)
Each release of TFC involves secure signing of the installer (that pins the hashes of requirements files that in turn pin the hashes of dependencies). The secure signing of the installer involves manual labor such as typing the signature from airgapped signing device to development environment, by hand. This is too much work to just keep the badge green, especially because many dependencies update very frequently, e.g. virtualenv.
That being said, if the requirements badge shows that the libraries are insecure...
...that's when you should not install TFC, but wait until the dependencies are updated. Would such an event occur, the updated requirements file would be released within hours, or at most, days.
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.