This server uses hardware true random number generators (TRNG) to serve out true random bits to the Internet. Those bits are created using 5 Entropy Keys from http://entropykey.co.uk. As a result, these bits are of very high quality for use in the most demanding cryptographic applications, such as long term OpenPGP keys or SSL certificates. It's important to understand that these bits are not the result of a pseudorandom number generator, or PRNG such as you will find in most operating systems and software applications.
These bits are available for anyone on the Internet to use, free of charge. The benefit to you is to keep your entropy pool filled with high quality, true random data. Keeping your pool filled will speed up cryptographic software applications that need a lot of entropy for generating one-time session keys, long term keys, passwords, etc. You can follow the status of these entropy keys at http://zen.ae7.st/munin/ae7.st/hundun.ae7.st/index.html#sensors.
The domain "hundun.ae7.st" is assembled from two pieces. First is the concept of chaos in Chinese cosmogony. Hundun is the "primordial and central chaos", literally the power of chaos in Zen and the Tao. However, hundun is the supreme ideal of Taoism. Rather than noise as the Western society would have it, chaos is wholeness, oneness and nature. Chaos is the natural state of the world and the universe. Chaos is aesthetically pleasing- a state all taoists wish to achieve.
The second part of the fully qualified domain name, ae7.st, comes from my Amateur Radio callsign, AE7ST, who is Aaron Toponce, the administrator of this site. So, you could think of hundun.ae7.st as literally "chaos coming from Aaron Toponce". Further, having visited http://random.org, I wanted to provide random data to the community that they could do with as they pleased, rather than hand out the results. Thus, this server was created.
Former NSA contractor Edward Snowden has revealed that the NSA has been involved with sweeping data collection and analysis on Americans, violating their Fourth Amendment rights to search. This places even more priority to use cryptography for your day-to-day communications. Using true randomness that has not been tampered with is the only way to create mathematically secure cryptographic keys. Unfortunately, I do not know whether or not the Entropy Keys and the Broadcom chip creating random data has been tampered with by the NSA. Please use caution when using these bits.
The motivation is to provide new GNU/Linux operating system installs sufficient entropy on first boot. The big problem with the Linux CSPRNG is that it does not block /dev/urandom on first boot. As such, the CSPRNG has not been properly seeded with random data, and the output sequence is predictable. This is problematic when creating encryption keys, such as for your SSH server. By installing and configuring the packages below during install, when the box first boots, it will make an encrypted connection to this server, fill the input entropy pool, and properly seed the Linux kernel CSPRNG, so when /dev/urandom is running, it is reseeded earlier in the boot process.
This service should also be used for virtual machines. Running something like haveged(8) in a virtual machine on a host with many virtual machines could open the potential for attack from a different VM. The attacking VM could maniuplate the hardware in a predictable manner to create predictable output by haveged(8). This would result in predictable reseeding of the Linux CSPRING and potentionally causing predictable output to /dev/urandom. By each VM creating its own SSL connection, each VM will negotiate the connection at different times, which will cause different bits to reach the VM, which means each CSPRNG in the VM will be reseeded with different data. If you have a KVM server with Qemu >= 1.3, you can expose the host /dev/random device to each virtual machine as /dev/hwrng. At which point, the host KVM hypervisor could rely on a separate hardware RNG to feed /dev/random, and this service is not needed.
If you are interested in receiving these bits, you will need to install some software on your system to act as a client receiving them. I will assume that you are running Debian GNU/Linux as the client. Any GNU/Linux operating system should suffice. I have not tested this procedure with BSD, Mac OS X, Windows or mobile operating systems. However, the general idea is to connect to port 1337, decrypt the SSL-encrypted packets, and feed them into your operating system's entropy pool.
First install the software:
$ sudo aptitude install stunnel4 ekeyd-egd-linux
Configure stunnel to start on boot by editing the /etc/default/stunnel configuration file:
# /etc/default/stunnel # Julien LEMOINE <email@example.com> # September 2003 # Change to one to enable stunnel automatic startup ENABLED=1 FILES="/etc/stunnel/*.conf" OPTIONS="" # Change to one to enable ppp restart scripts PPP_RESTART=0
Then configure Stunnel to connect to the remote port by adding the following to your /etc/stunnel/stunnel.conf configuration file:
client=yes [ekeyd] accept=8888 connect=126.96.36.199:1337
Then configure the ekeyd-egd-linux client to start on boot by editing the /etc/default/ekeyd-egd-linux configuration file, and change the reconnect to 60 seconds, in the event of a network connection timeout:
# Change to YES to allow ekeyd-egd-linux to start. Ensure the below are # correctly configured first though. START_EKEYD_EGD_LINUX=YES # Change this if you want it to be something other than the default # HOST=127.0.0.1 # PORT=8888 # Number of bits minimum in the pool, below which the daemon will kick in # and transfer data from the EGD to the pool (providing it's available) # WATERMARK=1024 # Number of 1024 bit (128 byte) blocks to transfer to the kernel each # time it dips below the low water mark. # BLOCKS=3 # How many shannons-per-byte to claim for data pushed to the pool # SHANNONS=7 # How many seconds between connection retries. Zero means do-not-retry. RETRYTIME=60
Now (re)start the stunnel and ekeyd-egd-linux daemons:
$ sudo /etc/init.d/stunnel restart $ sudo /etc/init.d/ekeyd-egd-linux restart
Verify now that you have made the connection, and that you are filling your entropy pool:
$ netstat -tan | awk '/ESTABLISHED/ && /188.8.131.52:1337/' tcp 0 0 10.80.86.100:35829 184.108.40.206:1337 ESTABLISHED $ cat /proc/sys/kernel/random/entropy_avail 3968
You should be very concerned about me tracking which bits I have sent to established connections. However, I promise I am not tracking which bits are sent to which IP address. That's too much work, and I'm really not that interested. I don't even want my ISP, nor your ISP, to know which bits I have sent or that you have received, thus the requirement to send this over SSL. However, if you are worried about me tracking which bits you have received, then please don't use this service.
Using these bits is completely harmless. Anyone on the system can write to /dev/random. Writing non-random, predictable data is harmless. This is because the Linux CSPRNG takes the SHA1(entropy) as it's output. Worst case, your entropy pool will not increase. Further, you can test the quality of randomness that I am serving, by using some random number tests, such as the FIPS 140-2 tests by rngtools, as shown below.
$ timeout 90m rngtest < /dev/random rngtest 2-unofficial-mt.14 Copyright (c) 2004 by Henrique de Moraes Holschuh This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. rngtest: starting FIPS tests... rngtest: bits received from input: 1735680032 rngtest: FIPS 140-2 successes: 86720 rngtest: FIPS 140-2 failures: 64 rngtest: FIPS 140-2(2001-10-10) Monobit: 13 rngtest: FIPS 140-2(2001-10-10) Poker: 8 rngtest: FIPS 140-2(2001-10-10) Runs: 22 rngtest: FIPS 140-2(2001-10-10) Long run: 23 rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 rngtest: input channel speed: (min=106.092; avg=366.208; max=1433.381)Kibits/s rngtest: FIPS tests speed: (min=327.975; avg=2207.022; max=6353.692)Kibits/s rngtest: Program run time: 5400019989 microseconds Terminated
This server is powered currently by a Raspberry Pi running Nginx behind a crappy DSL connection. As a result, I am constantly monitoring for abuse or heavy connections. If you are abusing my light setup, I will firewall you away from the hardware, and you will not be able to use the service. If you use the above defaults, and leave your box powered on 24/7, everything will be fine. If you change the WATERMARK to 4096, and run a cluster of computers as clients to this setup, you will likely be banned. So, please don't ruin it for everyone else by flooding my pipe with your datacenter. Instead, spend the $40 on your own entropy keys. If you are unsure, email me at firstname.lastname@example.org. Thanks.