Node master key generation, explained

The node master key generator program is available at the downloads page. As of now, it was only tested on Linux, but chances are it will work on other unices as well. It was never intended to be ported to Windows, as the FEDAnet node software is not supposed to run on Windows at all. Just unpack the archive, change to the directory and type make; you only need GNU make and gcc (of almost any version; well, it is known to compile with gcc 3.*). On non-linux systems and older linux versions you might need something like make CONF="-DFEDA_NG_SCHED=0" to disable linux-specific call to the CPU scheduler.

There's a README file inside the archive, be sure to read it. Here are some notes however.

First of all, remember there are keys of different ranks, and each node decides on its own which minimal rank will be considered recognizable. It takes several seconds to find a key of rank 7, but hardly anyone will recognize a node with such a key. It may take two or three days to get a key of rank 20, and if you run the key generator for a month, you'll probably have several keys of rank 21. Rank 22 and higher are much a question of luck, but you are strongly advised not to stop the generation until a key of rank 22, 23 or even 24 is found. To give you the idea, the author of this site (and of the project) is going to use node keys of rank 20 during the initial testing and debugging period, and recognize node keys of rank 16, but once the period of testing is over, at least a 24-ranked key will be used, and the level of minimal recognizability will be set to 21 initially, and eventually raised to 22 or even 23. All this mess serves one important purpose: the node address, which is directly derived from the key, must be of some value for the node owner, yet there must be no “center of the network” of any kind, so the only known option is to use the proof of work approach.

A node ID is derived from the node's master secret key; the node ID becomes a part of IP prefix used by the node, and is used for a lot of other purposes as well. It is therefore impossible to “change” the node key; a node can only be given up altogether, possibly being replaced with another, brand new one. Hence, the node master key must be kept really private. Technically you'll never need your master key to appear on a computer connected to the Internet, and the best way to handle it is to really handle it away from any networking. If you have an old laptop or even a SBC which you can dedicate for signing your point keys (which is the only operation you need your master key for), then use it. Alternatively, you can have a live system on a USB flash, but make sure you boot your computer from a cold stop and it is disconnected from everything but the power source.

Please note that you don't need a computationally powerful machine for regular key signing operations, you only need a lot of CPU time to generate the master key, this is a one-time operation (unless, of course, you decide to change your node or have more than one of them). However, to be sure your master key didn't leak out, you should setup the machine up to the point where the key can be generated (that is, the feda-ng program works), and then disconnect the machine from any networks, permanently. Once you get a key you're satisfied with, if you need for other purposes the machine you used for the generation, then take the key away from it (e.g., on a USB flash stick, and be sure to have a copy of it on more than one media), wipe and reinstall the machine completely. Only after that you can safely connect the former generation machine back to networks.

Each instance of a running generator takes 256MB RAM (all the RAM is actively used, the program will get unreasonably slow if it has to swap even a bit) and a full power of one CPU. From the other hand, the generator reschedules its own process so as not to take any CPU time when there are any other things in the system willing to run, so perhaps it is a good idea to run exactly as many generators as you have CPUs (well, RAM is also a consideration, but hardly you have 8 CPUs and only 2 GB RAM, right?)

You are strongly adviced to create some challenge-response tables as a side effect of the master key generation; long things short, give each generator the parameter -t mytable1 (replace 1 with 2, 3 etc. for subsequent instances; they must work with different files). See the README file for details.