This is a blog about privacy, freedom and independence. We focus on what users can do, with existing tools. We seek to demystify complex stuff, and make it broadly accessible, with instructions. We encourage self-reliance, and mistrust of marketing bullshit.

In part, this is an experiment in do-it-yourself onion service hosting. If it survives, it's an example. If not, it's a warning. We have documented the design and setup, with detailed instructions. There is some risk in doing that, of course. But security through obscurity doesn't work, long term. We will tweak the setup and instructions, based on experience and criticism. If the server goes away, we'll recreate the blog on another server, and report on what happened. Time will tell. And do see Warnings! for more background, details, known limitations, etc.

For the most part, we met on Wilders Security Forums [SHA-256 Fingerprint]. The late Veeshush first suggested that we create private space, and so we dedicate this blog to his memory.

We will periodically update posts with comments submitted here. Before posting, please encrypt comments to our public GnuPG key. You can also propose posts. We will post just about anything, except spam, doxxing, and such. But please note that we focus on defense.




Remote LXDE Desktop as Tor Onion Service



Remote Debian Setup with LUKS and Dropbear: Introduction (Part One)



Review of the Pond Messaging System



Implementing Physical Networking (iVPN-Tor) / Workspace Isolation with Raspberry Pi 2



Hint: Transcribing Bitcoin Addresses Between VMs



Remote Debian Setup with LUKS and Dropbear: Building Debian Installer (Part Two)



Remote Debian Setup with LUKS and Dropbear: Installing Debian (Part Three)



Remote Debian Setup with LUKS and Dropbear: Installing Tor and VirtualBox (Part Four)



Remote Debian Setup with LUKS and Dropbear: Creating Tor-Gateway VM (Part Five)



Remote Debian Setup with LUKS and Dropbear: Creating Web-Server VM (Part Six)



Creating Integrity Friendly Services: Robustfiles



OpenVPN Onion VPS for Evading Discrimination Against Tor

Contact Information


Right click on Erehwon Team and copy address to clipboard.


Right click on Erehwon Team and copy address to clipboard. This works with Sigaint and TorBox accounts, and probably with accounts on other onion mailservers that peer with them.


Install Pond, create a shared secret, encrypt it (and a contact name) to our public key, and upload here.



Secure Submission of Comments and Proposed Posts

Before posting comments, proposed posts or whatever, we recommend encrypting to our public GnuPG key. After encryption, paste ASCII-encoded text here and hit "post". The private key is not stored on this server. And so posted stuff will remain secure, even if adversaries have eavesdropped on Tor, or later compromise the server. Comments will not appear until we update the site. General comments are here.


This is a Tor onion ("hidden") service, and so we are all relatively anonymous here. However, the Tor Project does warn: "This is experimental software. Do not rely on it for strong anonymity." And indeed, it's well known that Tor is vulnerable to global adversaries. However, to the best of our knowledge, no stronger anonymity system has been implemented at usable scale. There are some workable kludges, however. For more on adversaries and anonymity systems, see this guide by Mirimir, published on iVPN's blog.

The onion service protocol is old, and has suffered from neglect. For example, in mid 2014, someone reporting to the FBI (perhaps this group) apparently identified Silk Road 2 servers through a "relay early" traffic confirmation attack. The vulnerability was quickly fixed. But it's telling that the Tor Project apparently ignored the attack for five months. There has since been talk of improving hidden services through crowdfunding. Also see this Tor Project page that aggregates blog posts tagged "hidden services". Bottom line, users probably have stronger anonymity than server operators do. That's because servers can so easily be probed. But do be careful.

In our experiment, we focus on security and anonymity. This is a dedicated (albeit tiny) hosted server, running Debian with LUKS full-disk encryption. However, that offers only limited protection, because we can neither control nor monitor physical access to the server. We don't even have physical access to the server! But as discussed in the setup guide, that was an intentional tradeoff. The hosting service knows nothing about us. We leased the server anonymously via Tor, and we also manage it via Tor. And we use Tor through nested VPN chains. Maybe Mirimir is too well known for that to count for much. But in practice, one would not associate such persistent and public pseudonyms with onion sites where anonymity mattered.

For better security, the web server and Tor client are isolated in separate Debian VMs. Even if the web server VM is compromised, it can only reach the Internet through the Tor gateway VM. We use static HTML for speed and security. It loads faster via Tor, because there's far less client-server dialog. And there's no need for server-side MySQL, or client-side JavaScript. We do use a simple PHP script for securely uploading comments via POST, but that's totally server-side. Sending of referers is disabled.

We retain lighttpd access logs, but only what's needed for debugging, tuning, detecting attacks, etc. We log only 1) request timestamp; 2) item requested; 3) time used; 4) information about connection status; and 5) bytes sent. Onion services don't know your IP address, or vice versa. We don't log referer, user-agent, or anything else from the HTTP request header. We do log lots of other stuff: standard Debian logs, full atop logs, VirtualBox logs, Tor debug logs, and so on. This is an experiment, after all. Maybe even a honeypot. But we periodically download logs, and wipe them from the server and VMs.

Even if Tor is secure and anonymous, and even if operators are honest and have their shit together, all bets are off when using any onion service via Tor2web proxy. You know that you're using a Tor2web proxy when the URL ends with anything except ".onion" (such as ".onion.direct", ".onion.link", ".onion.to", etc). Some Tor2web proxies don't even use HTTPS, so ISPs and other intermediaries can eavesdrop and spoof. Even if connections are secured by HTTPS, nothing prevents proxy operators from eavesdropping or spoofing. And ISPs and other intermediaries can still see URLs. Sadly enough, most users who find onion services via Google etc will probably be using Tor2web proxy links. If that's you, please come back after installing Whonix, or at least Tor browser. Or use Tails.

Anonymity benefits notwithstanding, it is a hard problem that hosted servers are just out there, somewhere. You can access them via SSH and KVM. You can open tickets with providers. But you can not, with any certainty, know where the server is, or what's happening to it. Once an adversary locates the server, the game is more-or-less over. But how can you even know if or when that has happened?

An adversary might just take the server down, without compromising full-disk encryption. Then we just recreate the setup on another server. But a clever and resourceful adversary may fully own the server, and we won't know anything until they tell us about it. Given that, we must operate as if this has already happened.

So how do we deal with that? The major risk to users from this blog is bad advice. So please don't take our word about anything. Don't just rely on our guides. Consult other sources, and make sure that you understand what you're doing. This site serves only plain HTML and text. The NoScript "stuff blocked" status in Tor browser is bullshit, by the way. But do check page source. Anyway, be extremely suspicious if our site starts pushing JavaScript, or offers downloads. And please do use Whonix or Tails. Tor browser is OK for playing around, but it's not secure, especially on Windows.

If this server has been compromised, you can't trust anything on it. But let's assume that you can trust these words, for now. And do save this page, in case shit happens. First compare the local copy of our public GnuPG key with other online copies: Keybase, Robust Files, this Wilders thread, and this Swehack thread. Just get the sha512sum for each clean text file, and see if they're the same. If the sha512sums don't match, make sure that all of the keys that you're comparing have Unix line endings. Also make sure that there's exactly one line return after "-----END PGP PUBLIC KEY BLOCK-----". Once you have a copy of our public GnuPG key that you're confident about, import it into GnuPG. There's also a version of our public GnuPG key on this server that contains "our" photo. And its sha512sum is obviously different.

We have signed all pages on this site, and you can use our public GnuPG key to verify their authenticity. For example, save this page as a plain HTML file. That will presumably give you "erehwon.dev.null.html". Then open a terminal window, and execute "gpg --verify erehwon.dev.null.html". You should get output like this:

      gpg: Signature made [datetime] using RSA key ID BE4A5B47
      gpg: Good signature from "Erehwon Team <sireliah@sigaintevyh2rzvw.onion>"
If you see "BAD signature", check another page. Maybe we fucked up. If more than one signature is bad, something is seriously fucked up. Maybe we've posted about it on Wilders, Swehack, or the Cypherpunks mailing list. Time will tell.