Aller au contenu
Financial Context Wiki

Signatures BLS

Un guide axé sur la vérification des signatures Boneh-Lynn-Shacham, les modes d'agrégation, les suites cryptographiques, les protections contre les clés malveillantes, leur emploi dans le consensus Ethereum et les risques d'implémentation.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

Une signature Boneh-Lynn-Shacham est une signature numérique fondée sur des couplages bilinéaires. Dans une orientation courante, la clé secrète sk produit la clé publique PK = sk * G1 ; le message m est projeté sur H(m) dans G2 ; et la signature sig = sk * H(m) se vérifie par e(PK, H(m)) = e(G1, sig). Les groupes précis, les encodages, la suite hash-to-curve et la séparation de domaines relèvent de la suite cryptographique et ne sont pas des notations interchangeables.

BLS présente un avantage opérationnel inhabituel : les signatures valides peuvent être additionnées en un seul élément de groupe de taille constante. Cette propriété compresse les signatures, mais pas la liste des signataires ; elle ne prouve pas davantage un quorum, n’identifie pas les validateurs autorisés, n’empêche pas l’équivoque et ne rend pas le consensus définitif. Ces garanties proviennent du protocole environnant.

Fonctionnement

  1. Fixez le protocole, la suite cryptographique et la version : courbe, groupes des clés publiques et des signatures, sérialisation, fonction hash-to-curve, étiquette de séparation de domaine et construction de la racine du message. Ne déduisez jamais la compatibilité du seul sigle BLS.
  2. Générez sk avec la procédure de génération de clés prescrite et dérivez PK. Rejetez les encodages nuls, à l’infini, mal formés, non canoniques ou dans le mauvais sous-groupe en appliquant exactement KeyValidate et les règles de désérialisation.
  3. Construisez les octets exacts du message et le domaine de signature. Dans le consensus Ethereum, la racine de signature lie la racine SSZ d’un objet à un domaine dérivé du type d’opération et des données du fork ; le texte affiché n’est pas l’objet signé.
  4. Signez et vérifiez individuellement avec le schéma retenu. Les variantes Basic, augmentation du message et proof of possession emploient des défenses différentes contre les clés malveillantes et ne doivent pas être mélangées sans précaution.
  5. Choisissez le vérificateur agrégé selon le schéma des messages. Utilisez FastAggregateVerify uniquement pour plusieurs clés publiques validées signant le même message sous les hypothèses requises de proof of possession ; utilisez AggregateVerify pour la liste de clés publiques et de messages permise par le schéma.
  6. Reconstituez indépendamment l’ensemble des signataires à partir des données du comité ou d’une bitlist de participants, rejetez les indices en double ou non autorisés, appliquez les pondérations de stake ou de seuil, puis vérifiez la signature agrégée. Un agrégat valide authentifie l’ensemble fourni ; il ne décide pas si cet ensemble respecte la politique.
  7. Rapprochez le résultat du fork choice, des conditions de slashing, du quorum, de la disponibilité, des délais et de la finalité. Conservez les octets d’entrée, domaines, indices des signataires, version de l’implémentation et vecteurs de test, puis comparez des bibliothèques indépendantes avant tout déploiement.

Exemples détaillés

  • La compression ne supprime pas les données d’appartenance. Le consensus Ethereum encode chaque clé publique BLS sur 48 bytes et chaque signature sur 96 bytes. Pour 512 signatures du même message, les signatures séparées occupent 512 * 96 = 49,152 bytes. Une signature agrégée accompagnée d’une bitlist de participants de 512-bit = 64-byte occupe 96 + 64 = 160 bytes, soit une réduction de 49,152 - 160 = 48,992 bytes, ou 99.6744791667%. Les clés publiques des validateurs et la correspondance avec le comité doivent toujours être disponibles ailleurs.
  • Agrégation d’un même message. Supposons que les validateurs enregistrés 17, 24 et 91 signent tous la même racine de signature R. Leurs signatures s’agrègent selon sigAgg = sig17 + sig24 + sig91. La vérification emploie l’ensemble ordonné et validé des clés publiques [PK17, PK24, PK91], la même R et FastAggregateVerify. Un résultat valide prouve que ces clés ont signé R selon le schéma ; une règle distincte détermine leur poids et si trois signataires constituent un quorum.
  • Des messages distincts exigent la bonne API. Les clés PK1, PK2 et PK3 signent les messages distincts m1, m2 et m3. Le vérificateur doit préserver les couples [PK1, m1], [PK2, m2], [PK3, m3] et appeler l’AggregateVerify applicable ; remplacer ces entrées par un seul message et FastAggregateVerify vérifie une autre affirmation. Avec le schéma Basic, les messages doivent aussi être distincts.
  • L’agrégation n’est pas une signature à seuil. Dans un groupe de 8 membres, l’agrégation ordinaire des signatures des membres [1, 2, 4, 6, 8] produit une signature et une liste de cinq signataires. Elle ne devient pas une signature à seuil 5-of-8 sous une seule clé publique de groupe. Un véritable système threshold BLS requiert une génération distribuée de clés ou un dealer de confiance, des indices de parts et des règles d’interpolation ; ses hypothèses de confiance et de défaillance doivent être auditées séparément.

Risques

  • Utiliser une courbe, une orientation de groupes ou une suite cryptographique différente de celle du protocole.
  • Signer des octets sérialisés différents malgré l’affichage du même message lisible.
  • Omettre le domaine du fork, de l’opération ou de l’application et permettre un replay entre contextes.
  • Considérer un Internet-Draft expiré comme une norme définitive et immuable.
  • Accepter des encodages de points mal formés, non canoniques ou à l’infini.
  • Omettre les contrôles de sous-groupe et accepter des entrées invalid-curve ou small-subgroup.
  • Employer un code hash-to-curve improvisé plutôt que la suite et les vecteurs de test prescrits.
  • Générer des clés secrètes biaisées, nulles, dupliquées, divulguées ou dérivées de manière prévisible.
  • Réutiliser une clé entre des protocoles dont les hypothèses de proof of possession et de domaine diffèrent.
  • Agréger des clés publiques non enregistrées sans la défense contre les clés malveillantes requise par le schéma.
  • Appeler la vérification rapide d’un même message pour des messages distincts ou des racines incohérentes.
  • Permuter, dupliquer ou omettre l’association entre clé publique et message.
  • Faire confiance à une bitlist de participants sans vérifier l’appartenance au comité et l’unicité des indices.
  • Compter les signatures plutôt que le stake, le poids ou le seuil défini par le protocole.
  • Supposer qu’un agrégat révèle quelle signature individuelle était invalide.
  • Confondre agrégation ordinaire, multisignatures et signatures à seuil.
  • Assimiler la validité d’une signature à une preuve de disponibilité des données, de correction de l’exécution ou de finalité.
  • Ignorer l’équivoque, les messages passibles de slashing, les fenêtres temporelles ou le contexte du fork choice.
  • Dépendre d’une seule bibliothèque, fonctionnalité du processeur ou optimisation non vérifiée de validation par lots.
  • Sous-estimer le coût des couplages, les entrées de déni de service, les canaux auxiliaires, la garde des clés, les mises à niveau et l’absence de sécurité post-quantique.

Idées reçues

  • Une signature agrégée prouve que tous les validateurs ont participé.
  • N’importe quelles clés publiques et signatures BLS peuvent être combinées sans risque en l’absence de règles de proof of possession.
  • L’agrégation de taille constante supprime la nécessité de transmettre ou de reconstituer l’appartenance des signataires.
  • L’agrégation BLS et threshold BLS sont une même construction.
  • Une signature BLS valide rend le bloc, le message de bridge ou le protocole signé économiquement sûr et définitif.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...