FROST signifie Flexible Round-Optimized Schnorr Threshold. Ce protocole de signature à seuil permet à suffisamment de participants de signer sous une clé publique commune sans réunir toute la clé secrète au même endroit pendant la signature.
Dans un schéma 2 sur 3, deux parts autorisées disponibles suffisent, tandis qu’une seule ne permet pas de signer. Un attaquant qui en obtient deux atteint lui aussi le seuil. Une part de clé durable n’est pas une signature partielle d’un message : il faut le protocole collectif et de nouvelles valeurs à usage unique. [RFC 9591 — FROST]
Un distributeur de confiance peut créer le secret et répartir les parts ; il connaît donc toute la clé et doit la traiter de manière sûre. DKG permet une génération collective sans ce distributeur unique, avec ses propres échanges et vérifications. RFC 9591 définit surtout la signature ; son annexe sur le distributeur ne signifie pas que tout déploiement utilise automatiquement DKG. [RFC 9591 — FROST] [ZF FROST Book — key generation and recovery]
Au premier tour, un participant crée deux nonces secrets et partage leurs engagements publics. Au second, il vérifie le message, la liste des participants et ses propres engagements, puis calcule sa part de signature. Un coordinateur agrège les parts. Des facteurs de liaison rattachent les nonces au message et à l’ensemble d’engagements précis ; les deux tours excluent la génération préalable des clés. [RFC 9591 — FROST] [ZF frost-secp256k1-tr — Taproot implementation]
Réutiliser un nonce peut révéler des secrets cryptographiques. Après usage, les nonces secrets doivent être retirés de manière sûre, même si la tentative est interrompue ; restaurer une ancienne sauvegarde ne doit pas les rendre réutilisables. Aléa, sessions simultanées et suivi persistant de la consommation relèvent de la sécurité, pas seulement de la vitesse. [RFC 9591 — FROST]
Le coordinateur collecte engagements et parts de signature ; sans assez de parts de clé, il ne peut pas signer seul. Il peut toutefois retenir des messages ou provoquer un abandon. Vérifier une part incorrecte peut identifier son auteur, pas garantir la fin de la session. Un transport authentifié et suffisamment de participants disponibles restent nécessaires. [RFC 9591 — FROST]
Pour Bitcoin, le résultat doit respecter l’encodage, le hachage et les règles exactes de BIP 340 ainsi que les éventuels ajustements de clé Taproot. Choisir secp256k1 dans une suite FROST générique ne suffit pas. ZF fournit séparément frost-secp256k1-tr pour Taproot ; vérifie la suite et ses tests. Une signature unique sur la chaîne ne révèle pas à elle seule le seuil interne. [ZF frost-secp256k1-tr — Taproot implementation] [BIP 340 — Schnorr Signatures for secp256k1]
Une part exige son identifiant correct, les données publiques du groupe et un logiciel compatible. Récupérer une part perdue avec les autres ou renouveler les parts implique des protocoles supplémentaires que le déploiement doit réellement gérer. Copier la même part n’ajoute pas de participant indépendant. Les sauvegardes doivent préserver le seuil tout en empêchant le retour de nonces consommés. [ZF FROST Book — key generation and recovery] [ZF frost-secp256k1-tr — Taproot implementation]
Chaque signataire doit vérifier destinataires, montants, frais et règles d’approbation au lieu de signer aveuglément un hash fourni par le coordinateur. FROST assure une signature collective, pas la justesse de l’intention commerciale. Vérifie version de l’implémentation, récupération et comportement en cas de panne ; un RFC informatif ne certifie pas le portefeuille entier. [RFC 9591 — FROST]
Pour une vision complète, lisez aussi Schnorr signature, MuSig2, Multisig, Taproot, Shamir Secret Sharing.