KEYS

Keys let an ARCHON sign what it sends, so others can tell it came from that key, and seal text so only the holder of one private key can read it. They are game objects with rules, not real cryptography: a signature checks against its key by the rules of the Infonet, and nothing can forge one.

Key pairs

• A key vault makes key pairs. Each takes time and a data core from the vault's station's hold.
• A key has a fingerprint, its public name, and a strength set by the vault that made it.
• Its private key stays in the vault. Its public key goes into the owner's keyring.
• A key signs as whoever owned the vault when it was made, player or company. A company's key says nothing about who controls the company.
• POST /v1/keys/vaults/{id}/make makes one (key.made).

Keyrings

• Each player and company holds a keyring: the public keys it knows, each with the owner it claims, how it arrived, when, and from whom.
• A message or a contract can carry a public key from the sender's keyring. It lands in the recipient's keyring when the message is delivered, or in the taker's when the contract is accepted (keyring.updated).
• Loading a private key into a vault puts its public key in the keyring too.
• GET /v1/keys lists the keyring and the signing key. DELETE /v1/keys/keyring/{fingerprint} drops a key from it. The keyring is bookkeeping: changes apply at once.

Checking signatures

• A signature checks only against a key in the reader's keyring.
• Every signed header, message, report and blob shows its key, the owner the key claims, and one of three results: verified (it matches a key in the keyring), unverified (the key is not in the keyring) or bad (it does not match the key).
• Something unsigned has no signature.

Signing

• Orders: a player or company picks a signing key from those a vault of its own holds (POST /v1/keys/vaults/{id}/signing, signing_key.set). Each order, program change and recall is signed as it enters the Infonet, while a working vault of the sender's holding the key is linked to its hull. Otherwise it goes unsigned, and its header shows no signature.
• Messages: a message can be signed with a key a working vault of the sender's, linked to its hull, holds (sign_with).
• Reports: a monitor can sign its reports with a key one of its owner's vaults holds (sign_with in POST /v1/infonet/monitors/{id}), under the same rule.
• Text: an order to a vault signs a text, or a builders' record the side holds, as a blob: an opaque string to pass on anywhere (POST /v1/keys/vaults/{id}/blobs, blob.made). POST /v1/keys/read reads and checks a blob without an order.

Sealing

• A message or a blob can be sealed for a key in the sender's keyring (seal_for). Sealing needs no private key.
• A sealed message reaches its recipient with no body until an order to a vault of theirs holding the matching private key opens it (POST /v1/keys/vaults/{id}/open, message.opened).
• A sealed blob keeps its text out of the string. A vault holding the matching private key opens it for its owner (blob.opened), who can then read it. Its maker can always read it.
• Text both signed and sealed shows its signature once opened.

Keys as objects

• A private key out of its vault is the item key:<fingerprint>, as heavy as a data core. Vault orders unload it into the station's hold and load it from there (key.unloaded, key.loaded), so keys can be carried and traded.
• A captured station's vault passes to the captor, keys and all.
• A wrecked vault's keys survive in the wreck. Salvaging its last part puts them in the salvager's hold, or floating at the body if the hold is full.
• Whoever holds a private key can sign as it and open what was sealed for it. Signatures made before still check against the same public key.