PP pki type

Jedes Protokoll, das etwas signiert, muss den Algorithmus benennen, und ihn in einem Feld zu benennen, das der Absender steuert, ist der Anfang von Downgrade-Angriffen. BIP70 bot drei Werte an, von denen einer schon Jahre vor dem Verfassen der Spezifikation als schwach galt. Browser entfernten SHA-1-Zertifikate bis Januar 2017 vollständig, und das Zahlungsprotokoll veröffentlichte nie eine Aktualisierung.

So funktioniert es

Status: historisch. PP pki type war Feld 2 von PaymentRequest, standardmäßig mit der Zeichenkette "none", und es fehlt in Bitcoin Core seit Version 0.20.0 vom 3. Juni 2020.

Drei Werte waren definiert, und ein vierter wurde nie registriert, obwohl die Spezifikation Raum dafür ließ.

"none" bedeutete eine unsignierte Anforderung. Das Zertifikatsfeld blieb leer, das Signaturfeld blieb leer, und eine Wallet konnte den Betrag und das Ziel anzeigen, aber keinerlei Identität. Die meisten Anforderungen in freier Wildbahn waren genau das.

"x509+sha256" bedeutete, dass der Händler die gesamte Nachricht mit leerem Signaturfeld serialisierte, das Ergebnis mit SHA-256 hashte und diesen Hash mit dem privaten Schlüssel signierte, der zum ersten Zertifikat in der beigefügten Kette gehörte.

"x509+sha1" bedeutete dasselbe Verfahren mit SHA-1 anstelle von SHA-256.

Die schwache Option anzubieten ist das Interessante. Eine Prüfstelle, die jeden vom Absender benannten Algorithmus akzeptiert, ist nur so stark wie der schlechteste Algorithmus, den sie noch akzeptiert, weshalb spätere Designs die akzeptable Menge auf der prüfenden Seite festlegen, statt sie aus der Nachricht abzulesen. SHA-1 war selbst 2013 ein schlechter Kandidat. 2005 wurde ein Kollisionsangriff veröffentlicht, der schneller als Brute Force ist, und NIST verbot SHA-1 für die Erzeugung neuer digitaler Signaturen nach 2013. Zertifizierungsstellen stellten Ende 2015 die Ausstellung von SHA-1-Zertifikaten ein, Chrome 56 vertraute ihnen ab Januar 2017 nicht mehr, und einen Monat später folgte eine vollständige öffentliche Kollision.

Wo es auftaucht

Bitcoin selbst liefert das Gegenbeispiel zu einem vom Absender benannten Signaturalgorithmus, und es lohnt sich, daran festzuhalten.

Eine Bitcoin-Transaktion verhandelt ihren Signaturalgorithmus nie mit demjenigen, der sie validiert. Die ausgegebene Ausgabe entscheidet die Frage: Eine Ausgabe vor Taproot wird mit ECDSA über secp256k1 geprüft, und eine Ausgabe, die auf einen Taproot-Schlüssel zahlt, wird mit Schnorr nach BIP340 geprüft, eine Regel, die bei Block 709.632 im November 2021 aktiviert wurde. Der Ausgebende kann nichts vorschlagen, was billiger zu brechen wäre, weil die Wahl bei Erhalt der Coins festgelegt wurde.

Dieser Unterschied erklärt, warum eine zertifikatbasierte Schicht so schlecht auf Bitcoin passte. Konsensregeln gelten für alle gleichermaßen und ändern sich nur durch ein koordiniertes Upgrade, während ein Feld, das einen Algorithmus benennt, eine Verhandlung ist, und Verhandlungen werden herabgestuft.

Wenn Sie wählen, wo Sie kaufen, statt Software zu schreiben, ist die nützliche Version eng, aber real. Eine Plattform, die eine veraltete kryptografische Option „aus Gründen der Kompatibilität“ am Leben hält, sagt Ihnen damit, wie sie Bequemlichkeit gegen Sicherheit abwägt, und dieses Urteil gilt auch für die Teile des Systems, die Sie nicht prüfen können.

PP pki type vs. SSL-Signatur

PP pki type benannte ein Schema; die SSL-Signatur war das Ergebnis seiner Ausführung. Behandelt man beides als eines, wird alte BIP70-Dokumentation verwirrend, denn eine Anforderung konnte einen Typ benennen und überhaupt keine Signatur tragen, was genau das war, was "none" bedeutete. Modernes TLS behält dieselbe Paarung bei, mit einer Algorithmuskennung neben den Signaturbytes, aber ein Client akzeptiert nicht mehr jede Kennung, die einst zulässig war.