One-time-key lifecycle

WOTS exposes values from hash chains. Two signatures from the same private key can expose complementary positions and enable an attacker to construct a value needed for another message. The safe rule is exact: one private key, at most one signed message.

What the Rust API helps with

The software reference uses non-Clone, consuming private-key values for signing. Profile parameters are also separate Rust types. These choices prevent several accidental mistakes inside one process.

They do not prevent:

• reconstructing the same key from a reused seed;
• restoring an old database snapshot;
• two machines allocating the same one-time index;
• replaying a hardware request after uncertain completion;
• copying raw private material before it enters the typed API.

System responsibility

A deployment needs an atomic allocator and durable state transition such as:

unused → reserved → consumed

Do not return reserved to unused after an ambiguous timeout. If the system cannot prove that no signature was produced, burn that key.

Bind the allocation identity, cryptographic profile, application domain, and message digest in authenticated metadata. Backup and disaster-recovery procedures must preserve consumed state.

Reset is not key rollback

Hardware reset invalidates in-flight ownership and flushes valid state. It does not make an already accepted private key safe to reuse, and it does not claim physical scrubbing of every wide inactive register or memory bit.