Module identity 

The host’s half of the tunnel identity proof: seed generation, derivation, and the pin.

protocol::identity carries the wire contract and the full design argument (why Noise KK rather than rustls — a measured cross-compile constraint on the daemon’s shipping target — and the honest ptrace limit). This module is what a launcher holds: the two seeds it generated, the payload fields they become, and the pin it stores to recognise its VM later.

Two seeds, and who learns what

At launch the host generates two 32-byte x25519 static secrets:

• the VM seed, delivered to the daemon in the run-hook payload. After the launch the host needs only its public half — the pin — and the secret half should not outlive the launch call on the host side.
• the host seed, which never leaves this process’s trust domain. Its public half is delivered to the daemon, which pins it in return. Holding this secret is what distinguishes the launching host from anyone else with the agent token.

Mutual authentication falls out: the client proves it holds the host secret, the daemon proves it holds the VM seed, and each side pinned the other’s public half before the first byte moved.

Structs

LaunchIdentity

One launch’s identity material, built by LaunchIdentity::from_seeds.

TunnelIdentity

What a launcher keeps to verify its VM later: its own secret, and the VM’s public pin.