onion key rotation and a chain drawn at random

two changes reached the main branch since the last note, the two that note named as next: forward secrecy for circuit layers and a node list longer than three. the numbers on the research page are the same preliminary series as before.

a relay replaces its onion key

until now a relay used one agreement key for as long as it ran. a neighbour that kept the setup cells could, once that key was stolen, open the relay’s layers for all that time.

a relay now holds a separate onion key and replaces it on a timer. the descriptor carries the current key and its epoch. the relay keeps the replaced key until every descriptor that named it has expired, so a client holding a slightly older descriptor still builds its circuit, and then releases the key from locked memory.

a setup cell kept by a neighbour opens only while the relay holds the key it was built for: at most the rotation period plus the descriptor lifetime and the clock allowance after that key was first published. memory taken after the release does not open the cell.

the window is counted on two clocks, the wall clock and the running time of the host, and each step happens as soon as either clock says so. a host that sleeps does not extend the window beyond its waking, and a wall clock set back does not extend it at all.

why it matters: this is the countermeasure against a neighbour that records setup cells and later obtains a relay’s key.

the client draws its chain

the testbed now runs five relays, and the client lists all of them. at every start it draws its entry at random, asks that entry for the signed bundles of every listed node, verifies them against the anchor and only then draws the other two hops. the request is the same whatever the chain, so it does not show the chain.

the client does not log the chain. after any failure it exits and draws a new one at its next start. one setup cell carries up to four hops on the default suite and three on gost. a fixed chain stays as a switch for measurements that need a known path.

every relay mirrors the bundles it holds. a relay whose bundle is missing is left out of a mirror instead of taking the whole mirror down, and the client accepts a mirror that leaves out a bounded number of listed nodes, one by default. a bundle that is listed and fails the check refuses the circuit.

why it matters: with a fixed chain the same three relays carried every circuit and each knew its position. with a drawn chain, how often a circuit meets rogue nodes is a quantity that can be computed and sampled, and the lab now does both.

what this does not fix

• rotation does not cover the hop keys of circuits that are alive when memory is taken, the link key, or the copies of released keys that the libraries left on the heap.
• rotation is the relay’s own doing. a client cannot check that a replaced key was released.
• the node list is static: there is no node discovery and no directory signed by several parties.
• a rogue entry can leave an honest node out of its mirror and so raise the chance that the exit is rogue as well. the bound on nodes left out limits how far.
• a relay can serve a different onion key to each of the others. the key that opens a setup cell then tells it whose mirror the client used, so a rogue exit can learn the entry.
• a relay that refuses or breaks the circuits it does not like decides which chains survive.
• there are no guard nodes: every circuit draws a fresh entry, so the chance that at least one circuit had a rogue entry and a rogue exit grows with every restart of the client.

next on the roadmap are a recipient client with an end-to-end layer and deniable authentication between clients.

the full list is on the limits page and in limitations. the onion key rotation and the choice of the chain are described in architecture, the threats and countermeasures in the threat model, and how drawn chains are measured in experiment.