Greetings from VanHack!

Hello Noisebridgers!

I’m reaching out from Vancouver Hack Space (also VHS, or VanHack) to see if Noisebridge would like to connect with us. We are testing out a hardware-secure messaging client called Tin Foil Chat locally at the space, and we wondered if Noisebridge would like to create a node to link our spaces. If things go well between us, maybe we could expand the network!

Here’s a pic of our full hardware isolated TFC node in action:

Any questions, feel free to reach out. You have some NB fans up north!

(Plot twist - it’s actually a listening device …)

Nice try, FBI


back into your Faraday cage, daemon!


(pretend this never happened) <- let’s talk :slight_smile:

Hey! I’m on East Coast time, and was asleep when this was posted (early night). And for sure! I think we’d love to connect, keeping hackerspaces alive has been tough over here.
It sounds like we’ll need to configure our Unicorn server or similar NB affiliated device (Cc @James) to get this working. Maybe we can install this and take it out for a spin with you guys?

The idea of the design is to have have “partially airgapped” computers talk without the ability for any actor to remotely exfiltrate meaningful data. Each endpoint needs 3 computers that utilize a data diode to enforce the one-way flow of information. Messages are typed into the upstream computer and sent across a data diode to the networked computer. They are then passed to a contact’s networked computer which forwards them across another data diode pointing toward a destination computer. Like this:

The are three levels of configuration:

  • Testing config that simulates 3 computers

  • Qubes OS config that uses strict firewall rules to pass info between VMs.

  • Hardware data diode config that uses 3 X86 computers and the physical data diode device. Designed to be secure against remote APTs.

I recommend anyone interested check out the Github page for TFC:

We’d love to help you guys get set up :slight_smile:

1 Like

Hello VHS! It looks like proper setup would involve some actual hardware on-site, will dig into git and see what all is involved there.

If you happen to be available please join us or send an emissary to our weekly general meeting tonight starting at 8pm

I appreciate your ephemeral protocol which looks you intend for this thread to auto disappear, we can also switch it to visible to logged in users only to side step the scrapers.

Made me curious on using ARM devices with the diode… what are the actual minimum system specs needed for each of the machines? When generating the VM’s how many cores and ram do you allocate?

Found this thread detailing Raspberry Pi’s not being supported, but the fact remains that there is a vast variety of both ARM and x86 sbc devices all over the market. Would be really useful to know exact specs required for setting this up on each of the three machines. Also, I see no mobile support is possible, which is fine. Cool project!

Hi everyone! The good folks at VHS I’ve been helping a bit linked me this thread.

I added some recommendations for system requirements to the FAQ.

Indeed. The main requirement is, in data diode isolated configuration you should be able to remove all hardware that could be used to exfiltrate keys from the Source/Destination computer. Many SBCs seem to sandwitch the Wi-Fi/BT into the CPU die itself, which makes them difficult, if not impossible to airgap reliably. This is why I gave up supporting Raspberry Pis after gen2.

Given the past discussion with VHS, the goal doesn’t seem to be dialing the isolation to 11, thus anything that runs Python3.7/3.8 should do fine. I’ll try to help you debug issues on SW side if you encounter any. Alas, I’m not made of money atm so buying SBCs isn’t currently possible.

The Networker side of TFC (Networked Computer + Relay Program) could in theory be run on a smartphone with a dedicated client, but unfortunately the bulkiness of data diode and Source/Destination computer would still be a problem:

Reliably airgapping a smartphone for use as Source/Destination Computer requires Andrew Huang -level skills. At most I could assume the user is able to remove wifi-cards and perhaps solder through-hole components (or at most, SMT components of an inexpensive HW such as the data diode PCB).

The user probably already owns some form of laptop/desktop PC for daily use, so the assumption is they’d use that as the networker.

For really compact setups, three GDP Pocket2s with de-soldered Wi-Fi interfaces, and data diode with USB-to-TTL adapters inside the USB-plug could be used. But that’s anything but inexpensive / easy.

Quick correction here. This was indeed the case in previous versions, but it’s since been upgraded to use Qubes’ qr-exec RPC (the same one Qubes uses to send files from one VM to another) which removes the network stack from the attack surface.

Anyway, let me know if you have any questions! :smile:


Thanks!!! :heart:

Makes sense, perhaps we can work together to find a casual, off-the-shelf diy solution. Here are a couple 64-bit x86 sbc devices:

RockPi X - brand new $49 - $59 x86 sbc device with up to 4gb ram.
Atomic Pi - x86 sbc device with 2gb ram that has always been ~$40.00

Any suggestions on how I might find devices that avoid this? Perhaps those without Wi-fi and BT…?

RockPi E is available 64-bit ARM with no wifi/bt and 2gb ram for $35.00 while remaining Super tiny. For $37.00 you can add POE.

Nice, curious on any ways to make this both more affordable, possibly require less power, and be compact! Obviously, that is not the primary goal when we can also use VM’s. :+1:

We do have spare boxes which could be re-purposed for a physical hardware version.

Totally understandable as an individual. Maybe we can work together in acquiring the hardware to test out various configurations that work for the spaces!

Yeah that should do it. Some netbooks may be cheaper than a $40-50 SBC + screen + peripherals + battery and charger. It of course depends on what the hackerspace has to provide beforehand. I’m myself using age old ~200USD netbooks that have removable wifi network cards.

E.g. Newegg lists some sub $200 chromebooks that might run Ubuntu.

TFC also has something called local test install configuration that runs the three main programs in Terminator. The only “isolation” is the behavior of the programs to only send or receive data. There is no key exfiltration security in that case but it’s not a large concern for a hackerspace with multiple users.

VMs could of course be used if one wanted to pass data between VMs via bridged USB-to-TTL adapter and the hardware data diode. (The Qubes configuration uses VM based isolation for SW only security). The local test runs even the cheap netbooks, but running e.g. three VirtualBox VMs requires a bit more computing power, and the QubesOS is incredibly picky on HW and requires at least 8GB of RAM etc.

Wonderful! A community working on finding usable hardware is what I’ve always hoped would happen!

might find some ideas to consider for hardware here ->

1 Like

Super cool project! What are your goals with TFC? How can it be extremely important in the grand scheme of things?

If it can run on totally open hardware, allow for many identities per physical node, and be made as easy to get started with and accessible as possible, I could imagine something like this as an even more secure alternative to SecureDrop, perhaps.

What are the technical limitations on message size? I ask in thinking about sending files over TFC – perhaps ones too large to fit into RAM.

1 Like

What are your goals with TFC?

Time will tell. Currently it’s in maintenance only.

How can it be extremely important in the grand scheme of things?

The remote exploitation of endpoints will become a tool of first resort for LEAs due to the deployment cost of exploits being negligible compared to the sunk cost of their development so over time the project (or at least the architecture) will become quite a bit more important.

allow for many identities per physical node

It’s currently not possible to do this but there’s no technical requirement. “Multiple identities” might not even be necessary once Tor Project implements prop224 basic authentication so you can appear selectively online. But if there’s a use case for it, it wouldn’t be impossible to add multiple identities. But new features will have to wait, I’m focusing on my studies for the time being.

I could imagine something like this as an even more secure alternative to SecureDrop, perhaps.

Sure, journalists could use TFC to establish secure anonymous links with sources. Both endpoints need to be powered on continuously to allow asynchronous communication. However, purchasing TFC-related hardware etc. isn’t necessarily what a non-technical whistleblower would want, and ordering the components etc. might leave a bigger paper trail than throwing Tails onto an old thumb drive and disposing of the thumb drive and an old laptop after making the leak via public wifi hotspot. So the OPSEC is quite complicated. IMO TFC works better in closed communication of political dissidents etc.

What are the technical limitations on message size?

The size of RAM is the only limiter for individual messages. Larger text should be sent as file (as it’s faster and has less parsing overhead on receiving end). If traffic masking mode is used by the sender, even files are sent as individual message-like packets. Traffic masking is very slow for sending large files, but the idea is you’re sending packets at constant rate anyway, so sending file data is more useful than sending noise data. Also, sending a file has smaller priority than messages so the file transmission will take place when you’re not chatting.

I ask in thinking about sending files over TFC – perhaps ones too large to fit into RAM.

TFC uses compression for files and larger messages so AFAIK the entire compressed data needs to fit in RAM. Files larger than the RAM probably shouldn’t be sent over TFC anyway, as that will must likely unnecessarily tax the Tor network. But it can be done by splitting the compressed file in multiple parts (separate compression programs have better support for decompressing several parts). It’s also a bad idea in general. At the default speed of 19200 bauds, sending a 1GB file over data diode takes more than 6 days.

Another issue is the Reed-Solomon erasure code that adds a lot of computational overhead for large amounts of data. So you can stretch these limits by disabling error correction, and/or by increasing the serial interface baudrate, or by tweaking your own fiber-optic data diode. But since the isolation mechanism breaks if you try to forward a file by moving it manually from Destination to Source (never do that!), TFC will never be practical as a file sharing tool. However, a journalist/protester uploading a photo or small video from conflict zone by connecting the camera only to Source Computer, is something that can be done.

1 Like

Whoops, meant to say “there’s no technical restriction”.

Good point; I agree that LEA hacking will likely become more prevalent over time.

I was thinking more like journalists running TFC hardware and sources doing the software-only version.

Does it make the hardware significantly more expensive to increase the bandwidth?