A live keynode is a live process known as a PolyKey Agent process. A dead keynode consists of only the keynode state stored at the node path.
When launching the Polykey Agent, the node goes into a bootstrapping phase. This is where it constructs the keynode state. The keynode state is also known as the node path. This can exist in your operating system's user profile data.
On Linux this would be
~/.local/share/polykey. However you can select the
exact location of the node path, it can be anywhere.
This location is where all the vault state, networking state, discovery state will be stored.
If the node detects that the node state is already initialised, and it is not corrupted, then it will attempt to unseal the node state by asking the user for the root password for the root key.
If the node state has not been initialised, then the first thing that a node will do is to generate a root certificate and the root key consisting the root public key and root private key.
The root private key needs to be password protected. The user must supply the root password in order to encrypt the root public key.
The root certificate is an X.509 certificate. This certificate will serve as the secure digital identity of the keynode.
The root public key which is encoded in the root certificate is the globally unique identity of the keynode. This is known as the node ID. The node ID is used to identify the node in the peer to peer distributed hash table (DHT).
Our current root keys are RSA keys. Eventually we will move to using Ed25519 keys. Because our current root keys are RSA keys, they are very long. Our node IDs are therefore MD5 hashes of the PEM-encoded RSA public key. This is temporary until we have integrated Ed25519 keys, and our node IDs will be much shorter.
Note that current modern websites tend to use ECDSA root keys, this is similar to Ed25519, but we will be looking to use Ed22519 instead of ECDSA in the future.
Here are some examples.
Subject Public Key Info:
Public Key Algorithm: RSA
Public-Key: (4096 bit)
Exponent: 65537 (0x10001)
Subject Public Key Info:
Public Key Algorithm: ECDSA
Public-Key: (256 bit)
The root key is used to generate and encrypt symmetric vault keys. The vault keys will be used to encrypt the vault filesystems.
After the root certificate, root keys are generated, and initial state directories are generated, the node enters the network bootstrapping phase.
This means it will start a gRPC server listening on
0.0.0.0:1314. This gRPC
server is how the Polykey CLI and Polykey GUI and Polykey Browser Extension will
communicate with the Polykey Agent.
It will also start an uTP server on
0.0.0.0:1314 over UDP for NAT traversal.
It will also start an HTTP 1.1 server on
0.0.0.0:1315 for HTTP integration.
All keynodes are preconfigured to trust and contact the bootstrap keynode
bootstrap.polykey.io. This in the future will likely be load balanced via
both DNS load balancing and also TCP/UDP load balancing.
bootstrap.polykey.io is itself a Polykey keynode. This node is maintained
by the official Polykey team. This nodes serves 3 duties:
- P2P DHT synchronisation to allow globally decentralised nodes to share their node table information
- STUN NAT traversal - to faciliate direct P2P connections between compatible nodes
- TURN Relay NAT traversal - to facilitate proxied P2P connections between incompatible nodes
The first duty is the most important one. Without the
is not possible for nodes that are on separate subnets to discover each other.
Users are able to run their own "bootstrap nodes". Corporate networks can run their own bootstrap nodes. You can override the bootstrap node configuration to point to other bootstrap nodes. You can pay us to run bootstrap nodes.
The second and third duties are much more process intensive and is there to allow users of PolyKey to bust through NATs. NATs were developed to get around the limited amount of IPv4 addresses available. With IPv6 they are now considered obsolete. Some corporate networks may still use NATs as a rudimentary firewall. In the future, PolyKey will fully support IPv6 and the need for STUN or TURN NAT busting will be lessened.
At this point the node is setup and fully operational. It is time to create vaults, put secrets into them, discover your friends and enemies, and share your vaults with them.