Ein wesentlicher technologischer Eckpfeiler Bitcoins ist der Hash Algorithmus. Er wird zum einen genutzt um die Integrität der gespeicherten Daten in der Blockchain zu sichern (mittels SHA-256) nund zum anderen werden damit die relativ langen öffentlichen Schlüssel in, für Menschen, leichter lesbare Bitcoin Adressen umgewandelt (mittels RIPEMD-160). Ein paar Grundlagen zu diesem Thema finden sich hier.
Eine – rechte simple – Hash Funktion ist die Quersumme einer Zahl. Die Quersumme der Zahl 42589 zum Beispiel ist 28 (4+2+5+8+9=28). Ändert man nun eine Ziffer der Zahl, ändert sich damit auch die Quersumme. Ändert man die Zahl an der Einerstelle auf 42582 hat man eine Quersumme von 21. Will man nun jemand eine Botschaft übermitteln, zum Beispiel eine Zahlungsanweisung oder vielleicht eine Kontonummer kann man neben der Botschaft dem Empfänger auch die Quersumme dieser Botschaft senden. Der Empfänger kann dann aus der Botschaft die Quersumme bilden und prüfen ob sie mit der ihm bereits übermittelten übereinstimmt. Ist dies der Fall, kann der Empfänger davon ausgehen, dass die Botschaft nicht beschädigt bzw. verändert wurde. Deshalb nennt man so eine Quersumme auch gerne mal Prüfsumme.
Diese einfache Hash Funktion ist allerdings nicht besonders tauglich für den täglichen Gebraucht. Wenn man eine Zahlendreher macht (was bei langen Kontonummern zum Beispiel leicht der Fall sein kann), ändert das nichts an der Prüfsumme. Sowohl für 42589 als auch für 45289 wäre die Quersumme 28. Diese Funktion ist also nicht kollissionssicher. Es gibt mehrere mögliche Zahlen, welche dieselbe Prüfsumme aufweisen können. Dies würde es ermöglichen, trotz sicher und korrekt übermittelter Prüfsumme, eine Botschaft zu verändern die zur Prüfsumme passt.
Um dies zu verhindern, verwendet man in der Kryptologie aufwendigere Algorithmen als die, oben verwendete, Quersumme. Bitcoin nutzt für die Integrität der Daten den SHA256 Algorithmus und RIPEMD-160 zum Erstellen von leicht lesbaren Bitcoin Adressen. Diese kryptologischen Hash Algorithmen sind kollissionssicher. Kollissionssicherheit bedeutet, dass man davon ausgegangen kann, dass es zu einem generierten Hashwert auch nur eine passende Botschaft gibt.
Wie genau dies funktioniert will ich an dieser Stelle nicht erklären, da es hier relativ tief in die Mathematik geht – es ist aber auch nicht notwendig. Wichtig ist, zu merken, dass es praktisch unmöglich ist, eine Botschaft so zu verändern, dass sie – trotz der Änderung – denselben Hashwert liefert wie die ursprüngliche Nachricht. Damit ist sichergestellt, dass jeder der den ursprünglichen Hashwert kennt, selbst die Integrität der Botschaft prüfen kann: Er muss nur den Hash aus der Botschaft generieren und prüfen ob er mit dem zuvor bekannten Hash übereinstimmt. Diese Technik wird auch dazu benutzt, um die Integrität von konventionellen Datenbanken sicher zu stellen. Oder auch um die korrekte Übertragung von Dateien zu gewährleisten. Beim Download von Dateien finden sich oft Prüfsummen (zumeist MD5) neben dem Link zu einer Datei. Nach dem Download ist man damit in der Lage zu prüfen ob die erhaltene Datei auch exakt jene ist, die zum Download angeboten wurde, und nicht etwa fehlerhaft geladen – oder schlimmer – böswillig manipuliert wurde.
Nehmen wir an wir wollen die (sehr kurze) Botschaft “Warte, nicht hängen!” übertragen. Die Botschaft könnte natürlich viel länger sein, aber sie ist immerhin wichtig. Und zwar so wichtig, dass wir sicher sein wollen, dass sie unverändert beim Empfänger ankommt. Schließlich wäre schon eine kleine Änderung am Text katastrophal in ihrer Wirkung. Ändert man nur die Position des Satzzeichens, bleibt zwar die Länge des Textes exakt gleich aber seine Bedeutung kehrt sich um: “Warte nicht, hängen!”.
Wir stellen also dem Empfänger der Botschaft auch noch den Hashwert (SHA256)unserer Botschaft “Warte, nicht hängen!” zur Verfügung:
4576c93df27f1eb67c01bc0d8b6229e5a332d44a584d018a240058c9a3b53923
Nach Erhalt der Botschaft kann der Empfänger ebenfalls den Hashwert aus der Nachricht bilden und diesen mit unserem Hashwert vergleichen. Sind beide identisch kann er sich sicher sein, dass der Inhalt der Nachricht beim Transport nicht verändert wurde. Hätte nun ein bösert Wicht die Nachricht in “Warte nicht, hängen!” geändert erhielte der Empfänger den Hash:
aae5a88b50e1e981af933f91279777483b3edfcc082f9c46a9fea00bcbd7ef33
und wüsste damit, dass dem Inhalt der Nachricht nicht zu trauen ist.