惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

罗磊的独立博客
L
LangChain Blog
aimingoo的专栏
aimingoo的专栏
IT之家
IT之家
B
Blog
博客园_首页
博客园 - 司徒正美
有赞技术团队
有赞技术团队
博客园 - 聂微东
I
InfoQ
美团技术团队
GbyAI
GbyAI
阮一峰的网络日志
阮一峰的网络日志
H
Help Net Security
大猫的无限游戏
大猫的无限游戏
MyScale Blog
MyScale Blog
WordPress大学
WordPress大学
The GitHub Blog
The GitHub Blog
A
About on SuperTechFans
人人都是产品经理
人人都是产品经理
Microsoft Azure Blog
Microsoft Azure Blog
Engineering at Meta
Engineering at Meta
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
The Cloudflare Blog

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Hash-Based Signatures: The Most Conservative Path to Post...
Haven Messenger · 2026-06-15 · via DEV Community

Haven Messenger

Nearly every digital signature in use today — RSA, ECDSA, Ed25519 — rests on a number-theory problem that a large quantum computer would solve efficiently. Hash-based signatures take a radically narrower bet: they assume only that a secure hash function exists. That single assumption makes them the most conservative quantum-resistant signatures we have, and the story of how they're built is one of the most elegant in cryptography.

A digital signature scheme rests on some hard problem. RSA rests on the difficulty of factoring large numbers; elliptic-curve schemes rest on the discrete logarithm problem. Shor's algorithm, run on a sufficiently large quantum computer, breaks both. That is the entire motivation for post-quantum cryptography: replacing those foundations with problems quantum computers are not known to solve quickly.

Most post-quantum signature proposals lean on relatively young assumptions — structured lattices, in the case of the lattice schemes now being standardized. Hash-based signatures lean on something far older and far better understood: the security of cryptographic hash functions. We have studied hash functions for decades, we use them everywhere, and a secure hash is the minimal assumption you could possibly want. If your hash function holds, your signatures hold. That is the entire pitch, and it is a strong one.

Lamport: A Signature From Nothing But Hashing

The foundation is the Lamport one-time signature, described by Leslie Lamport in 1979. The idea is almost shockingly simple. To sign a single bit, you generate two random secret values and publish their hashes as your public key. To sign a "0," you reveal the first secret; to sign a "1," you reveal the second. Anyone can hash the revealed value and check it against the public key, but no one can produce the other secret, because a hash function cannot be run backwards.

Extend that to a full message by hashing the message to a fixed-length digest and signing each of its bits with its own pair of secrets. The security rests entirely on the one-way property of the hash. There is no modular arithmetic, no elliptic curve, no factoring — just hashing.

Why "one-time" is in the name: Each Lamport key pair can safely sign exactly one message. Signing a second message reveals more of your secret values, and an attacker who collects enough revealed secrets across multiple signatures can begin forging. The "use once" rule is not a suggestion — it is load-bearing.

Winternitz: Trading Time for Space

Lamport signatures are simple but large, because you need secret pairs for every bit. The Winternitz one-time signature scheme (WOTS, and the refined WOTS+) shrinks them by signing several bits at once using repeated hashing — applying the hash function a number of times that encodes the value, rather than revealing one of two secrets per bit. The result is a tunable trade-off: more hashing per signature in exchange for smaller keys and signatures. WOTS+ is the one-time building block inside the practical schemes that follow.

Merkle Trees: One Public Key for Many Signatures

A one-time signature you can only use once is not much of a signature scheme. Ralph Merkle's insight, also from the late 1970s, turns it into a usable one. Generate many one-time key pairs. Hash all their public keys into the leaves of a binary Merkle tree, and let the single root of that tree be your one real public key.

Now you can sign many messages: each signature uses a fresh one-time key from a leaf, and includes the "authentication path" — the sequence of sibling hashes that lets a verifier climb from that leaf back to the published root. The verifier confirms the one-time signature, then confirms the leaf belongs to the tree whose root they trust. One compact public key now authenticates thousands or millions of one-time keys.

The State Problem

This construction — the Merkle signature scheme and its modern descendants XMSS (RFC 8391) and LMS (RFC 8554) — is efficient and well understood. NIST approved XMSS and LMS in Special Publication 800-208. But it carries a sharp and dangerous requirement: it is stateful. The signer must remember which leaves have already been used and never reuse one.

That sounds trivial until you think about real systems. Restore a virtual machine from a snapshot, and you roll the state back to a point where unused leaves now appear unused again — and you sign with a leaf you already burned. Clone a server, run two copies, and they share a counter. Any of these reuses a one-time key, and one-time keys are catastrophic to reuse. The cryptography is sound; the operational discipline is brutal.

A stateful hash-based scheme is only as safe as your guarantee that you will never, under any backup, migration, or failure, sign twice with the same leaf. For many deployments that guarantee is simply not achievable.

SPHINCS+: Paying to Be Stateless

The answer to the state problem is SPHINCS+, which NIST selected and standardized as SLH-DSA in FIPS 205 in 2024. SPHINCS+ is stateless: it eliminates the dangerous counter entirely. Instead of tracking which leaf to use, it selects one pseudorandomly from such an enormous space that accidental collisions are negligible, and it layers a hypertree of Merkle trees together with a few-time signature scheme (FORS) to make that work securely.

The price is size and speed. SPHINCS+ signatures are large — on the order of several kilobytes to tens of kilobytes depending on the parameter set, far bigger than a 64-byte Ed25519 signature — and signing is comparatively slow. What you buy with that cost is the removal of state management and a security argument resting on nothing but the strength of the underlying hash function. For a signing key that must remain trustworthy for decades, many designers consider that the most defensible trade available.

Scheme State Trade-off
Lamport / WOTS+ One-time only The building block; not used standalone
XMSS / LMS Stateful Efficient, smaller — but reuse is catastrophic
SPHINCS+ (SLH-DSA) Stateless Safe to deploy anywhere; large, slow signatures

When to Reach for Them

Hash-based signatures are not the default choice for high-volume, latency-sensitive work — the lattice-based ML-DSA (Dilithium) is faster and more compact for general use. Where hash-based schemes shine is anywhere you want the most conservative possible security foundation and can tolerate larger signatures: firmware and software signing, long-lived roots of trust, and any key whose compromise decades from now would be unacceptable. Their value is precisely that they do not depend on a young, structured assumption that might fall to future cryptanalysis.

This is cryptographic agility reasoning in practice: matching the conservatism of the primitive to the lifetime of the thing it protects. A session key that lives for minutes can take a more aggressive bet; a code-signing root that must hold for twenty years should take the most boring, best-understood assumption available.

The Deeper Point

Hash-based signatures are a reminder that cryptographic strength is, fundamentally, about the quality of your assumptions. The entire edifice — one-time signatures, Winternitz compression, Merkle authentication, hypertrees — is built to extract a full, practical signature scheme from the single premise that a hash function is hard to invert. There is a quiet rigor to that. It refuses to assume anything it doesn't have to.

That same instinct guides how Haven approaches the cryptography underneath encrypted messaging: prefer well-understood, widely-vetted primitives over novel constructions, and keep verification tests green so the foundations stay sound as the field moves toward a post-quantum world. The most trustworthy systems are usually the ones that assume the least.

Originally published at havenmessenger.com