This seems to be specifically designed for people who are worried that their communications device has been pwned over the internet. So, people who are under fairly targeted, active surveillance.
Hence requiring three physically separate computers and data diodes at each end, to try and physically prevent attacks over the network.
The way I remember it being explained, is in the US metadata had particularly poor legal protections compared to the message content. This is what gave the government any sort of legal basis to claim mass surveillance was legal, compared to say recording and indexing every message from every american. The context of the talk was about cloud and data sovereignty, and making the case that it isn't unsafe to store data in the US with the revelations at the time.
I don't think the talk was recorded, I wish it was, because I think that was the best description I've seen from a legal perspective on why the surveillance programs were targeting metadata and not contents.
Note: It wasn't a Tor-based service back then. Anyone curious about his thinking might find those searching "site:schneier.com" "markus ottella" "tinfoil chat." It also needed a port to native code given he just knew Python.
In any case, it was one of strongest designs being, with right implementation, potentially NSA-proof with simple architecture vs hardware/software architectures that cost millions done by specialists. At best, attackers would keep trying to disrupt or brick the receiver and network components. Potentially some side channel leakage to watch for.
The usability was a problem. An integrated solution could put the boards in one device that user just set up like they do consumer routers. Supplier subversion and interdiction are more threatening. Alternatively, instructions on how to do this with components that come from many suppliers. Or both: one for each audience with their threat profiles. In any case, the real brilliance is that you can have usable high-security really fast vs building a seL4-based appliance.
Yes the use of Tor Onion Services is a brand new thing and something I've been working since the fall of 2017. Piggy-backing on Pidgin was always a temporary solution: The Snowden documents and Hayden's comment on killing people based on metadata made it clear something that's anonymous by default was the way to go.
Ricochet was the biggest influencer, and after I asked about OnionShare's (that's also written on Python) Tor connectivity, Micah Lee kindly pointed me to the direction of Stem. Stem's author Damian Johnson and other members of Tor Project were really helpful and I can't thank them enough. (Note that they have not vetted the implementation in any way!)
I initially implemented v2 onions and stealth authorization but with the announcement of prop224 and next gen (v3) onions I decided to wait. While working on that, new primitives were being implemented to the libraries TFC uses. So in the end, TFC got v3 onions, X448 and XChaCha20-Poly1305 at the same time which was a nice improvement.
"At best, attackers would keep trying to disrupt or brick the receiver and network components."
DoS is indeed one of the unsolvable problems. The hope with the (now) anonymous installation and use, as well as the support for Tails on Networked Computer (still waiting for Tails 4.0), make it harder to disrupt users on targeted basis. I've worked hard to ensure Relay Program on Networked Computer doesn't need to know anything about the user or their contacts, and with Tails, ideally the OS doesn't contain anything that could be used to identify the user.
" The Snowden documents and Hayden's comment on killing people based on metadata made it clear something that's anonymous by default was the way to go."
Definitely a concern. Definitely should be an option. Just gotta remind you that the NSA and some other groups automatically classify people using Tor as folks to watch. Whereas, HTTPS at McDonald's WiFi doesn't get that designation. Avoiding Tor can help you avoid getting noticed in the first place. Depends on user's threat model. So, make sure it supports ability to not use Tor even if Tor is default.
"and after I asked about OnionShare's (that's also written on Python) Tor connectivity, Micah Lee kindly pointed me to the direction of Stem. Stem's author Damian Johnson and other members of Tor Project were really helpful and I can't thank them enough."
Sounds like how OSS development and communities are supposed to work! :)
"DoS is indeed one of the unsolvable problems."
Good thinking so far. For non-anonymous routes, perhaps investigate some setup that operates behind Cloudfare to get their DDOS resistance. They just become an extension of the untrusted, network component. Could make that part modular so users can swap out the service provider or even use their own anti-DDOS appliances in data center with big pipes. It's just hard to beat the big, centralized providers since vast majority of solving DDOS is huge pipes and the right hardware/software for detection.
So, there's a few concepts that apply here. You want the Trusted Computing Base, the part system depends on for security, to be as simple and easy to analyze as possible. The limit of verification that big spenders can afford is around 10,000 lines of code. You want it to be in a safe by default language (eg Ada + SPARK, Rust) or proven safe implementation (eg MISRA-C + RV-Match) that maps closely to resources of machine. Then, to catch leaks (important here), you must do a covert channel analysis of all shared resources in the system, esp memory or anything timed, to ensure an untrusted component can't acquire secrets from a trusted component. These were some basic requirements from 1980's security certification that prevented and detected problems in products from that time onward. One of biggest being cache-based, timing channels in VAX VMM in 1992.
Python doesn't map closely to hardware. Its implementation language isn't safe. You can't do covert channel analysis in it. It's also likely sitting on OS that's impossible to verify with tons of bugs each year. A nice, interim step before a verified OS is one we know they'll have trouble attacking or at least few can touch like OpenBSD. Currently, Rust or statically-analyzed C on OpenBSD for sender with full, memory safety for any components on Receiver and Transport. Simplified hardware that's up to date with hardware bugs. They need the extra work cuz the attackers will be hitting those with malicious input.
Since both are located in the capitol area of Finland and names are too close to another not to cause a mix up, I think it's important to clear any confusion:
The FoilChat company was founded on November 2013, and their first app was launched in April 2016. FoilChat is proprietary mobile/web app built in Java, JS and possibly Swift or Objective C. The encryption apparently uses RSA (what even is forward secrecy?), AES-CBC and PBKDF2.
TFC or Tinfoil Chat was named in July 2013, and the first release was in December 2013. TFC is FOSS system built in Python. TFC uses X448, XChaCha20-Poly1305 and Argon2.
So, same country, same start year. Different authors, different target market, different language, different protocol, different security level.
Besides the software it uses a very simple made data-diode[0] circuit especially to prevent key- and plaintext-extraction by limiting the data flow in only one direction. This is used to connect three distinct computers (sending/receiving/networked) from which only one is considered compromised (the networked one).
The rational behind that is as long as your (sending/encrypting and receiving/decrypting) endpoints aren't compromised during installation it's very hard to compromise them later.
That can't be said about Wire on an unsave endpoint like an android phone. On the other hand, Tinfoil Chat isn't the easy to use messenger which you want to recommend to any non tech-savvy person.
The other nice aspect is Onion routing by default similar to Briar, Ricochet, Onionshare and Cwtch. TFC has no server in the middle that could collect metadata, and Onion Services hide geolocation of the users as well.
I completely agree it's not easy-to-use in comparison to other messengers, but I've found it very difficult to increase convenience without losing endpoint security.
