Tin Foil Chat / Hackernet

Hi all,

I’m working on setting up a network that would link Hackerspaces together over Tin Foil Chat, an open source project that aims to make tippy-top level secure communications widely available. The Idea would be to connect us with Noisebridge and then build out the network from there.

The end product would be a dedicated chat terminal that looks and acts like IRC. @TyIsI also had the brilliant idea of having a dot matrix printer print out the chat log, so that we could see and hear when anything stirs in the Hackersphere.

Do you guys think this is the kind of thing that we would want to have here at VHS? If so I’ll happily donate the time and materials needed to get it up and running.


I think it sounds like a very interesting project, building a ‘Data Diode’ looks like it would be a great learning experience in hardware. That said, I don’t know that I’ve ever had a need for a dedicated IRC terminal to a hackerspace in SFO…

My thoughts are that if it interests you, you should try to build it. Whether or not the autonomous space wants it is a secondary concern, and shouldn’t guide your exploration.

Later, when the project is finished, let the space evaluate whether they feel it would be a useful fixture to add to the space. And for that, I think you can just raise it at a QGM.


Ok, I should have made clearer that we’re actually ready for blastoff. I have built everything out and have four small computers that work with TFC on them at the space. It all works, and if people would like to test it out for themselves I’d love to show it off. I shipped another board to Noisebridge that should be getting there today has arrived and should be picked up shortly has been picked up and will soon be set up and connected with our nodes here.

Edit: Took some pics to help clarify–we’re ready to rock!

Data Diode:

Two nodes conversing:

close up of chat environment:

Can I get a hooyah?


This is really neat.

I don’t have a use for it. But I appreciate it nonetheless.

I would support having this as a VHS fixture for a limited time (3-6 months maybe?). Then take it down and remix it into a new interesting project!

1 Like

@lukecyca @Gavitron

Hi there!

I think you make some interesting points that I would like to build off of.

It strikes me that the motivation behind installing TFC at VHS is not to accommodate the vast number of individuals at VHS who are struggling to maintain contact with hackers at Noisebridge, but rather, to begin building a secure communications network between hacker spaces for three reasons.

Firstly, I think only good can come out of connecting people who have ideas and innovation to spare. While TFC should not be the be-all-end-all of communication channels between hacker spaces, it is certainly a cool idea!

Secondly, the survival of VHS is a bit precarious, being largely dependent upon extremely generous donations of time, labour and equipment. How do we garner more consistent attention for a space we love so dearly? How do we rally more support, particularly remotely? Launching a secure communications network between hacker spaces from all over the world is a cool idea that could draw support, new memberships and even press.

Lastly, the right to privacy is threatened more and more every day, even in Canada. TFC is an open source technology that could grant new levels of private communications to regular people. Hacker spaces seem to lend themselves to experimentation and creation. Planting a TFC node in a hacker space is probably the best bet that this technology will be replicated and distributed out into society.

TFC doesn’t take up that much space - why not give it a chance?



1 Like

My dudes this sort of proof of concept demo is what the hackspace is for, and anyone who’s not sold on the idea has clearly not yet seen the top sneaky locker.


@Claire_Baragar @TristanL I feel like I’m being misinterpreted here, and then having that misinterpretation strawmanned.

I read Wes’ first post as “I will do a thing, if I get approval to do so from the VHS peeps”. I tried to be supportive, and pointed out that he needs no such approval to do a thing at the hackspace, it is literally what the space is for. Further, he’d already done the thing, so i don’t know why he phrased it that way in the first place.

that said, it’s cool, and good for you, Wes. I look forward to trying it.

The other part of my post comes from the fact that physical space at VHS is a premium. So I mentioned the standard procedure of getting something installed permanently at VHS, which is to present it at a QGM, after canvassing interest via this post on Talk. Again, not to be dismissive, but to support Wes in finding a place for his project to live that doesn’t prevent others from using the space too. For example, the tables in the centre are meant to be cleared when one leaves, so taking 2 seats for this install deprives others of those seats if it’s left unattended.

All said, this is a novel solution for encrypted communication, and would admittedly garner some press. but I think your last paragraphs are a little more breathless enthusiasm than pragmatic analysis of the method. I confess to only being a middling security boffin, but any actual security derived from the “hardware keys” would have been lost the second the hardware passed through a commercial carrier. In the nationstate threat model, they regularly intercept hardware in transit to breach keys, and at that point this is a hardware TOR proxy, versions of which semi-regularly appear on indiegogo or kickstarter.

Not to take away from the fun of building it, and showing it off - it’s cool, be proud of your work, Wes, and lets find a place to put it so that others can enjoy it. If it can build some social media buzz, then you could reach out to some news outlets to get a photo-op too.

That all sounds good man, and I appreciate the clarity. So I guess the only question that remains is what a good physical space would be? It could fit inside a locker–hence the locker hackily adorned in Security Foil, with the benefit that it locks. But again, we only have so many and it could go just about anywhere. Thoughts?

There’s definitely some understandable confusion here, especially with the picture above that seems to show this taking up space on the tables, but it doesn’t. The actual terminal is just mounted in one of the unused lockers in the front and is easily moved if we ever need that space, so no need to consult the membership via QGM.

Good point—pic is confusing. I’ve been setting up in various places to test, like on the centre table in the pic above, and then pack everything up when I head out.

Sounds good to me!

Hey folks, thanks for your interest in TFC!

(I assume this is just initial testing pre-data diode setups?)

Wrt installation space, perhaps fitting two small netbooks and the data diode circuit on a shelf next to some more permanent (desktop) system used for other purposes could work?

If I’m reading this correctly, you’re referring to sending a pre-shared key on some hardware medium? TFC also supports X448 public key exchange so its unlikely it would be a problem.

Or were you referring to Wes saying they had shipped another board (I take it they meant a data diode circuit), that would be interdicted by a nation-state adversary? That is a possibility, but at the very least, the shipped circuit can be used as a reference when building a new, more trustworthy circuit. Alternatively the receiving party could just re-purchase the security critical COTS parts (TTL adapters and optocouplers) from their local brick & mortar: The sockets exist for the very reason of allowing easy swap if foul play is suspected.

TFC only uses Tor (and Onion Services) as a transmission channel for the ciphertexts. Since you’re running a Tor Onion Service on the relay computer, you shouldn’t use it as a relay/exit node, thus the Networked Computer isn’t comparable to “HW Tor Proxy”. The hint of pessimism in your writing is completely understandable but luckily in this case there’s clear mitigation strategies against possible attacks. I’m also quite sure taking a slightly deeper look into the design would alleviate most of your concerns.

Anyway, I’m extremely stoked for you guys, let me know if you have any questions.


Ps. @Wes I really hope you’ll find time to upload more photos!


No way. Markus, it’s a pleasure to meet you. How did you find us???

You guys, this is the developer for TFC–the lone individual responsible for making this real over the past years and free for all.


And yes, you’re correct–the chat taking place in the pictures is between two single computers (the discontinued atomic pi), each running TFC in the local testing configuration.

You can also find me directly on TFC on one of the test nodes at VHS, currently sitting in a locker covered in…you guessed it…tin foil:



GitHub has some analytics (like referer links) on the repository’ traffic, and I sometimes take a look if there’s suddenly new stars. :slight_smile:


My fingerprint is

86594 62938 96672 21164 54480
06186 21126 54617 08896 48452
12586 03827 20314 16395 40209

@maqp welcome to our forums!

This concept of a common inter-hackspace chat is something that’s intrigued me for more than a few years now, so when I heard from @Wes what he was working on, I was immediately interested.

While you’re here, got any thoughts on hooking up a dot matrix printer using that as an additional output medium for the receiver? My train of thought was that it would be really cool to have either a ticker or a dot matrix printer spring to life on new messages

SomeoneShould™ hook up one of our LED marquees to show the incoming messages

1 Like

I guess external output could/should be a nice feature. Bonus points if it’s a serial out, so we can push it to any receiver, including parallel and other devices.

Hey @lukecyca

See the code block below for a position and the condition on when to call the subroutine that handles LEDs.

Hey @TyIsI

The fastest way to create hard-copies of chat logs is to enable logging for the group with the /logging on command, and then to export the log file at the end of the day with the /export command*, and then by printing the plaintext file with the editor of your choice. To prevent reprinting the messages you just printed the next day, you also need to remove the encrypted log entries of the group from TFC with /rmlogs <groupname> at the end of the first day.

* This requires the TFC master password unless you disable the pwd prompt with /set ask_password_for_log_access False and enter the master password to authenticate the setting change.

A much more cool way to achieve this functionality is to print incoming messages in real time. The easiest way to do this I can think of, is to tinker slightly with the source code. This way none of the steps of manual printing I mentioned above are necessary.

So what you’ll need to do is, open the Destination Computer’s TFC source file that needs editing with root-privileges:

$ sudo gedit /opt/tfc/src/receiver/windows.py

on line 252 of the file:

add the following code block

if self.group is not None:
    print(f"the ID of the group \"{self.name}\" is \"{self.uid}\". If this is the correct group, replace the value ""`None` " f"with the ID below in `pinned_group_id = None`, for example, \"pinned_group_id = b'>\x9f\x08\t'\".You can then hide this message by placing \"#\" in front of this print statement.")

pinned_group_id = None

if self.group is not None and self.uid == pinned_group_id and not whisper:

    wrap_text = True  # Set to False to disable text wrapping.
    wrap_width = 80  # The wrapping width will depend on the resolution of the printer used, font size etc.
    output_via_printer = False  # Set to True  to enable printing via printing
    output_via_serial = False  # Set to True  to send the message via serial interface
    incoming_msg_leds = False  # Set to True once the function call for LED display is implemented

    handle = self.get_handle(timestamp, onion_pub_key, origin, whisper)

    if incoming_msg_leds and origin == ORIGIN_CONTACT_HEADER:
        led_light_soubroutine_call()  # As suggested by lukecyca, when the origin header matches the one associated with contacts it means a message was received from another TFC endpoint. It's not immediately clear to me how this should be implemented (GPIO or whatnot), so I'll leave the details to you.

    if wrap_text:
        wrapper = textwrap.TextWrapper(width=wrap_width,
                                       subsequent_indent=len(handle) * ' ')
        message = wrapper.fill(message)
        if message == '':
            message = handle
        message = handle + message

if output_via_printer:
    import subprocess
    lpr = subprocess.Popen("/usr/bin/lpr", stdin=subprocess.PIPE)

if output_via_serial:
    import serial
    s = serial.Serial('/dev/ttyUSB1', 9600)  # ttyUSB0 will most likely be reserverd for incoming ciphertexts from the Networked Computer

IMO the group the messages of which are to be printed should be hard coded, that way if anyone uses the endpoint for testing or more personal messaging, the added functionality can’t accidentally print something sensitive or that’s unrelated to the conversation that’s intended to be printed out. You can make this even more robust by instead of name, checking the group ID (that can’t be changed for the group) with self.uid == <hard_coded_id_of_group> This way it won’t break if someone changes the group’s name for whatever reason with /nick <new_group_name>.

The “and not whisper” condition should also be included to respect the senders’ wish to opt out of logging some specific messages they send to the group with the command /whisper <more_sensitive_message>. One example that comes to mind is some symmetric secret like a password.

Also, please make sure everyone using the system is aware of the fact the software has been modified to create hard-copies of messages sent to the group :slight_smile:

EDIT: Replaced code block with more modular one that prepends timestamp and handle, has optional text wrapping, and that allows selection of output device.