Should be merged with Freedombox/FreedomBuddy and placed under the name FreedomBox/FreedomBuddy.


?FreedomBuddy is designed to let users negotiate services without interference from third parties, preventing man-in-the-middle attacks by using pre-shared keys. Santiago is designed to let users negotiate services without third party interference. By sending OpenPGP signed and encrypted messages over ?HTTPS (or other protocols) between parties, I hope to reduce or even prevent MITM attacks. ?FreedomBuddy can also use the Tor network as a proxy (with Python 2.7 or later), allowing this negotiation to happen very quietly.

It's designed to operate as a sort of distributed DNSSEC that lets only the people you trust find you.

?FreedomBuddy aims to be accessible to less technical users. ?Santiago is the old name for the ?FreedomBuddy system.

?FreedomBuddy version 0.3 is out and available on ?GitHub. It now comes with:

Next Steps


?FreedomBuddy currently lives at ?Github.

Setup instructions are included in the Freedombox discussion list.

setup instructions

1. If you want to test over Tor, get the Tor Browser Bundle:

2. Install pre-requisites:

3. You need a PGP key.

4. You need a production.cfg or test.cfg file with contents like

5. You need an SSL certificate (the ssl-cert package is required).

6. Either set up a Tor listener on port 8118, or set the proxy port to

7. Run make once in the Plinth root directory to create the config

8. Running bash in a console will set up a ?FreedomBuddy

At this point it should successfully interact with other ?FreedomBuddies in the world. To serve it correctly over a Tor Hidden Service, you may need to change the protocol (see from "https" to "http" and symlink the "https" protocol directory as "http".


First, a short history lesson in by way of explanation: A few years ago, Comcast started blocking Lotus Notes for no apparent reason. Users were negotiating connections between their computers and Comcast was censoring the messages. To simplify things terribly, Alice would try to send Bob some new notes. Bob would tell Alice to send them along but that acceptance would be censored: Alice never received Bob's reply and notes were never exchanged.


Santiago avoids this issue by encrypting the messages that negotiate connections: now, neither Comcast nor your nosy next-door neighbor will know what services you're negotiating, keeping out the people who have no business poking into your business. Securing the connection process allows you to set up an encrypted connection to your friend that other services can use, making it still harder for third parties to interfere in your communication.

I'm going to host a ?FreedomBuddy node as a Tor hidden service. That will let my buddies find me online to use the wiki I'm sharing with them, even as we both move constantly (through meatspace and the network).

How would this work?

Tor Hidden Services (or other protocols, maybe I2P, GNUnet, etc) can act as static IP addresses. So, if I use that to host the ?FreedomBuddy service, my friends will be able to find me, because that location is my unchanging, cryptographic identity.

We could stop right here and have no need for the ?FreedomBuddy service, but there's one functional problem: communicating over Tor is really slow. So, we can use the ?FreedomBuddy system to exchange our current IP addresses (for any service), and connect directly to one another, without going through any sort of proxy. This sort of connection, while less anonymous, is usually much faster.


?FreedomBuddy relies on the user having a set of friends' trusted PGP keys. Finally, since we already have a whitelist of permitted users (through their PGP keys), you could configure each service to allow only whitelisted users to connect.


If you use a ?Tor hidden service as your Santiago service address, that can act as static IP address, allowing you to negotiate with your friends even as you both move around and change IP addresses.



Complete indistinguishability for both client and server against an active attacker who is willing to break some handshakes to identify at least one of the parties involved is a seriously difficult (possibly intractable) problem. For one thing, the TLS handshake currently leaks a lot of identifiable information about the server at least, as well as the capabilities and extension offered by the client.

ISP control

This is no communication panacea, the folks in control of your internet connection could still cut it off for exceeding your bandwidth cap, for example. However, it does make it significantly harder to determine what services are being negotiated.

identity and pre-shared key

The pre-shared key bit might help to reduce the technical density of the problem, making it more accessible to grandmothers than, say, a custom VPN ethernet interface: people understand identity much better than they understand technical issues. That's not to say that people even understand identity well. But, without going deep into the philosophy, most folks seem to have an intuitive understanding of the subject.



Work Space





Live Help

Where To Start













Use cases





HELP & DISCUSSIONS: Mailing List - #freedombox | CONTACT Foundation | JOIN Alioth Projects, GitHub

Next call: Social Hacks: Saturday, August 13th, 2016, 14:00 UTC

Last news: New Wiki License To Be Effective on June 13th - 2016-05-31