Bitcoin begreifen

Angenommen eine neue Mitarbeiterin hat gerade in der Firma angefangen. Ihr Name ist Faiza. Die Firma möchte ihr 100 CT als Willkommensgeschenk senden. Wie kann die Firma die 100 CT an Faiza schicken?

Zuerst braucht die Firma den public Key des Empfängers–Faiza. Faiza hat noch nie Cookie Tokens benutzt, also muss sie ein neues Schlüsselpaar generieren und den public Key dem Sender–der Firma–geben, wie Abbildung 5 zeigt.

Faiza erzeugt einen private und einen public Key, wobei sie dem selben Prozess folgt wie in [improving-cookie-token-security], aber sie gibt ihren public Key nicht Lisa. Jetzt wo Lisa nicht mehr die Tabelle mit Namen und public Keys pflegt, hat es keinen Sinn, ihr den public Key zu geben. Sie braucht ihn nicht. Stattdessen gibt Faiza den public Key der Partei, die ihr Cookie Tokens schicken will–der Firma.

Die Firma erzeugt eine Nachricht, in der sie Lisa bittet, 100 CT von 037e944a…36de9496 an 029a726c…ad8f436d zu senden. Dann signiert sie diese Nachricht digital und schickt sie an Lisa. Lisa benutzt

um sicherzustellen, dass die Nachricht mit dem private Key, der zu dem public Key des Senders gehört, signiert wurde. Sie verifiziert ebenfalls, dass im Spreadsheet auf dem public Key des Senders ausreichend Guthaben vorhanden ist. Sie tut dies auf die gleiche Weise, wie sie es tat, als im Spreadsheet noch Namen standen–sie sucht nach dem public Key des Senders und berechnet den Kontostand.

Lisa hat den public Key des Empfängers vorher noch nie gesehen, aber das ist ihr egal. Ihr geht es nur darum, dass der Sender genug Geld zum Ausgeben hat, und dass die Nachricht korrekt signiert wurde. Sie trägt in die Empfängerspalte des Spreadsheets ein, was immer in der Nachricht stand.

Faiza entdeckt eine neue Zeile mit ihrem public Key in der An: Spalte. Das gibt ihr ein warmes, gutes Gefühl. Jetzt kann sie ihre Cookie Tokens benutzen, wie sie will. Faiza musste Lisa nicht mit ihrem public Key behelligen, was Lisa einiges an Arbeit erspart hat.

Sammeln wir einmal auf, was bisher passiert ist:

Diese Änderungen haben die Privacy verbessert und Lisa die Arbeit vereinfacht. Am Ende dieses Kapitels werden wir mehr darüber diskutieren, wie wir die Privacy weiter verbessern können.

Die Mail an Lisa in diesem Beispiel gibt gegenüber Lisa preis, wer der Sender ist (die Firma in diesem Fall), weil deren Absenderadresse im Von: Feld der Mail steht. Für den Moment können wir annehmen, dass Lisa diese persönliche Information weder ausnutzt noch preisgibt. Wir benutzen Mail in diesen Beispielen anstelle des Bitcoin Peer-to-Peer Netzwerks. Das Bitcoin Netzwerk, eingehender besprochen in [ch08], benutzt keinerlei persönliche Information.

Bitte denk einen Moment darüber nach, was die Acme Versicherung jetzt noch aus dem Spreadsheet herauslesen kann. Welche Information kann sie herausbekommen, wenn sie den Namen von Sender oder Empfänger einer Zahlung herausbekommt? Sie wird in der Lage sein, alle Zahlungen herauszubekommen, die diese Person getätigt hat.

Einige Entwickler unter den Kollegen glauben, sie können die 33 Byte public Keys durch etwas kürzeres ersetzen und trotzdem ausreichende Sicherheit beibehalten. Sie schlagen vor, jeden public Key im Cookie Token Spreadsheet durch einen kryptografischen Hash des public Key zu ersetzen. Das kürzt Sender und Empfänger im Spreadsheet ab, schützt aber das Geld der Benutzer im Falle eines Fehlers in der public Key Ableitungsfunktion, wie wir später sehen werden. Das Hashen geschieht nicht mittels einer einzelnen kryptografische Hashfunktion, sondern mit zwei verschiedenen, wie Abbildung 6 illustriert. Wir diskutieren den Grund für die Benutzung zweier Hashfunktionen im nächsten Abschnitt.

Der public Key wird zunächst mit SHA256 gehasht, womit du aus dem letzten Kapitel schon vertraut sein müsstest. Der Output dieser kryptografischen Hashfunktion wird dann mit RIPEMD160 gehasht, einer anderen kryptografischen Hashfunktion, die als Output eine 160 Bit (20 Byte) lange Zahl erzeugt. Wir nennen diesen letzten Hash den public Key Hash (PKH). Alle public Key im Spreadsheet werden durch ihre jeweiligen PKHs ersetzt.

Die Zahlung unterscheidet sich jetzt von der, bei der Faiza 100 CT von der Firma erhalten hatte. Angenommen John möchte einen Keks kaufen (Abbildung 7).

Erstens wird die Nachricht an Lisa etwas abgewandelt. John muss den PKH des Cafés–was früher der public Key war–als Empfänger verwenden. Der Sender ist immer noch ein public Key in der Nachricht, da der public Key zur Verifikation der Signatur benötigt wird. Lisa merkt sich ja nicht mehr die public Keys der Kollegen.

Zweitens, weil das Spreadsheet jetzt PKHs enthält, muss Lisa den PKH des Senders aus dem public Key des Senders ausrechnen, um den Kontostand des Senders zu berechnen und um in der Lage zu sein, die Zahlung in das Spreadsheet einzutragen.

RIPEMD160 als letzten kryptografischen Hash zu benutzen ist eine bewusste Wahl, damit die PKHs möglichst kurz werden. Vergleiche doch einmal die Outputs von SHA256 und RIPEMD160:

Es ist ein gut balancierter Tradeoff zwischen Sicherheit und Grösse.

Aber weshalb zwei verschiedene kryptografische Hashfunktionen? Wir wissen nicht genau, warum dieses Schema für Bitcoin ausgesucht wurde, weil sein Erfinder, Satoshi Nakamoto, aufgehört hat, mit der Bitcoin Community zu kommunizieren. Wir können nur spekulieren. Diskutieren wir stattdessen lieber die Eigenschaften dieses Verfahrens.

Wenn eine der Hashfunktionen sich als nicht Pre-Image resistent herausstellen würde, wäre es die andere immer noch. Wenn man also einen Input für RIPEMD160 berechnen könnte, der einen bestimmten PKH Output ergibt, dann müsste man immer noch eine Pre-Image Attacke gegen SHA256 (mit ungefähr 2²⁵⁵ mal raten) ausführen, um den public Key zu finden. Ebenso müsste man, wenn man einen Input für SHA256 finden könnte, der einen bestimmten Output erzeugt, immer noch erst eine Pre-Image Attacke auf RIPEMD160 ausführen, bevor man das Ergebnis zur Berechnung des public Keys hernehmen kann.

Sollte sich andererseits herausstellen, dass die Outputmenge einer der kryptografischen Hashfunktionen kleiner ist als angenommen, dann leidet darunter die Sicherheit der gesamten Hashfunktionen-Kette. Um das klarer zu machen, nimm an, SHA256 hätte nur 100 mögliche Output Werte. man kann dann Geld stehlen, indem man verschiedene zufällige private Keys ausprobiert und die korrespondierenden PKHs ausrechnet. Wenn ein PKH mit dem Zielwert übereinstimmt, dann hättest du einen private Key gefunden, mit dem du Geld stehlen könntest. Im Durchschnitt müsstest du nur 50 private Keys ausprobieren, um von einem PKH zu stehlen. Diese Eigenschaft verbindet das Schlechteste beider Welten: Wenn eine der beiden Funktionen Schwächen hat, dann ist die gesamte Kette geschwächt. Die Wahrscheinlichkeit, dass eine der Funktionen eine solche Schwäche hat, ist gering. Wenn es eine solche Schwäche wirklich gibt, dann ist die Verringerung der Outputmenge wahrscheinlich nicht signifikant genug, um die Sicherheit in der Praxis zu beeinträchtigen. Denke dran, dass wir immer noch keine einzige Kollision in irgendeiner dieser kryptografischen Hashfunktionen gefunden haben.

Es gibt ausserdem noch zu bedenken, dass unterschiedliche Organisationen die beiden kryptografischen Hashfunktionen entwickelt haben. RIPEMD160 wurde an einer Europäischen Universität in offener Kollaboration mit einer grossen Gemeinde von Kryptografen entwickelt. SHA256 wurde von der US National Security Agency (NSA) entwickelt. Beide werden als sicher betrachtet, und beide unterzogen sich genauesten Prüfungen durch eine grosse Menge Leute.

Jetzt, wo wir die Sicherheit des Cookie Token Spreadsheets verbessert haben, lass uns erneut über Sicherheit nachdenken. Hat es die Privacy verbessert? Ist es schwieriger für die Acme Versicherung geworden, Information darüber herauszufinden, wer wen bezahlt im Vergleich zu der Zeit, wo wir public Keys im Spreadsheet benutzt haben?

Die Antwort lautet Nein. Es gibt praktisch eine eins-zu-eins Beziehung zwischen public Keys und PKHs. PKHs zu benutzen verhüllt nicht zusätzlich persönliche Informationen gegenüber der Verwendung von public Keys.

Die sicherheitsorientierten Leute unter den Kollegen diskutieren das Problem mit den Tippfehlern und lassen sich die Idee mit Cookie Token Adressen einfallen. Eine Cookie Token Adresse ist ein PKH, der codiert wird, um Tippfehler zu bemerken. Der PKH kann zwischen dieser Codierung und dem einfachen Textformat hin und zurück konvertiert werden.

Angenommen Faiza tut John leid, und sie möchte ihm 20 CT von ihren 100 CT geben, um seinen Schmerz zu lindern. Sie möchte nicht denselben Fehler wie John begehen, also bittet sie ihn um seine Cookie Token Adresse. John erzeugt diese, indem er seinen PKH mit einer Funktion namens base58check codiert (Abbildung 10).

Das Resultat ist Johns Cookie Token Adresse: 19g6oo8f…gCenRBPD. John reicht diese Adresse Faiza, die dann die Zahlung anhand des Prozesses in Abbildung 11 durchführt.

Der Zahlungsprozess ändert sich für den Sender, aber für Lisa ändert sich nichts. Faiza base58check–decodiert Johns Adresse in einen PKH. Dieses Decodieren stellt sicher, dass keine Tippfehler in der Adresse gemacht worden waren.

Wie zuvor erwähnt, kann ein PKH von und zu einer Adresse konvertiert werden. Es ist keine Einwegfunktion. Es sind lediglich zwei verschiedene Arten, den PKH zu repräsentieren, entweder als eine Serie von Bytes oder als eine Adresse (Abbildung 12).

Die Mail an Lisa ist genau dieselbe wie bisher. Nur Benutzer verwenden die Cookie Token Adresse. Sie gehört keineswegs zu Lisas Validierungsprozess oder zum Spreadsheet.

Die Kozepttabelle (Tabelle 1) hat sich in diesem Kapitel nicht verändert. Cookie Token Adressen sind exakt das, was Bitcoin benutzt, also haben wir keine Konzepte eingeführt, die von Bitcoin abweichen.

Dank PKH und Cookie Token Adressen kann Lisa ihre Tabelle von public Key loswerden. Wir nehmen PKH und Adressen in unseren Werkzeugkasten mit auf und geben Version 3.0 des Cookie Token Systems frei (Tabelle 2).