Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Security policy

Project status

HashSigs RHDL is research hardware and has not received an independent cryptographic or side-channel audit. It implements the custom WOTS+ construction used by a pinned HashSigsRS revision. It is not XMSS, SLH-DSA, FIPS 205, or a many-time signature system.

Do not use this repository as the sole protection for production secrets until its protocol, generated RTL, integration shell, physical implementation, key lifecycle, and side-channel behavior have been reviewed for that deployment.

Critical operating requirements

  • Never reuse a WOTS private key. One private key signs at most one message. Reuse can reveal enough chain material to enable a forgery.
  • Bind the profile identifier outside serialized keys and signatures. LEGACY_KECCAK and HASHSIGS_SHA256_GENERIC_V1 have the same lengths but are cryptographically incompatible.
  • Supply a collision-resistant, domain-separated 32-byte application digest. WOTS does not hash an arbitrary-length application message for the caller.
  • Treat reset and zeroization as defined hardware boundaries. Reset invalidates ownership; it does not imply that every unused data register or memory bit was physically scrubbed.
  • The current hardware verifier supports the SHA-256 profile only. Legacy Keccak verification is available through the software reference path, not the active RHDL verifier top.

Supported versions

Security fixes are applied to the current main branch. No older release line is currently maintained.

Reporting a vulnerability

The canonical contact and policy location is https://hashsigsdocs.sahastasai.com/project/security. It will name a verified private reporting channel when one is available. Until that channel is published, do not send sensitive vulnerability details through a public issue or pull request.

An operational private channel is a prerequisite for inviting confidential reports, not something this document guesses. When available, a report should include the affected commit and profile, whether the problem is in software, RHDL source, generated RTL, FPGA integration, or documentation, and a minimal reproduction when safe. Do not include real private keys, credentials, or unrelated host data.

Evidence corrections

An incorrect performance or hardware claim can be reported through the same private channel when disclosure could expose a security weakness. Ordinary documentation corrections may use a pull request. Evidence is downgraded until the exact producing artifact has been revalidated.