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

推荐订阅源

Vercel News
Vercel News
博客园 - 司徒正美
C
Check Point Blog
G
Google Developers Blog
The GitHub Blog
The GitHub Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
有赞技术团队
有赞技术团队
P
Proofpoint News Feed
IT之家
IT之家
B
Blog
博客园_首页
量子位
MongoDB | Blog
MongoDB | Blog
博客园 - Franky
J
Java Code Geeks
H
Help Net Security
A
About on SuperTechFans
Apple Machine Learning Research
Apple Machine Learning Research
Jina AI
Jina AI
D
DataBreaches.Net
Y
Y Combinator Blog
大猫的无限游戏
大猫的无限游戏
云风的 BLOG
云风的 BLOG
Google DeepMind News
Google DeepMind News

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
Threshold Signatures and FROST: One Signature, No Single ...
Haven Messenger · 2026-06-18 · via DEV Community

Haven Messenger

Splitting a key with Shamir's scheme protects a secret at rest, but to use it you have to reassemble the whole key in one place — and for one fatal moment, somebody holds all of it. Threshold signatures remove that moment entirely: a quorum jointly produces a valid signature while the complete private key never exists anywhere, not even briefly. FROST is the design that made this fast enough to deploy.

Imagine three executives who must collectively authorize wire transfers, a custody service guarding crypto assets across geographically separate machines, or a certificate authority that does not want any single operator able to sign on its behalf. The shared requirement: an action that needs multiple parties to agree, with no individual able to act alone, and ideally no single machine that — if compromised — hands an attacker the full signing power.

There are several ways to approximate this, and they are not equally good. Understanding why threshold signatures win for many of these cases means understanding what the alternatives leak.

The Three Approaches, and Their Seams

Secret sharing

Shamir's Secret Sharing splits a key into n shares such that any t reconstruct it and fewer reveal nothing. It's elegant for protecting a key you rarely use. But the act of using the key requires reassembling it — gathering t shares onto one machine, which becomes a single point of total compromise at exactly the moment of highest value. The full key briefly exists. An attacker who owns that machine during signing owns everything.

Multisignature (multisig)

Multisig, familiar from Bitcoin, takes a different route: each party has a fully independent key, and the verifier checks that t separate signatures are present. No key is ever combined — a real strength. The cost is on the verification side: the signatures are visible as multiple distinct signatures, the policy (who signed, how many are required) is exposed on-chain or on the wire, and the size and fees grow with the number of signers. It works, but it advertises its own structure.

Threshold signatures

A threshold signature scheme (TSS) gives you the best of both. Like multisig, no party holds the whole key. Unlike multisig, the parties run an interactive protocol that outputs one ordinary signature — indistinguishable from a signature made by a single key. The verifier sees a normal signature against a single public key and has no idea, from the signature alone, that a quorum of five machines in four countries produced it.

The key insight: In a threshold scheme the full private key is never assembled — not during setup, not during signing, not ever. It exists only as a mathematical relationship distributed across the participants' individual key shares. There is no instant where stealing one machine's memory yields the whole secret.

Where FROST Comes In

Threshold Schnorr signatures are appealing because Schnorr signatures are clean and linear, which makes them friendlier to "split across parties" math than ECDSA. But early threshold Schnorr constructions needed multiple interactive rounds of communication for every signature, and were fragile in the face of concurrent signing sessions — a serious problem for any real service handling parallel requests.

FROST — Flexible Round-Optimized Schnorr Threshold signatures, introduced by Komlo and Goldberg in 2020 and specified by the IETF in RFC 9591 (2024) — solved the practicality problem. Its headline properties:

  • Round efficiency. Signing takes a single round of interaction when participants pre-process commitments in advance, or two rounds without pre-processing — a major improvement over earlier multi-round schemes.
  • Concurrency safety. FROST is designed to remain secure even when many signing sessions run at once, avoiding the ROS-style attacks that broke naive parallel Schnorr signing.
  • Standard output. The result is a normal Schnorr signature, verifiable with the ordinary single-key verification algorithm. No special verifier is needed.
  • Flexible thresholds. Any t-of-n policy, configurable at key-generation time.

How a FROST Signature Comes Together

Without drowning in notation, the shape of the protocol is:

  1. Distributed key generation (DKG). The n participants jointly run a protocol that produces a shared public key and gives each participant a private share. No party — and no coordinator — ever sees the corresponding full private key. (A trusted dealer can alternatively distribute shares, but DKG removes even that single point of trust.)
  2. Commitment. Each of the t signers picks fresh random nonces and publishes commitments to them. With pre-processing, this happens before the message to sign is even known.
  3. Signing. Given the message, each signer computes a partial signature using its share and its nonces, binding in the others' commitments to prevent manipulation.
  4. Aggregation. A coordinator (who needs no secret material) sums the partial signatures into one final Schnorr signature. The coordinator can verify each partial contribution, so a misbehaving signer can be identified rather than silently corrupting the result.

The randomness handling deserves emphasis. Schnorr signatures are catastrophically broken by nonce reuse — repeat a nonce and the private key falls out of the algebra. Distributing signing across parties multiplies the ways nonce handling can go wrong, which is exactly why FROST's careful, binding commitment structure (and its concurrency analysis) is the substance of the scheme, not a detail.

Threshold vs Multisig, Compared

Property Multisig Threshold (FROST)
Full key ever assembled No No
Output signature Multiple, distinct One, ordinary
Policy visible to verifier Yes — exposes signers/threshold No — looks single-key
Size / cost scaling Grows with signers Constant
Needs interaction to sign No (signers act independently) Yes — signers coordinate
Verifier complexity Must understand the policy Standard verification

The trade-off is real: threshold signing requires the participants to be online and to interact during signing, whereas multisig signers can act fully independently. That interactivity, plus the subtlety of getting the protocol right, is the price of the privacy and uniformity benefits.

A threshold signature is the cryptographic version of a rule that says "this door needs three keys turned at once, but anyone watching it open just sees a door open." The structure of the authority is invisible from outside.

Where You'll Encounter It

Threshold and multi-party signing now underpin institutional crypto custody, hot-wallet protection, distributed certificate authorities, and the signing infrastructure behind some software supply-chain and code-signing systems. The common thread is high-value signing authority that no single person or machine should be able to exercise alone — and that benefits from not advertising its own governance structure to everyone who checks a signature.

It is not a tool for everyday application authentication; the interactivity and operational complexity only pay off when the signing key is genuinely catastrophic to lose. For most systems, simpler controls are the right answer. But where the stakes justify it, FROST is the current state of the art for doing it efficiently.

Where Haven Fits

Haven doesn't ask you to run a quorum to send a message — that would be the wrong tool for personal communication. But the underlying principle is exactly the one we build on: no single party should hold the power to read or impersonate you. In Haven, your keys are derived on your device and never assembled on a server we could be compelled to hand over. Threshold cryptography is the institutional expression of the same idea we apply at the individual level — distribute trust so there is no one place an adversary can break to win everything.

Originally published at havenmessenger.com