Generate A Vanity .onion Address For Your Tor Hidden Service Using Scallion

Ever wonder how Tor sites get those custom vanity .onion addresses such as silkroada7bc3kld.onion? These addresses can be generated by hidden service operators for production use, and are just as secure as the automatically generated (and often more cryptic) addresses.

Hidden service .onion addresses are really just the public part of a key pair. Utilizing asymmetric encryption, a hidden service uses the public key (a 16 character string that functions as the actual address prefix) and a private key (a much longer string that is known only to the hidden service) to verify the identity of the service. Anyone connecting to the public key can only do so if the hidden service has access to the private key. Under normal circumstances, only the service operator has access to that private key, so you could trust that the address has not been hijacked.

Keep in mind, while it takes a long time, it is possible for someone to generate the same keypair as another hidden service. While computationally expensive, entities able to throw enough resources at generating an identical address would be able to do so much more quickly than someone acting alone on a sole machine.

 

Generation with Scallion

Scallion is one tool that can be used for generation. Unlike previous tools for generation addresses, Scallion focuses on GPUs, meaning it works much faster than CPU-targeting utilities in most cases. In my experience, Scallion does not work on ARM devices (Use Shallot or Eschalot instead), but if you have an x86_64 processor and some sort of video graphics (integrated or otherwise), you should be good to go.

Let’s get started generating custom .onion addresses. I will assume that you have access to a Linux machine and are familiar with the terminal. I will be using Debian, but this guide should be easy to modify for most distributions.

First, install some dependencies and then clone Scallion onto your machine:

$ sudo apt install clinfo mono-complete mono-devel nvidia-opencl-common nvidia-opencl-dev nvidia-opencl-icd libssl1.0-dev beignet beignet-dev ocl-icd-opencl-dev ocl-icd-libopencl1
$ git clone https://github.com/lachesis/scallion.git

Now, we will move to the scallion directory, and build the scallion executable:

$ cd scallion
$ xbuild scallion.sln /p:TargetFrameworkVersion="v4.5"

Next, we will get a list of all of the devices that can be used for generating addresses:

$ mono scallion/bin/Debug/scallion.exe -l
Id:0 Name:Intel(R) HD Graphics Skylake Desktop GT2
    PreferredGroupSizeMultiple:16 ComputeUnits:24 ClockFrequency:1000
    MaxConstantBufferSize:134217728 MaxConstantArgs:8 MaxMemAllocSize:3221225472

We can see I have one device with an identifier 0 that I can target. You may have more than one device.

Now we can use Scallion to find an address that starts with a word or phrase of our choice. Let’s start Scallion with 8 threads, and have it use device 0. We will look for addresses that start with “apple”. After a little waiting, you should get some similar output with the .onion address (public key) and the private key:

$ mono scallion/bin/Debug/scallion.exe -t8 -d 0 apple
Cooking up some delicious scallions...
Using kernel optimized from file kernel.cl (Optimized4)
Using work group size 16
Compiling kernel... done.
Testing SHA1 hash...
CPU SHA-1: d3486ae9136e7856bc42212385ea797094475802
GPU SHA-1: d3486ae9136e7856bc42212385ea797094475802
Looks good!
LoopIteration:1  HashCount:16.78MH  Speed:98.7MH/s  Runtime:00:00:00  Predicted:00:00:00  Found new key! Found 1 unique keys.

  2018-01-03T00:24:24.645322Z
  applencoaipu4tqj.onion
  -----BEGIN RSA PRIVATE KEY-----
MIICXgIBAAKBgQCcDTg3+pON2oUclpStVlFVhtcpleNwtmdO3ZVuN2cPe9tyATjH
fye++edUSTwVm6EZZABrK3iSBdGAITXxRpc5dBM+SHPals6DEECRffa+d2QazJq2
xjhU7sfocXMzly+lALtE3T/I8yhFwcDlv/LGsWn6P9Hh2A2otDz3SCeGCQIEXGYD
DwKBgBkW9kDgDFafPvLhA0YIaDei5tBR5gJXt2vqabJfbi8P7RKF3GJ6vlHXu7xS
XikDmN5lJ+dAeFH5mH4mx0TAyfpjHvwrvCcVFPuXnt8ufDHYnRc5B8hYg/bpe0eS
9iZpSFKvq1Io49Wlt04KKAW86Nk0EJRPlkU6ewfOvs5AHI9vAkEAz+N847csHbcx
79RlBhvoT+GUYoSdKvtB+0pyv4mRYEV3SHFATVwXlTksOcPkI1dFVftkoXaEEld2
RTmsVlaLNQJBAMAqnKx+s4LAj2NxzBTpbcpeVY+DauWBoNMUo5Qdqm3SSV4hPsbd
Bf99XvCWS+7tD+jhks4mffOcKQZNK4JHVgUCQQDH6n4Uf2QWhZHvnY0niHE0ydiu
f2KIBc2spzWzcCWiyBqmtAbjhT3/HajJHB3zYdzHPrI0uVFHVqrjBnhRKSVjAkEA
vWUSQ9u4jPBH/z3ahdD6kbvQA90Jxo/JQgrwaHAUrli/SvmOC3xx/kSWLVPSlSk4
p96zeIgMolOS4Tfiff+newJAUaCQumLZori7RCT+2XOXFCoV03TLlujS8L+2sNH1
LPR8Brc3CBv+ZlleYnJCR4J88py8dFGYSYM95qmpCek1SA==
-----END RSA PRIVATE KEY-----

After generating a private key and address, you will want to use them with your Tor hidden service. The private key and address usually sit in files within the /var/lib/tor/hidden_service/ directory and are named hostname and private_key respectively.

 

For a full list of options and flags, we can run the scallion executable with the --help flag:

$ mono scallion/bin/Debug/scallion.exe --help
Usage: scallion [OPTIONS]+ regex [regex]+
Searches for a tor hidden service address that matches one of the provided regexes.

Options:
  -k, --keysize=VALUE        Specifies keysize for the RSA key
  -n, --nonoptimized         Runs non-optimized kernel
  -l, --listdevices          Lists the devices that can be used.
  -h, -?, --help             Displays command line usage help.
      --gpg                  GPG vanitygen mode.
  -d, --device=VALUE         Specifies the opencl device that should be used.
  -g, --groupsize=VALUE      Specifies the number of threads in a workgroup.
  -w, --worksize=VALUE       Specifies the number of hashes preformed at one
                               time.
  -t, --cputhreads=VALUE     Specifies the number of CPU threads to use when
                               creating work. (EXPERIMENTAL - OpenSSL not
                               thread-safe)
  -p, --save-kernel=VALUE    Saves the generated kernel to this path.
  -o, --output=VALUE         Saves the generated key(s) and address(es) to this
                               path.
      --skip-sha-test        Skip the SHA-1 test at startup.
      --quit-after=VALUE     Quit after this many keys have been found.
      --timestamp=VALUE      Use this value as a timestamp for the RSA key.
  -c, --continue             Continue to search for keys rather than exiting
                               when a key is found.
      --command=VALUE        When a match is found specified external program
                               is called with key passed to stdin.
                               Example: "--command 'tee example.txt'" would
                               save the key to example.txt
                               If the command returns with a non-zero exit code,
                                the program will return the same code.
 

Generate A Vanity .onion Address For Your Tor Hidden Service Using Eschalot

Ever wonder how Tor sites get those custom vanity .onion addresses such as silkroada7bc3kld.onion? These addresses can be generated by hidden service operators for production use, and are just as secure as the automatically generated (and often more cryptic) addresses.

Hidden service .onion addresses are really just the public part of a key pair. Utilizing asymmetric encryption, a hidden service uses the public key (a 16 character string that functions as the actual address prefix) and a private key (a much longer string that is known only to the hidden service) to verify the identity of the service. Anyone connecting to the public key can only do so if the hidden service has access to the private key. Under normal circumstances, only the service operator has access to that private key, so you could trust that the address has not been hijacked.

Keep in mind, while it takes a long time, it is possible for someone to generate the same keypair as another hidden service. While computationally expensive, entities able to throw enough resources at generating an identical address would be able to do so much more quickly than someone acting alone on a sole machine.

 

Generation with Eschalot

Eschalot is one tool that can be used for generation. Eschalot is based off of another tool I previously covered called Shallot. While Shallot only allowed for some basic matching with regular expressions, Eschalot gives the user a bit more control and even supports word lists. Eschalot will not be as fast as a tool like Scallion, but it is (in my opinion) more portable as Scallion seems to have issues running on ARM-based SOCs.

Let’s get started generating custom .onion addresses. I will assume that you have access to a Linux machine and are familiar with the terminal. I will be using Debian, but this guide should be easy to modify for most distributions.

First, install OpenSSL if we don’t have it, then clone Eschalot onto your machine:

$ sudo apt-get install openssl
$ git clone https://github.com/ReclaimYourPrivacy/eschalot.git

Now, we will move to the eschalot directory, and build the eschalot executable:

$ cd eschalot
$ make

We can now make sure everything is working using the builtin testing option:

$ make test
./worgen 8-16 top150adjectives.txt 3-16 top400nouns.txt 3-16 top1000.txt 3-16 > wordlist.txt
Will be producing 8-16 character long word combinations.
Reading 3-16 characters words from top150adjectives.txt.
Reading 3-16 characters words from top400nouns.txt.
Reading 3-16 characters words from top1000.txt.
Loading words from top150adjectives.txt.
Loaded 150 words from top150adjectives.txt.
Loading words from top400nouns.txt.
Loaded 400 words from top400nouns.txt.
Loading words from top1000.txt.
Loaded 974 words from top1000.txt.
Working. 100% complete, 31122412 words (approximately 377Mb) produced.
Final count: 31366539 word combinations.
./eschalot -vct4 -f wordlist.txt >> results.txt
Verbose, continuous, no digits, 4 threads, prefixes 8-16 characters long.
Reading words from wordlist.txt, please wait...
Loaded 31366539 words.
Sorting the word hashes and removing duplicates.
Final word count: 31363570.
Thread #1 started.
Thread #2 started.
Thread #3 started.
Thread #4 started.
Running, collecting performance data...
Found a key for kindland (8) - kindlandudsw7nga.onion
Found a key for loudhour (8) - loudhourvype7cyn.onion
Found a key for cutwaxwin (9) - cutwaxwinstsf6mk.onion
Total hashes: 177519717, running time: 10 seconds, hashes per second: 17751971

When done, simply clean up the test results:

$ make cleantest

 

Now is a good time to use Eschalot to find an address that starts with a word or phrase of our choice. Let’s start Eschalot in verbose mode, with 4 threads, and have it continue to look for addresses even after it has found one. We will look for addresses that start with “apple”. After a little waiting, you should get some similar output with the .onion address (public key) and the private key:

$ ./eschalot -t4 -v -c -p apple
Verbose, continuous, no digits, 4 threads, prefixes 5-5 characters long.
Thread #1 started.
Thread #2 started.
Thread #3 started.
Thread #4 started.
Running, collecting performance data...
Found a key for apple (5) - appleiujtls4awea.onion
----------------------------------------------------------------
appleiujtls3awea.onion
-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQDQo/ArZ/Em1/1wvTlpVSjV5eTnYelelzJ670kBsO8/Yjvq5GGu
M7LdAUVUBdrF9qO2I24eKNul0sam+jmvov8WvFAk2eSk2p5VefVabxvUvSiOVNwA
cw3XmHlbWPpriOmyFiTOQtzYXHqG4YNPna9VQMR5S+86hy4AEiJoJNEdpQIEAT1u
AwKBgF8uYVx00lZPzAUxAFmrw85H78001d767m+7OLWmj5dDSgC0nbNWHbICwP8y
fczIoQ/DLHGOHK1WtPiUXNw7E/EX3f4DQ3E0zssIRZOBhmy6D3umLUHBILI/6n/F
hzD8U/Zy3W6rgZ35Ib34Mv35Kq/d6DFUD7u6qWv8CrD0gt7zAkEA6ASM6cI/EaT+
iTh+OSt+Pdh6N3Kofe2QGbqb8Y99tsX07nHOzl8EH0kkIxO26RDuWdT5J3wRUCkA
UGyqVrefNwJBAOY0y7qkSTtLE1S/TwhMWc8mEWqewj4FVT+H/sY0hlfZ5VW7xMjf
usKD99eTDLgJ0joqpIOlmmUHAFHKCkdHwAMCQQDVBCQWZJ/qzFqmFvs20erbTzrk
4VNgV6QmOJDidMAxqyjyocUnA1/vASHJcJnunEsdXvpADVKsV3hwO4jSIxqPAkAs
yCr9mXF5c+wWErdlNdYmOTthqIeCxZssr0fRYVadbtfQ9rEHV0UFEdUp50JWAX3s
oy7t+b7kPoTpTteKshyTAkAPzLpDXQPEWKIJL5uqTR1G/iR7FlQ/jaFd44OCNtmz
azXGB3asSbLcmc3z9KnOb5xzeApPW7hIPy/yxYCgEdrE
-----END RSA PRIVATE KEY-----

Additionally, you can use the included worgen utility to generate word lists that can be fed into Eschalot. Below is an example series of commands that will generate 10-character strings by mixing nouns that are 3-10 characters long each, and then run the list through Eschalot. Eschalot comes with several different word lists included what can be used by the worgen utility.

$ ./worgen 10-10 nouns.txt 3-10 nouns.txt 3-10 > wordlist.txt
$ ./eschalot -vct4 -l 10-10 -f wordlist.txt > results.txt

After generating a private key and address, you will want to use them with your Tor hidden service. The private key and address usually sit in files within the /var/lib/tor/hidden_service/ directory and are named hostname and private_key respectively.

 

For a full list of options and flags, we can run the eshalot executable with no arguments:

$ ./eschalot
Version: 1.2.0

usage:
eschalot [-c] [-v] [-t count] ([-n] [-l min-max] -f filename) | (-r regex) | (-p prefix)
-v : verbose mode - print extra information to STDERR
-c : continue searching after the hash is found
-t count : number of threads to spawn default is one)
-l min-max : look for prefixes that are from 'min' to 'max' characters long
-n : Allow digits to be part of the prefix (affects wordlist mode only)
-f filename: name of the text file with a list of prefixes
-p prefix : single prefix to look for (1-16 characters long)
-r regex : search for a POSIX-style regular expression

Examples:
eschalot -cvt4 -l8-12 -f wordlist.txt >> results.txt
eschalot -v -r '^test|^exam'
eschalot -ct5 -p test

base32 alphabet allows letters [a-z] and digits [2-7]
Regex pattern examples:
xxx must contain 'xxx'
^foo must begin with 'foo'
bar$ must end with 'bar'
b[aoeiu]r must have a vowel between 'b' and 'r'
'^ab|^cd' must begin with 'ab' or 'cd'
[a-z]{16} must contain letters only, no digits
^dusk.*dawn$ must begin with 'dusk' and end with 'dawn'
[a-z2-7]{16} any name - will succeed after one iteration

You can also run the worgenexecutable with no arguments for a complete list of options:

$ ./worgen
Version: 1.2.0

usage: worgen min-max filename1 min1-max1 [filename2 min2-max2 [filename3 min3-max3]]
  min-max   : length limits for the output strings
  filename1 : name of the first word list file (required)
  min1-max1 : length limits for the words from the first file
  filename2 : name of the second word list file (optional)
  min2-max2 : length limits for the words from the first file
  filename3 : name of the third word list file (optional)
  min3-max3 : length limits for the words from the first file

  Example: worgen 8-12 wordlist1.txt 5-10 wordlist2.txt 3-5 > results.txt

              Generates word combinations from 8 to 12 characters long
              using 5-10 character long words from 'wordlist1.txt'
              followed by 3-5 character long words from 'wordlist2.txt'.
              Saves the results to 'results.txt'.

 

Generate A Vanity .onion Address For Your Tor Hidden Service Using Shallot

Ever wonder how Tor sites get those custom vanity .onion addresses such as silkroada7bc3kld.onion? These addresses can be generated by hidden service operators for production use, and are just as secure as the automatically generated (and often more cryptic) addresses.

Hidden service .onion addresses are really just the public part of a key pair. Utilizing asymmetric encryption, a hidden service uses the public key (a 16 character string that functions as the actual address prefix) and a private key (a much longer string that is known only to the hidden service) to verify the identity of the service. Anyone connecting to the public key can only do so if the hidden service has access to the private key. Under normal circumstances, only the service operator has access to that private key, so you could trust that the address has not been hijacked.

Keep in mind, while it takes a long time, it is possible for someone to generate the same keypair as another hidden service. While computationally expensive, entities able to throw enough resources at generating an identical address would be able to do so much more quickly than someone acting alone on a sole machine.

 

Generation with Shallot

Shallot is one tool that can be used for generation. Under the name onionhash, Shallot was first created and maintained by an anonymous developer named Bebop. After Bebop disappeared, development continued with the help of a programmer named `Orum who renamed it Shallot before disappearing himself. Eventually, katmagic moved the code to github where it lives today, but without active development. Over the years, other developers have made fixes, but none of them have been moved into the master branch of the application. Shallot will not be as fast as a tool like Scallion, but it is (in my opinion) more portable as Scallion seems to have issues running on ARM-based SOCs.

Let’s get started generating custom .onion addresses. I will assume that you have access to a Linux machine and are familiar with the terminal.

First, clone Shallot onto your machine:

$ git clone https://github.com/katmagic/Shallot.git

Now, we will move to the Shallot directory, and download and apply some patches:

$ cd Shallot
$ wget https://patch-diff.githubusercontent.com/raw/katmagic/Shallot/pull/9.patch
$ git apply 9.patch
$ wget https://patch-diff.githubusercontent.com/raw/katmagic/Shallot/pull/16.patch
$ git apply 16.patch
$ wget https://patch-diff.githubusercontent.com/raw/katmagic/Shallot/pull/25.patch
$ git apply 25.patch

Wait, what are these for?

  • Patch #9 fixes an off-by-one error that caused generation of incorrect keys.
  • Patch #16 adds an optimization for computing powers of 2 using a bitshift.
  • Patch #25 adds use of memcmp to speed up regular expression use.

Next, we will configure and make to build the shallot executable:

$ ./configure && make

We can now test it by generating an address that starts with “apple” utilizing regular expressions:

$ ./shallot ^apple

After a little waiting, you should get some similar output with the .onion address (public key) and the private key:

$ ./shallot ^apple
-----------------------------------------------------------------
Found matching domain after 9231616 tries: applelmehzgcx37v.onion
-----------------------------------------------------------------
-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQC1szzknIej9Cn32XEarL1TFJXGOWpllK8NDSLKsJfwBIW3kyFb
F996LeIX7wKomRuudZ8TfyCQsdL4XT27MvZTX/HTjYc1TErpw6s+0n1WXm/+sbgD
/8X1vpt/m4OLZS+JOgDSFNM9zi1Qy2GOAMGlyBA5nXKxo5h60vOA87RVowIEARq5
/wKBgBGN/v/RFriNmAd572mI8SiMK5NBO6yu33wz1kf15Xqh/K6QE9Tsr/htYNjr
/RBb7JgIDCXFl0Bsjfnqtsp/WPe5eWUJkzePpzrIyrgAgFneHYYPeKbhUuEwB20i
mFBKXgZmX2yK6BtJDMAjorq/E/hoe9ecKzGaTrv04LTquiIvAkEA43+W3lXBgUIE
EO9ckIHrQ94DvhCtwQGg1vQFLovbvgBL1rqDgmmrWrUrqjqAJXZj8Iou+k+Z9xkK
fn6O4WfMsQJBAMx2ymXmNI8mldwGcl18LvnYGeTCEy0pD6j2yM5LsBNj9G0ZKcFV
n9gAkG5VumCW3yNvGVao7s9B0cjw63n5jJMCQF1ETnd7YOZb20e6GPWxJ1jlXAG7
CapYtn42LBPD9JgNNw8RqKz+zOPu61kWFXMOQnlruLh127218FVsfbvilt8CQFi7
dTZ0DwIPQRwB5QaGe2ymXFSj1yMbDMh9Z/7TXcmdSnigfDfGykQN27qYPwB8CcTM
MfZszZukdmgYFYx+H8cCQDrGHNbtSePX53ATAf2nP6Wqzi438d4Aegev5qOaTLk6
ol+H4euHzOO7R/YmWcXRWSZAwFfmboNb5xMfR54SK+k=
-----END RSA PRIVATE KEY-----

The private key and address usually sit in files within the /var/lib/tor/hidden_service/ directory and are named hostname and private_key respectively.

 

For a full list of options and flags, we can run the shallot executable with no arguments:

$ ./shallot
Usage: shallot [-dmopv] [-f ] [-t count] [-x time] [-e limit] pattern
  -d        : Daemonize (requires -f)
  -m        : Monitor mode (incompatible with -f)
  -o        : Optimize RSA key size to improve SHA-1 hashing speed
  -p        : Print 'pattern' help and exit
  -f  : Write output to 
  -t count  : Forces exactly count threads to be spawned
  -x secs   : Sets a limit on the maximum execution time. Has no effect without -m
  -e limit  : Manually define the limit for e

The repository on Github also has a handy chart to estimate how long it will take to generate an address matching a certain number of characters on a 1.5GHz processor:

characters | time to generate (approx.)
-------------------------------------------------------------------    
1          | less than 1 second    
2          | less than 1 second    
3          | less than 1 second   
4          | 2 seconds    
5          | 1 minute    
6          | 30 minutes    
7          | 1 day    
8          | 25 days  
9          | 2.5 years  
10         | 40 years  
11         | 640 years  
12         | 10 millenia  
13         | 160 millenia  
14         | 2.6 million years
 

Configuring a Tor Hidden Service

Tor hidden services allow various types of services (web server, telnet server, chat server, etc) to be operated within the Tor network. This allows both users and service operators to conceal their identities and locations. Just about anything that can be run on the clearnet can be run within the Tor darknet.

Setting up a hidden service on Tor is a simple process and depending on the level of detail, an operator can keep their service completely anonymous. Depending on your use-case, you may or may not choose to anonymize your service at all. For anonymous operation, it is recommended to bind services being offered to localhost and make sure that they do not leak information such as an IP address or hostname in any situation (such as with error messages).

For this guide, we assume a Debian Stretch (or similar) Linux system with a non-root, sudo user. It is also assumed that the target machine has been set up with some standard security practices such as disallowing root logins over SSH, and basic firewall rules. This Tor hidden service will be masked on the darknet, but if the hosting server is deanonymized, a malicious party could uncover the machine’s actual clearnet IP address and attempt to penetrate it or otherwise disrupt service. Depending on the software running the services you are hiding, you may wish to install into a virtual machine to limit damage to the system by code vulnerabilities.

Installing Tor

Before configuring a relay, the Tor package must be set up on the system. While Debian does have a Tor package in the standard repositories, we will want to add the official Tor repositories and install from there to get the latest software and be able to verify its authenticity.

First, we will edit the sources list so that Debian will know about the official Tor repositories.

$ sudo nano /etc/apt/sources.list

At the bottom of the file, paste the following two lines and save/exit.

deb http://deb.torproject.org/torproject.org stretch main
deb-src http://deb.torproject.org/torproject.org stretch main

Now back in the console, we will add the Tor Project’s GPG key used to sign the Tor packages. This will allow verification that the software we are installing has not been tampered with.

$ gpg --keyserver keys.gnupg.net --recv A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
$ gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -

Lastly, run an update and install Tor from the repositories we just added.

$ apt-get update
$ apt-get install tor deb.torproject.org-keyring

 

Configuring the Hidden Service

We will be editing the torrc file, so let’s bring it up in our text editor:

$ sudo nano /etc/tor/torrc

Going line by line in this file is tedious, so to minimize confusion, we will ultimately rewrite the whole file. We will implement logging into a file located at /var/log/tor/notices.log and assume the local machine has a web server running on port 80. Paste the following over the existing contents in your torrc file:

Log notice file /var/log/tor/notices.log

############### This section is just for location-hidden services ###

## Once you have configured a hidden service, you can look at the
## contents of the file ".../hidden_service/hostname" for the address
## to tell people.
##
## HiddenServicePort x y:z says to redirect requests on port x to the
## address y:z.

HiddenServiceDir /var/lib/tor/hs_name_of_my_service/
HiddenServicePort 80 127.0.0.1:80

#HiddenServiceDir /var/lib/tor/other_hidden_service/
#HiddenServicePort 80 127.0.0.1:80
#HiddenServicePort 22 127.0.0.1:22

After saving the file, make and permission a log file, then we are ready to restart Tor:

$ sudo touch /var/log/tor/notices.log
$ chown debian-tor:debian-tor /var/log/tor/notices.log
$ sudo service tor restart

If the restart was successful, the Tor hidden service is active. If not, be sure to check the log file for hints as to the failure:

$ sudo nano /var/log/tor/notices.log

Now that the hidden service is working, Tor has created the hidden service directory we defined in the torrc, /var/lib/tor/hs_name_of_my_service/. There are two files of importance within this directory.

There is a hostname file at /var/lib/tor/hs_name_of_my_service/hostname that contains the hidden service’s public key. This public key acts as a .onion address which users on the Tor network can use to access your service. Make a note of this address after reading it from the file with cat:

$ sudo cat /var/lib/tor/hs_name_of_my_service/hostname
nb2tidpl4j4jnoxr.onion

There is also a private_key file that contains the hidden service’s private key. This private key pairs with the service’s public key. It should not be known or read by anyone or anything except Tor, otherwise someone else will be able to impersonate the hidden service. If you need to move your Tor hidden service for any reason, make sure to backup the hostname and private_key files before restoring them on a new machine.

After restarting the hidden service, it may not be available right away. It can take a few minutes before the .onion address resolves on a client machine.

 

Example – Configure A Web Server with Nginx

Let’s use this hidden service to host a website with Nginx.

First, we will install Nginx and create a directory for our HTML files

$ sudo apt-get install nginx
$ sudo mkdir -p /var/www/hidden_service/

Now, we will create an HTML file to serve, so we need to bring one up in our editor:

$ sudo nano /var/www/hidden_service/index.html

Paste the following basic HTML and save it:

<html><head><title>Hidden Service</title></head><body><h1>It works!</h1></body></html>

Next, we will set the owner of the files we created to www-data for the web server and change the permissions on the /var/www directory.

$ sudo chown -R www-data:www-data /var/www/hidden_service/
$ sudo chmod -R 755 /var/www

We want to make some configuration changes for anonymity. First, let’s edit the default server block:

$ sudo nano /etc/nginx/sites-available/default

Find the block that starts with server { and you should see a line below that reads #listen 80;. Replace this line with to explicitly listen on localhost:

listen localhost:80 default_server;

Now find the line in the block for server_name  set the server name explicitly:

server_name _;

Next we need to edit the Nginx configuration file:

$ sudo nano /etc/nginx/nginx.conf

Find the block that starts with http { and set the following options:

server_name_in_redirect off;
server_tokens off;
port_in_redirect off;

The first option will make sure the server name isn’t used in any redirects. The second option removes server information in error pages and headers. The third option will make sure the port number Nginx listens on will not be included when generating a redirect.

Now we need to create a server block so Nginx knows which directory to serve content from when our hidden service is accessed. Using our text editor, we will create a new server block file:

$ sudo nano /etc/nginx/sites-available/hidden_service

In the empty file, paste the following configuration block. Make sure that the server_name field contains your onion address which you read from the hostname file earlier and not my address, nb2ticpl4j4hnoxq.onion.

server {
listen   127.0.0.1:80;
server_name nb2tidpl4j4jnoxr.onion;

error_log   /var/log/nginx/hidden_service.error.log;
access_log  off;

location / {
        root /var/www/hidden_service/;
        index index.html;
    }
}

After saving the file, we need to symlink it to the sites-enabled directory and then restart Nginx:

$ sudo ln -s /etc/nginx/sites-available/hidden_service /etc/nginx/sites-enabled/hidden_service
$ sudo service nginx restart

To test the hidden service, download and install the Tor Browser on any machine and load up your .onion address.

 

Example – Configure A Web Server with Apache

Let’s use this hidden service to host a website with Apache. Note: Many criticize Apache for leaking server information by default. Apache takes more effort to secure.

First, we will install Apache and create a directory for our HTML files

$ sudo apt-get install apache2
$ sudo mkdir -p /var/www/hidden_service/

Now, we will create an HTML file to serve, so we need to bring one up in our editor:

$ sudo nano /var/www/hidden_service/index.html

Paste the following basic HTML and save it:

<html><head><title>Hidden Service</title></head><body><h1>It works!</h1></body></html>

Next, we will set the owner of the files we created to www-data for the web server and change the permissions on the /var/www directory.

$ sudo chown -R www-data:www-data /var/www/hidden_service/
$ sudo chmod -R 755 /var/www

Now, we need to make a few changes to the Apache configuration. Let’s start by setting Apache up to only listen to port 80 on 127.0.1.1:

$ sudo nano /etc/apache2/ports.conf

Change the line Listen 80 to Listen 127.0.0.1:80 and save the file.

Now we will access the security configuration file:

$ sudo nano /etc/apache2/conf-enabled/security.conf

Change the line for ServerSignature to ServerSignature Off and the line for ServerTokens to ServerTokens Prod to restrict information the httpd reports about the server.

Then, we will make an edit to the main Apache configuration file to override the server name Apache uses:

$ sudo nano /etc/apache2/apache2.conf

At the very bottom of the file, paste the following. Make sure that the ServerName field contains your onion address which you read from the hostname file earlier and not my address, nb2tidpl4j4jnoxr.onion.

ServerName nb2tidpl4j4jnoxr.onion

Next, we will disable Apache’s mod_status module to turn off status information:

$ sudo a2dismod status

Now we need to create a virtual host so Nginx knows which directory to serve content from when our hidden service is accessed. Using our text editor, we will create a new server block file:

$ sudo nano /etc/apache2/sites-available/hidden_service

In the empty file, paste the following configuration block. Make sure that the server_name field contains your onion address which you read from the hostname file earlier and not my address, nb2tidpl4j4jnoxr.onion.

<VirtualHost *:80>

 ServerName  nb2ticpl4j4hnoxq.onion

 DirectoryIndex index.html
 DocumentRoot /var/www/hidden_service/

  CustomLog /dev/null common

</VirtualHost>

After saving the file, we need to symlink it to the sites-enabled directory and then restart Nginx:

$ sudo ln -s /etc/apache2/sites-available/hidden_service /etc/apache2/sites-enabled/hidden_service
$ sudo service apache2 restart

To test the hidden service, download and install the Tor Browser on any machine and load up your .onion address.

 

Conclusion

Your hidden service should be up and running, ready to server Tor users. Now that your relay is functioning, it may be a good idea to back up your hostname and private_key files mentioned earlier in the /var/lib/tor/hs_name_of_my_service/ directory.

I would strongly recommend taking a look at riseup.net’s Tor Hidden Services Best Practices guide to learn more about proper setup of your hidden service.

Additionally, subscribe to the tor-onions mailing list for operator news and support!

Sources

 

Configuring and Monitoring a Tor Middle Relay

The Tor network relies upon individuals and organizations to donate relays for user traffic. The more relays within network, the stronger and faster the network is. Below, we will create a middle relay which receives traffic and sends it off to another relay. Middle relays will never serve as exit points for traffic back out to the clear Internet (a job for an exit relay). Because of this, many see running a middle relay as a safer way of contributing to the Tor network as opposed to running an exit relay which could find an operator at fault if illegal activity or content exits his node.

For this guide, we assume a Debian Stretch (or similar) Linux system with a non-root, sudo user. It is also assumed that the target machine has been set up with some standard security practices such as disallowing root logins over SSH, and basic firewall rules. This Tor relay will be public, and should be secured like any public-facing server.

 

Installing Tor

Before configuring a relay, the Tor package must be set up on the system. While Debian does have a Tor package in the standard repositories, we will want to add the official Tor repositories and install from there to get the latest software and be able to verify its authenticity.

First, we will edit the sources list so that Debian will know about the official Tor repositories.

$ sudo nano /etc/apt/sources.list

At the bottom of the file, paste the following two lines and save/exit.

deb http://deb.torproject.org/torproject.org stretch main
deb-src http://deb.torproject.org/torproject.org stretch main

Now back in the console, we will add the Tor Project’s GPG key used to sign the Tor packages. This will allow verification that the software we are installing has not been tampered with.

$ gpg --keyserver keys.gnupg.net --recv A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
$ gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -

Lastly, run an update and install Tor from the repositories we just added.

$ apt-get update
$ apt-get install tor deb.torproject.org-keyring

 

Keeping Time

It is important that a Tor relay keeps accurate time, so we will change the timezone and set up the ntp client.

First, list timezones to and find which one corresponds to the location of the machine:

$ timedatectl list-timezones

Next, we set the timezone to the one for the machine’s location. Amsterdam is used below as an example.

$ sudo timedatectl set-timezone Europe/Amsterdam

Finally, install ntp:

$sudo apt-get install ntp

You can check your changes using the timedatectl command with no options:

$ timedatectl
      Local time: Sat 2017-12-30 21:49:25 CET
  Universal time: Sat 2017-12-30 20:49:25 UTC
        RTC time: Sat 2017-12-30 20:49:25
       Time zone: Europe/Amsterdam (CET, +0100)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: no
 Last DST change: DST ended at
                  Sun 2017-10-29 02:59:59 CEST
                  Sun 2017-10-29 02:00:00 CET
 Next DST change: DST begins (the clock jumps one hour forward) at
                  Sun 2018-03-25 01:59:59 CET
                  Sun 2018-03-25 03:00:00 CEST

 

Configuring the Relay

By default, all new relays are set up to be exit nodes. Since we want to create a middle relay, there is some configuration that needs to be done.

We will be editing the torrc file, so let’s bring it up in our text editor:

$ sudo nano /etc/tor/torrc

Going line by line in this file is tedious, and to minimize confusion, I will outline some configuration outlines and paste a sample torrc file below that you can use with minimal changes.

  • We don’t need a SOCKS proxy, so uncomment the line SOCKSPolicy reject *
  • We want to keep a separate log file, so uncomment the line Log notice file /var/log/tor/notices.log
  • We will be running as a daemon, so uncomment the line RunAsDaemon 1
  • We will be running monitoring via ARM, so uncomment the line ControlPort 9051
  • Relays need an ORPort for incoming connections, so uncomment the line ORPort 9001
  • It is recommended that a relay has an FQDN or at least a subdomain of one. If not, the machine’s IP address can be used. We will unncomment the line Address noname.example.com and use our address in place of noname.example.com
  • The relay should also have a nickname, so uncomment the line Nickname ididnteditheconfig and use our own nickname in place of ididnteditheconfig
  • Contact information should also be provided, so uncomment the line #ContactInfo Random Person and use our own info in place of Random Person
  • We will be running a directory port, so uncomment the line DirPort 9030
  • The most important option, we don’t want to allow any exits, so uncomment the line ExitPolicy reject *:*
  • Optionally, we may want to limit the bandwidth that Tor uses. To do so, uncomment the lines RelayBandwidthRate 100 KBytes and RelayBandwidthBurst 200 KBytes. These values are defined for one way transport, so note that the actual bandwidth rate above could be 200KB/s total (100KB/s for each input and output). Burst defines a maximum rate, so a burst of 200 KBytes means bandwidth could reach 400KB/s total (combined input and output). Many will likely want their relay to be considered Fast by the network, meaning that the relay’s bandwidth is in the top 7/8ths of all relays. At the time of writing, a rate of 500 KBytes/s seems to be on the low end of achieving this according to a Tor team member.
  • Optionally, we may want to limit the total traffic Tor uses over a period. To do so, uncomment the lines AccountingMax 40 GBytes and AccountingStart month 3 15:00. The AccountingMax value is defined for one way transport, so note that setting 40 GBytes could use 80 GBytes total (40 GBytes for each input and output). If the machine is on a provider that limits monthly bandwidth, it is a good idea to adjust this value to align with the provider’s data cap and adjust the AccountingStart values to reset to reset when the data cap does. NOTE: If you do set accounting, the relay will not advertise a directory port and you will not get directory connections. Relays with directories are expected to have a lot of bandwidth and limiting it will result in other nodes not making directory connections.

Now, here is a full sample torrc file for the tor middle relay:

## Configuration file for a typical Tor user

## Tor opens a SOCKS proxy on port 9050 by default -- even if you don't
## configure one below. Set "SOCKSPort 0" if you plan to run Tor only
## as a relay, and not make any local application connections yourself.
#SOCKSPort 9050 # Default: Bind to localhost:9050 for local connections.
#SOCKSPort 192.168.0.1:9100 # Bind to this address:port too.

## Entry policies to allow/deny SOCKS requests based on IP address.
## First entry that matches wins. If no SOCKSPolicy is set, we accept
## all (and only) requests that reach a SOCKSPort. Untrusted users who
## can access your SOCKSPort may be able to learn about the connections
## you make.
#SOCKSPolicy accept 192.168.0.0/16
#SOCKSPolicy accept6 FC00::/7
SOCKSPolicy reject *

## Logs go to stdout at level "notice" unless redirected by something
## else, like one of the below lines. You can have as many Log lines as
## you want.
##
## We advise using "notice" in most cases, since anything more verbose
## may provide sensitive information to an attacker who obtains the logs.
##
## Send all messages of level 'notice' or higher to /var/log/tor/notices.log
Log notice file /var/log/tor/notices.log
## Send every possible message to /var/log/tor/debug.log
#Log debug file /var/log/tor/debug.log
## Use the system log instead of Tor's logfiles
#Log notice syslog
## To send all messages to stderr:
#Log debug stderr

## Uncomment this to start the process in the background... or use
## --runasdaemon 1 on the command line. This is ignored on Windows;
## see the FAQ entry if you want Tor to run as an NT service.
RunAsDaemon 1

## The directory for keeping all the keys/etc. By default, we store
## things in $HOME/.tor on Unix, and in Application Data\tor on Windows.
#DataDirectory /var/lib/tor

## The port on which Tor will listen for local connections from Tor
## controller applications, as documented in control-spec.txt.
ControlPort 9051
## If you enable the controlport, be sure to enable one of these
## authentication methods, to prevent attackers from accessing it.
#HashedControlPassword 16:872860B76453A77D60CA2BB8C1A7042072093276A3D701AD684053EC4C
#CookieAuthentication 1

############### This section is just for location-hidden services ###

## Once you have configured a hidden service, you can look at the
## contents of the file ".../hidden_service/hostname" for the address
## to tell people.
##
## HiddenServicePort x y:z says to redirect requests on port x to the
## address y:z.

#HiddenServiceDir /var/lib/tor/hidden_service/
#HiddenServicePort 80 127.0.0.1:80

#HiddenServiceDir /var/lib/tor/other_hidden_service/
#HiddenServicePort 80 127.0.0.1:80
#HiddenServicePort 22 127.0.0.1:22

################ This section is just for relays #####################
#
## See https://www.torproject.org/docs/tor-doc-relay for details.

## Required: what port to advertise for incoming Tor connections.
ORPort 9001
## If you want to listen on a port other than the one advertised in
## ORPort (e.g. to advertise 443 but bind to 9090), you can do it as
## follows.  You'll need to do ipchains or other port forwarding
## yourself to make this work.
#ORPort 443 NoListen
#ORPort 127.0.0.1:9090 NoAdvertise

## The IP address or full DNS name for incoming connections to your
## relay. Leave commented out and Tor will guess.
Address tor.peer3.famicoman.com

## If you have multiple network interfaces, you can specify one for
## outgoing traffic to use.
# OutboundBindAddress 10.0.0.5

## A handle for your relay, so people don't have to refer to it by key.
Nickname peer3famicoman

## Define these to limit how much relayed traffic you will allow. Your
## own traffic is still unthrottled. Note that RelayBandwidthRate must
## be at least 20 kilobytes per second.
## Note that units for these config options are bytes (per second), not
## bits (per second), and that prefixes are binary prefixes, i.e. 2^10,
## 2^20, etc.
RelayBandwidthRate 2048 KBytes  # Throttle traffic to 2048KB/s (16384Kbps)
RelayBandwidthBurst 3072 KBytes # But allow bursts up to 3072KB/s (24576Kbps)

## Use these to restrict the maximum traffic per day, week, or month.
## Note that this threshold applies separately to sent and received bytes,
## not to their sum: setting "40 GB" may allow up to 80 GB total before
## hibernating.
##
## Set a maximum of 40 gigabytes each way per period.
#AccountingMax 400 GBytes
## Each period starts daily at midnight (AccountingMax is per day)
#AccountingStart day 00:00
## Each period starts on the 3rd of the month at 15:00 (AccountingMax
## is per month)
AccountingStart month 24 15:00

## Administrative contact information for this relay or bridge. This line
## can be used to contact you if your relay or bridge is misconfigured or
## something else goes wrong. Note that we archive and publish all
## descriptors containing these lines and that Google indexes them, so
## spammers might also collect them. You may want to obscure the fact that
## it's an email address and/or generate a new address for this purpose.
#ContactInfo Random Person 
## You might also include your PGP or GPG fingerprint if you have one:
#ContactInfo 0xFFFFFFFF Random Person 
ContactInfo famicoman[at]gmail[dot]com - 1DVLNHpcoAso6rvisCnVQbCFN8dRir1GVQ

## Uncomment this to mirror directory information for others. Please do
## if you have enough bandwidth.
DirPort 9030 # what port to advertise for directory connections
## If you want to listen on a port other than the one advertised in
## DirPort (e.g. to advertise 80 but bind to 9091), you can do it as
## follows.  below too. You'll need to do ipchains or other port
## forwarding yourself to make this work.
#DirPort 80 NoListen
#DirPort 127.0.0.1:9091 NoAdvertise
## Uncomment to return an arbitrary blob of html on your DirPort. Now you
## can explain what Tor is if anybody wonders why your IP address is
## contacting them. See contrib/tor-exit-notice.html in Tor's source
## distribution for a sample.
#DirPortFrontPage /etc/tor/tor-exit-notice.html

## Uncomment this if you run more than one Tor relay, and add the identity
## key fingerprint of each Tor relay you control, even if they're on
## different networks. You declare it here so Tor clients can avoid
## using more than one of your relays in a single circuit. See
## https://www.torproject.org/docs/faq#MultipleRelays
## However, you should never include a bridge's fingerprint here, as it would
## break its concealability and potentially reveal its IP/TCP address.
#MyFamily $keyid,$keyid,...

## A comma-separated list of exit policies. They're considered first
## to last, and the first match wins.
##
## If you want to allow the same ports on IPv4 and IPv6, write your rules
## using accept/reject *. If you want to allow different ports on IPv4 and
## IPv6, write your IPv6 rules using accept6/reject6 *6, and your IPv4 rules
## using accept/reject *4.
##
## If you want to _replace_ the default exit policy, end this with either a
## reject *:* or an accept *:*. Otherwise, you're _augmenting_ (prepending to)
## the default exit policy. Leave commented to just use the default, which is
## described in the man page or at
## https://www.torproject.org/documentation.html
##
## Look at https://www.torproject.org/faq-abuse.html#TypicalAbuses
## for issues you might encounter if you use the default exit policy.
##
## If certain IPs and ports are blocked externally, e.g. by your firewall,
## you should update your exit policy to reflect this -- otherwise Tor
## users will be told that those destinations are down.
##
## For security, by default Tor rejects connections to private (local)
## networks, including to the configured primary public IPv4 and IPv6 addresses,
## and any public IPv4 and IPv6 addresses on any interface on the relay.
## See the man page entry for ExitPolicyRejectPrivate if you want to allow
## "exit enclaving".
##
#ExitPolicy accept *:6660-6667,reject *:* # allow irc ports on IPv4 and IPv6 but no more
#ExitPolicy accept *:119 # accept nntp ports on IPv4 and IPv6 as well as default exit policy
#ExitPolicy accept *4:119 # accept nntp ports on IPv4 only as well as default exit policy
#ExitPolicy accept6 *6:119 # accept nntp ports on IPv6 only as well as default exit policy
ExitPolicy reject *:* # no exits allowed

## Bridge relays (or "bridges") are Tor relays that aren't listed in the
## main directory. Since there is no complete public list of them, even an
## ISP that filters connections to all the known Tor relays probably
## won't be able to block all the bridges. Also, websites won't treat you
## differently because they won't know you're running Tor. If you can
## be a real relay, please do; but if not, be a bridge!
#BridgeRelay 1
## By default, Tor will advertise your bridge to users through various
## mechanisms like https://bridges.torproject.org/. If you want to run
## a private bridge, for example because you'll give out your bridge
## address manually to your friends, uncomment this line:
#PublishServerDescriptor 0

After saving the file, we are ready to restart Tor:

$ sudo service tor restart

Now, we need to make sure everything worked properly and that the relay is functioning as expected. To do so, we will check the logs:

$ sudo nano /var/log/tor/log

If everything worked as expected, the following lines should appear near the bottom of the log file:

[notice] Self-testing indicates your ORPort is reachable from the outside. Excellent.
[notice] Tor has successfully opened a circuit. Looks like client functionality is working.
[notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Publishing server descriptor.

If you see anything different, make sure your torrc file is configured properly and that your firewall is set to allow connections to the ports you set for the ORPort and DirPort (by default, 9001 and 9030 respectively).

 

Monitoring Your Relay with Nyx

To monitor Tor relays, many people use a popular tool called Nyx which provides graphical information about activity and status of the node. Nyx utilizes the ControlPort we set earlier to connect into our relay. This port shot not need to be accepted by a firewall if Nyx will be running on the same machine and should be password-protected otherwise.

First, Nyx needs to be installed:

$ sudo apt-get install python-setuptools
$ sudo easy_install pip
$ sudo pip install nyx

Then,Nyx can be run:

$ nyx

The result is a nice representation of the relay’s traffic, utilization, flags, and general information.

 

Monitoring Your Relay with ARM (Deprecated)

While ARM is no longer maintained, it does still function.

To monitor Tor relays, many people use a popular tool called ARM which provides graphical information about activity and status of the node. ARM utilizes the ControlPort we set earlier to connect into our relay. This port shot not need to be accepted by a firewall if ARM will be running on the same machine and should be password-protected otherwise.

First, ARM needs to be installed:

sudo apt-get install tor-arm

Then, ARM can be run:

arm

The result is a nice representation of the relay’s traffic, utilization, flags, and general information.

 

Conclusion

While my relay picked up traffic quickly, it took a long time to be able to fully utilize the bandwidth rates that I gave it. A new Tor middle relay goes through many stages before it can be deemed stable and reliable by the network. I highly recommend reading The lifecycle of a new relay to understand the whole process and know why you may not see traffic right away.

You may notice in my screenshots of Nyx and ARM above, my relay has procured several flags. If you are trying to obtain certain flags for your relay (which sort of act like markers of the relay’s capabilities), I recommend reading this StackExchange post on the subject.

If you want to see some statistics for your relay or share them with others, consider checking out the Atlas and Globe projects. This provides information on a relay by fingerprint of that relay, though you can perform searches with the relay’s nickname. Check out my relay on Atlas and my relay on Globe for examples.

Now that your relay is functioning, you may wish to backup your torrc, backup your relay’s private key (/var/lib/tor/keys/secret_id_key), read and implement operational security practices, and join the tor-relays mailing list.

 

Sources

 

I2P 101 – Inside the Invisible Internet

This article was originally written for and published at N-O-D-E on May 1st, 2016. It has been posted here for safe keeping.

I2P 101 – INSIDE THE INVISIBLE INTERNET

The Invisible Internet Project (more commonly known as I2P) is an older, traditional darknet built from the ground up with privacy and security in mind. As with all darknets, accessing an I2P site or service is not as simple as firing a request off from your web browser as you would with any site on the traditional Internet (the clearnet). I2P is only accessible if you are running software built to access it. If you try to access an I2P service without doing your homework, you won’t be able to get anywhere. Instead of creating all new physical networking infrastructure, I2P builds upon the existing Internet to take care of physical connections between machines, creating what is known as an overlay network. This is similar to the concept of a virtual private network (VPN) wherein computers can communicate with one another comfortably, as though they were on a local area network, even though they may be thousands of miles apart.

2nzxPzu

INTRODUCTION

I2P was first released in early 2003 (only a few months after the initial release of Tor), and was designed as a communication layer for existing Internet services such as HTTP, IRC, email, etc. Unlike the clearnet, I2P focuses on anonymity and peer-to-peer communications, relying on a distributed architecture model. Unlike Tor which is based around navigating the clearnet through the Tor network, I2P’s goal from the start was to create a destination network and was developed as such. Here, we see that the focus is on community and anonymity within it as opposed to anonymity when using the clearnet.

ROUTERS, INPROXIES & OUTPROXIES

When you connect to I2P, you are automatically set up to be a router. If you are a router, you exist as a node on the network and participate in directing or relaying the flow of data. As long as you are on the network, you are always playing a part in keeping the traffic flowing. Other users may choose to configure their nodes as inproxies. Think of an inproxy as a way to get to an I2P service from the clearnet. For example, if you wanted to visit an eepsite (An anonymous site hosted on I2P, designated by a .i2p TLD) but we’re not on I2P, you could visit an inproxy through the clearnet to provide you access. Other users may choose to operate outproxies. An outproxy is essentially an exit node. If you are on I2P and want to visit a clearnet site or service, your traffic is routed through an outproxy to get out of the network.

ADVANTAGES

There are numerous advantages to using I2P over another darknet such as Tor depending upon the needs of the user. With I2P, we see a strong focus on the anonymity of connections as all I2P tunnels are unidirectional. This means that separate lines of communication are opened for sending and receiving data. Further, tunnels are short-lived, decreasing the amount of information an attacker or eavesdropper could have access to. We also see differences in routing as I2P uses packet switching as opposed to circuit switching. In packet switching routing, messages are load balanced among multiple peers to get to the destination instead of a single route typical of circuit switching. In this scenario, I2P sees all peers participating in routing. I2P also implements distributed dissemination of network information. Peer information is dynamically and automatically shared across nodes instead of living on a centralized server. Additionally, we also see low overhead for running a router because every node is a router instead of a low percentage of those who choose to set one up.

GARLIC ROUTING

I2P implements garlic routing as opposed to the more well known onion routing. Both garlic routing and onion routing rely on the technique of layered encryption. On the network, traffic flows through a series of peers on the way to its final destination. Messages are encrypted multiple times by the originator using the peers’ public keys. When the message is sent out on the path and decrypted by the proper corresponding peer in the sequence, only enough information to pass the message to the next node is exposed until the message reaches its destination where the original message and routing instructions are revealed. The initial encrypted message is layered and resembles an onion that has its layers peeled back on transit.

Garlic routing extends this concept by grouping messages together. Multiple messages referred to as “bulbs” are bound together, each with its own routing instructions. This bundle is then layered just like with onion routing and sent off to peers on the way to the destination. There is no set size for how many messages are included in one bundle, providing another level of complexity in message delivery.

INSIDE THE NETWORK

Hundreds of sites and services exist for use within the I2P network, completely operated by the community. For example, Irc2P is the premier IRC network for chat. We see search engines like eepSites & Epsilon, and torrent trackers like PaTracker. Social networks like Id3nt (for microblogging) and Visibility (for publishing) are also abundant. If you can think of a service that can run on the network, it may already be operational.

FUTURE

I2P remains in active development with many releases per year and continues to be popular within its community. While I2P is not as popular as other darknets such as Tor, it remains to be a staple of alternative networks and is often praised for its innovative concepts.Though I2P does not focus on anonymous use of the clearnet, it is seeing active use for both peer-to-peer communication and file-sharing services.

CONCLUSION

While many may view I2P as just another darknet, it has many interesting features that aren’t readily available or implemented on other networks. Due to the community and regular updates, there is no reason to think that I2P will be going anywhere anytime soon and will only continue to grow with more awareness and support.

Over time, more and more people have embraced alternative networks and we are bound to see more usage on the horizon. However one of the points I2P maintainers express is that the network’s small size and limited adoption may be helpful at this point in time. I2P is not as prominent in the public’s field of view, possibly protecting it from negative publicity and potential attackers.

Whether or not I2P will keep hold of its core community or expand and change with time is unknown, but for now it proves to be a unique darknet implementation with a lot of activity.

SOURCES

https://geti2p.net/en/comparison/tor
https://www.ivpn.net/privacy-guides/an-introduction-to-tor-vs-i2p
https://geti2p.net/en/about/intro
https://geti2p.net/en/docs/how/garlic-routing

––
BY MIKE DANK (@FAMICOMAN)

 

Hyperboria 101 – Moving Through The Mesh

This article was originally written for and published at N-O-D-E on February 14th, 2016. It has been posted here for safe keeping.

HYPERBORIA 101 – MOVING THROUGH THE MESH

Hyperboria is a network built as an alternative to the traditional Internet. In simple terms, Hyperboria can be thought of as a darknet, meaning it is running on top of or hidden from the existing Internet (the clearnet). If you have ever used TOR or I2P, it is a similar concept. Unlike the Internet, with thousands of servers you may interact with on a day-to-day basis, access to Hyperboria is restricted in the sense that you need specific software, as well as someone already on the network, to access it. After configuring the client, you connect into the network, providing you with access to each node therein.

WF8CEM9

INTRODUCTION

Hyperboria isn’t just any alternative network, it’s decentralized. There is no central point of authority, no financial barrier of entry, and no government regulations. Instead, there is a meshnet; peer-to-peer connection with user controlled nodes and connected links. Commonly, mesh networks are seen in wireless communication. Access points are configured to link directly with other access points, creating multiple connections to support the longevity of the network infrastructure and the traffic traveling over it. More connections between nodes within the network is better than less here. With this topology, all nodes are treated equally. This allows networks to be set up inexpensively without the infrastructure needed to run a typical ISP, which usually has user traffic traveling up several gateways or routers owned by other companies.

But what is the goal of the Hyperboria network? With roots in Reddit’s /r/darknetplan, we see that the existing Internet has issues with censorship, government control, anonymity, security, and accessibility. /r/darknetplan has a lofty goal of creating a decentralized alternative to the Internet as we know it through a scalable stack of commodity hardware and open source software. This shifts the infrastructure away from physical devices owned by internet service providers, and instead puts hardware in the hands of the individual. This in itself is a large undertaking, especially considering the physical distance between those interested in joining the network, and the complexities of linking them together.

While the ultimate idea is a worldwide wireless mesh connecting everyone, it won’t happen overnight. In the meantime, physical infrastructure can be put in place by linking peers together over the existing Internet through an overlay network. In time with more participation, wireless coverage between peers will improve to the point where more traffic can flow over direct peer-to-peer wireless connections.

ADVANTAGES

The Hyperboria network relies upon a piece of software called cjdns to connect nodes and route traffic. Cjdns’ project page boasts that it implements “an encrypted IPv6 network using public-key cryptography for address allocation and a distributed hash table for routing.” Essentially, the application will create a tunnel interface on a host computer that acts as any other network interface (like an ethernet or wifi adapter). This is powerful in the way that is allows any existing services you might want to face a network (HTTP server, BitTorrent tracker, etc.) to run as long as that service is already compatible with IPv6. Additionally, cjdns is what is known as a layer 3 protocol, and is agnostic towards how the host connects to peers. It doesn’t matter much if the peer we need to connect to is over the internet or a physical access point across the street.

All traffic over Hyperboria is encrypted end-to-end, stopping eavesdroppers operating rogue nodes. Every node on the network receives a unique IPv6 address, which is derived from that node’s public key after the public/private keypair is generated. This eliminates the need for additional encryption configuration and creates an environment with enough IP addresses for substantial network expansion. As the network grows in size, the quality of routing also improves. With more active nodes, the number of potential routes increases to both mitigate failure and optimize the quickest path from sender to receiver.

Additionally, there are no authorities such as the Internet Assigned Numbers Authority (IANA) who on the Internet control features like address allocation and top level domains. Censorship can easily be diminished. Suppose someone is operating a node hosting content that neighboring nodes find offensive, so they refuse to provide access. As long as that node operator can find at least one person somewhere on the network to peer with, he can continue making his content accessible to the whole network.

PEERING

One of the main differences between Hyperboria and networks like TOR is how connection to the network is made. Out of the box, running the cjdns client alone will not provide access to anything.

To be able to connect to the network, everyone must find someone to peer with; someone already on Hyperboria. This peer provides the new user with clearnet credentials for his node (an ip address, port number, key, and password) and the new user enters them into his configuration file. If all goes to plan, restarting the client will result in successful connection to the peer, providing the user access to the network.

However, having just one connection to Hyperboria doesn’t create a strong link. Consider what would happen if this node was experiencing an outage or was taken offline completely. The user and anyone connecting to him as an uplink into the network would lose access. Because of this, users are encouraged to find multiple peers near them to connect to.

In theory, everyone on the network should be running their node perpetually. If a user only launched cjdns occasionally, other nodes on the network will not be able to take advantage of routing through the user’s node as needed.

With the peering system, there is no central repository of node information. Nobody has to know anyone’s true identity, or see who is behind a particular node. All of the connections are made through user-to-user trust when establishing a new link. If for any reason a node operator were to become abusive to other nodes on the network, there is nothing stopping neighboring nodes from invalidating the credentials of the abuser, essentially kicking them off of the network. If any potential new node operator seemed malicious, other operators have the right to turn him away.

MESHLOCALS

The most important aspect of growing the Hyperboria network is to build meshlocals in geographically close communities. Consider how people would join Hyperboria without knowing about their local peers. Maybe someone in New York City would connect to someone in Germany, or someone in San Franscisco to someone in Philadelphia. This creates suboptimal linking as the two nodes in each example are geographically distant from each other.

The concept of a meshlocal hopes to combat this problem. Users physically close together are encouraged to form working groups and link their nodes together. Additionally, these users work together to seek new node operators with local outreach to grow the network. Further, meshlocals themselves can coordinate with one another to link together, strengthening regional areas.

Meshlocals can also offer more in-person communication, making it easier to configure wireless infrastructure between local nodes, or organize actions via a meetup. Many meshlocals have gone on to gain active followings in their regions, for example NYC Mesh and Seattle Meshnet.

INSIDE THE NETWORK

After connecting to Hyperboria, a user may be at a loss as to what he is able to do. All of these nodes are connected and working together, but what services are offered by the Hyperboria community, for the Hyperboria community? Unlike the traditional Internet, most services on Hyperboria are run non-commercially as a hobby.

For example, Hyperboria hosts Uppit: a Reddit clone, Social Node: a Twitter-like site,and HypeIRC: an IRC network. Some of these services may additionally be available on the clearnet, making access easy for those without a connection to Hyperboria. Others are Hyperboria-only, made specifically and only for the network.

As the network grows, more services are added while some fade away in favor of new ones or disrepair. This is all community coordinated after all; there is nothing to keep a node operator from revoking access to his node on a whim for any reason.

FUTURE

As previously mentioned, the ultimate goal of Hyperboria is to offer a replacement for the traditional Internet, built by the users. As it stands now, Hyperboria has established a core following and will see more widespread adoption as meshlocals continue to grow and support users.

Additionally, we see new strides in the development of cjdns with each passing year. As time has gone on, setup and configuration have becomes simpler for the end-user while compatibility has also improved. The more robust the software becomes, the easier it will be to run and keep running.

We also see the maturation of other related technologies. Wireless routers are becoming more inexpensive with more memory and processing power, suitable for running cjdns directly. We also see the rise of inexpensive, small form factor microcomputers like the Raspberry Pi and Beaglebone Black, allowing anyone to buy a functional, dedicated computer for the price of a small household appliance like an iron or coffee maker. Layer 2 technologies like B.A.T.M.A.N. Advanced are also growing, making easily-configurable wireless mesh networks simple to set up and work cooperatively with the layer 3 cjdns.

CONCLUSION

Hyperboria is an interesting exercise in mesh networking with an important end goal and exciting construction appealing to network professionals, computer hobbyists, digital activists, and developers alike.

It’ll be interesting to see how Hyperboria grows over the next few years, and if it is indeed able to offer a robust Internet-alternative for all. Until then, we ourselves can get our hands dirty setting up hardware, developing software, and helping others do the same. With any luck, we will be able to watch it grow. One node at a time.

SOURCES

https://github.com/cjdelisle/cjdns
https://docs.meshwith.me
https://www.reddit.com/r/darknetplan/comments/1vq87d/project_meshnet_for_everyone_a_complete/
https://www.reddit.com/r/dorknet/comments/xry23/this_is_my_first_time_hearing_about_darknet_i/

––
BY MIKE DANK (@FAMICOMAN)

 

Documentaries I’d Like to See Before I Die (Or Everyone Forgets)

I’d like to think that I have something of a second nature when it comes to whether or not there is a documentary made or in production for any of my disjointed hobbies and interests. It’s not one of those skills you showcase in your job interview, but I seem to have this knack for religiously crawling the web in search for films I think I’d enjoy. Surprisingly, and to my great pleasure, a lot of these fringe interests I posses already have films about them. Awesome. However, there are a few that simply do not- or, have a film that doesn’t satiate my particular appetite.

So, for my sanity, I made a list of the topics I’d personally like to see filmed. And, in some cases, some topics I’d probably find gratification in filming myself.

Written below is that very list. Think of this more as a way of me getting the thoughts from my head to paper as opposed to a list of full-bodied explanations and fleshed-out ideas.

Demoscene. There are already a few demoscene documentaties out there. For example, The Demoscene Documentary is about the demoscene in Finland and Moleman 2 is a demoscene documentary focusing mainly on Hungary. While these are in fact good films, they each have a specific scope. From what I gather, the demoscene can be radically different from country to country, making it difficult to understand as a whole when only presented with a few of its parts. I’d propose an episodic piece showcasing the demoscene in a variety of countries – each country having its own segment. While these existing documentaries have touched on Finland and Hungary, there are still Germany, USA, Denmark, and Norway to consider (and probably others).

Bitcoin & Digital Currency. We’ve all heard of Bitcoin by now, especially as it makes waves at it’s current high value. However, Bitcoin itself has an interesting past and makes an interesting statement. If you do any detective work about how Bitcoin came to be, you will be sucked up into a mysterious story about how nobody knows the identity of the creator or what happened to him. The conspiracy theories are vast and plenty. We also touch on the interesting issue of an unregulated worldwide currency, governments attempting regulation, bitcoin-mining malware botnets, attacks on exchanges, etc. How about how crazy some people go with their mining setups? Dozens of caseless computers fillied with graphics cards- a cyberpunk daydream turned reality. How about using FPGAs and these new ASIC rigs? Now, that’s just bitcoin. There are numerous other digital currencies out there such as the newer litecoin, or even e-gold (Created in 1996). Digital currency has been around longer than most people think.

Cypherpunk. The cypherpunk movement does for cryptograhy what the cyberpunk scene did for personal computing. While cypherpunks have been around for decades, the interest within the scene has been renewed and pushed towards the mainstream more recently. Going back to “A Cypherpunk Manifesto” and the cypherpunk mailing list, we see early discussions of online privacy and censorship, paving the way for Bitcoin, Wikileaks, CryptoParty, Tor, 3D-printing of weaponry, etc.

Usenet. Started in 1980, Usenet is a system for users to read and post messages. Usenet can be seen as the precursor to internet forums, and is much like a Bulletin Board System in theory except it is distributed among many servers instead of a central authority. As time goes on, Usenet continues to grow in bandwidth usage, now generating terabytes of traffic a day. This is mostly through binary file transfers as opposed to messages. Despite many main ISPs deciding to remove Usenet access from their internet services, many still seek out paid access.

Pirate Radio UK. While Pirate Radio USA and Making Waves do a fantastic job at covering pirate Radio in the US, I haven’t seen much of an effort to show off pirate radio in the UK. From what I’ve gathered, there are an uncountable number of pirate radio stations across the pond, and it’s a different game when compared to the US. At the peak of pirate radio’s popularity, there were near 600 stations active in the UK while there are presently 150, mostly based in London. Here’s a mini piece from Vice.

Darknet. Not in regards to file sharing. More covering the darknet as a blanket term for an independant or ad-hoc network with some sort of disconnection from the internet. Considering topics like Hyperboria and CJDNS, Tor and the Deep Web, Meshneting for fun or necesity, Tin-Can, and so-on. As the hardware becomes less expensive and more devices have networking abilities, creating a scalable network becomes a more achievable task.

Dyson. I feel that James Dyson doesn’t get as much credit as a revolutionary engineer as he deserves. Dyson focuses on improvement: taking the wheel and making it better. No pun intended, but his first success was the creation of a fiberglass wheelbarrow that used a ball instead of a wheel. Afterwards, he famously created over 1000 prototypes for a new vaccuum cleaner using cyclone technology after noticing problems with his Hoover. Dyson repeatedly uses creative thinking and pulls inspiration from unlikely sources.

Raspberry Pi. While the Raspberry Pi was not necessarilly a unique and new concept, it was certainly one of the most well executed. We have seen other incarnations of plug computers such as the Beagleboard or the Sheevaplug, but the Raspberry Pi’s addition of integrated video sets it apart. And, at the price of $30, makes it incredibly affordable. Many would argue that what makes the Pi so special is the community that has formed around it, and not necessarily the hardware that ties it together. Everyone stretches their imagination and expertise: if it can be on the Pi, it should. Aside from the community, the Raspberry Pi Foundation has been done an incredible job at cultivating the technology and inspiring the next generation of young programmers and hardware hackers.

Kickstarter. There have been documentaries in the works that focus on crowdfunding, but I’m not as interested in the crowdfunding movement as much as I am in Kickstarter the company. While Indie GoGo has been around for a longer time, they do not seem to be held together as tightly. Kickstarter seems like not only an interesting company, but one that holds itself, and those who utilize its services, to a high standard.

QUBE. Here’s an odd one for that likely nobody has heard of. QUBE was the first interactive TV station, started in 1977 in Columbus, Ohio. Residents who subscribed to the cable service received a device that looked something like a calculator that allowed them to communicate back to the station during shows. Aside from the interactive feature, QUBE was on the forefront of pay-per-view programming and special interest content. QUBE soon went bankrupt and dissolved in the early 1980s. As a bit of an aside, I think I actually tried contacting the webmaster of that site a while back to ask if I could get a copy of the “QUBE DVD” for archiving but didn’t get a reply. Let’s hope he/she runs Webalizer or Google Analytics and sees some referrer traffic. Maybe it’ll be enough to spark a conversation.

So here ends my list. While the majority of these ideas are feasible, I can’t help but think a few might end up slipping too far and too fast into obscurity before their time. Other ideas on here might be too early in their lives. Doing something now, or even within the next decade, would only show a small part of the eventual picture.

Do I expect any of these to be made? Not particularly. But you never know.

Everyone gets lucky once in a while.