
Tinfoil Chat – Onion-routed, endpoint secure messaging system - schlowmo
https://github.com/maqp/tfc
======
nickpsecurity
This was one of the few times someone came on Schneier's blog, heard high-
assurance security techniques, and actually used them. Clive Robinson and I
always talked diodes and physical separation. Markus Ottela's improvements on
those concepts were extremely clever. He kept coming back with questions. We'd
feed in things like mitigating covert channels. He'd apply it like that or his
own take. Great stuff.

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.

~~~
maqp
Nice to see you again Nick P!

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.

~~~
nickpsecurity
You too, buddy. I've been here and on Lobste.rs mostly. All my CompSci papers
are in my Lobsters stories if you want to check those out.

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

------
vokep
Brilliant name alone, surprising nobody has come up with it yet.

~~~
pasiaj
[https://www.foilchat.com/](https://www.foilchat.com/)

~~~
maqp
Author here.

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.

------
Not_anchovie
Am I wrong in stating that onion traffic is watched more heavily than non
onion traffic? And honestly it's never the message itself that is watched but
the metadata, or so they say. So as long as they get your metadata, and it
still seems reasonably possible, nothing has really changed.

~~~
roywiggins
If you're not worried that someone has hacked your device to get your
plaintext, then this probably isn't useful.

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.

~~~
maqp
It's not just individual targets. The big concern is economics of automating
remote exploitation, as explained by ACLU's Christopher Soghoian here:
[https://media.ccc.de/v/33c3-8136-stopping_law_enforcement_ha...](https://media.ccc.de/v/33c3-8136-stopping_law_enforcement_hacking#t=1440)

------
mikece
I don't see how this is any more secure than using Wire (via a VPN if you
really want to obscure your IP address further). What am I missing?

~~~
schlowmo
The part of the design which piqued my curiosity and distinguish Tinfoil Chat
from other messengers is the endpoint-security aspect.

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.

[0]
[https://en.wikipedia.org/wiki/Unidirectional_network](https://en.wikipedia.org/wiki/Unidirectional_network)

~~~
maqp
(It's actually only sending computer that must not be compromised during
installation, but in other respects you're right.)

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.

~~~
schlowmo
> (It's actually only sending computer that must not be compromised during
> installation, but in other respects you're right.)

Thanks for clarification, it slipped my attention that plaintext extraction
isn't possible even with a compromised receiving endpoint as long as the data-
diode is in place.

And thanks for your work. I'm currently experimenting with TFC on various
hardware and considering it as topic of my (long due) bachelor thesis in
Software Engineering.

------
Quiark
Also see Cwtch from OpenPrivacy

[https://openprivacy.ca/blog/2018/06/28/announcing-
cwtch/](https://openprivacy.ca/blog/2018/06/28/announcing-cwtch/)

~~~
maqp
I can't wait for this to become a thing! I've loved Ricochet since day one.
OnionShare has been another great system
[https://onionshare.org/](https://onionshare.org/) and I'm extremely happy
I've been able to help them, if only a bit.

------
schappim
This would be fun to implement with 3 stacked RPi Zeros.

~~~
fsagx
I was not aware of this project, but I have had a similar hardware setup half-
completed on my workbench forever. I am using an old thinkpad T40 (love the
keyboard, and it seems to be indestructible) with a serial connection to a RPi
velcroed to the case. The laptop passes cyphertext and destination data only
to the Rpi, which forwards it along and also does the reverse. My thoughts
were that if I disable SLIP-type functionality on the laptop, along with all
networking, that it would sufficiently isolate the laptop. Now you've got me
thinking about 3 RPi-zeros packaged to fit in the CD drive slot...

------
HocusLocus
I joined a secure chatroom to meet Alice, found only a bunch of Bobs.

~~~
Lowkeyloki
But Eve was nowhere to be found. That's how you know it works.

------
Skunkleton
[https://xkcd.com/538/](https://xkcd.com/538/)

~~~
Skunkleton
I realize that linking XKCD doesn't add much to the discussion. That said, it
is pretty irresponsible to claim that this tech defends against nation-state
actors.

