PP pki type

Tout protocole qui signe quelque chose doit nommer l'algorithme, et le nommer dans un champ que l'expéditeur contrôle est le point de départ des attaques par rétrogradation. BIP70 proposait trois valeurs, dont l'une était considérée comme faible depuis des années avant la rédaction de la spécification. Les navigateurs ont achevé d'écarter les certificats SHA-1 en janvier 2017, et le protocole de paiement n'a jamais publié de mise à jour.

Comment cela fonctionne

Statut : historique. PP pki type était le champ 2 de PaymentRequest, avec pour valeur par défaut la chaîne "none", et il est absent de Bitcoin Core depuis la version 0.20.0 du 3 juin 2020.

Trois valeurs étaient définies et aucune quatrième n'a jamais été enregistrée, bien que la spécification ait laissé la place pour une.

"none" désignait une demande non signée. Le champ du certificat restait vide, le champ de la signature restait vide, et un portefeuille pouvait afficher le montant et la destination mais aucune identité. La plupart des demandes en circulation étaient exactement de ce type.

"x509+sha256" signifiait que le commerçant sérialisait tout le message avec le champ de signature laissé vide, hachait le résultat avec SHA-256, et signait ce hachage avec la clé privée du premier certificat de la chaîne jointe.

"x509+sha1" signifiait la même procédure avec SHA-1 à la place de SHA-256.

Proposer l'option faible est la partie intéressante. Un vérificateur qui honore l'algorithme nommé par l'expéditeur n'est pas plus solide que le pire algorithme qu'il accepte encore, et c'est pourquoi les conceptions ultérieures fixent l'ensemble acceptable du côté du vérificateur au lieu de le lire dans le message. SHA-1 était un mauvais candidat même en 2013. Une attaque par collision plus rapide que la force brute a été publiée en 2005, et le NIST a interdit SHA-1 pour générer de nouvelles signatures numériques après 2013. Les autorités de certification ont cessé d'émettre des certificats SHA-1 à la fin de 2015, Chrome 56 a cessé de leur faire confiance en janvier 2017, et une collision publique complète a suivi un mois plus tard.

Où le rencontrer

Bitcoin lui-même fournit le contre-exemple d'un algorithme de signature nommé par l'expéditeur, et il vaut la peine de s'en souvenir.

Une transaction bitcoin ne négocie jamais son algorithme de signature avec celui qui la valide. La sortie dépensée tranche la question : une sortie antérieure à Taproot est vérifiée avec ECDSA sur secp256k1, et une sortie payant une clé Taproot est vérifiée avec Schnorr selon le BIP340, une règle activée au bloc 709 632 en novembre 2021. Celui qui dépense ne peut pas proposer quelque chose de moins coûteux à casser, car le choix a été fixé au moment où les bitcoins ont été reçus.

Cette différence explique pourquoi une couche fondée sur des certificats s'intégrait si mal au bitcoin. Les règles de consensus s'appliquent identiquement à tous et ne changent que par mise à niveau coordonnée, tandis qu'un champ nommant un algorithme est une négociation, et les négociations sont rétrogradées.

Si vous choisissez où acheter plutôt que d'écrire un logiciel, la version utile est étroite mais réelle. Une plateforme qui maintient en vie une option cryptographique obsolète "pour la compatibilité" vous dit comment elle pèse la commodité face à la sécurité, et ce jugement s'applique aussi aux parties du système que vous ne pouvez pas inspecter.

PP pki type vs SSL signature

PP pki type nommait un schéma ; la signature SSL était le résultat de son exécution. Traiter les deux comme une seule chose rend confuse l'ancienne documentation BIP70, car une demande pouvait nommer un type et ne porter aucune signature, ce qui est précisément ce que signifiait "none". Le TLS moderne conserve le même appariement, avec un identifiant d'algorithme enregistré à côté des octets de signature, mais un client n'accepte plus tous les identifiants autrefois légitimes.