Zum Inhalt springen

Zusammenfassung des Themenkomplex PrivateKey/Adresse/Paperwallet würfeln


Empfohlene Beiträge


Nen schönen Abend allerseits,

nach längerem stillen Mitlesen (HAHA!!) kommt heut mein erster coinforums-post.

Anlass ist ne Mail an nen Kumpel von mir, der die Geschichte mit dem Manuell-Seed-Erwürfeln erklärt haben wollte... Dabei bin ich ein wenig ausgeschweift, und es wurde ne Art Zusammenfassung von was ich hier im Forum in den letzten Monaten mitgenommen habe, und ich dachte mir, ich stell das mal hier rein, viele Infos sind recht verstreut, und viele Anfänger kommen immer wieder mit den gleichen Fragen...


Und vielen Dank an dieser Stelle an das ganze Forum, insbesondere @Jokin, @Axiom0815, @ChristophBergmann, @fjvbit , @ngt, @BL4uTz, @MixMax und viele viele andere, die mit viel Geduld immer wieder das gleiche gefragt werden und erzählen und die mir geholfen haben Bitcoin und diese Cryptowelt ein bischen zu verstehen. Und muss sagen, es ist witzig mit euch, dieser Wohnzimmer-Zankhaufen, ist wie Soap-schaun, manchmal... :) und eine unbezahlbare Schule!


Also, hier die Mail an meinen Kumpel, mit leichter Anpassung ans Publikum, man sehe mir ausschweifenden Schreibstil und Neigung zu Widerholungen nach...

 

Einleitendes zur Kryptographie hinter Bitcoin


Das Grundprinzip der Adressen von Bitcoin kann man vielleicht so zusammenfassen: Ich benötige eine asymmetrische Rechenenoperation, um von einer beliebigen (geheimen) Zahl P (der PrivateKey) zu einer zweiten Zahl Q zu kommen, die öffentlich sichtbar sein soll (die Adresse). Asymmetrisch bedeutet, es ist einfach von P nach Q zu rechnen, aber praktisch unmöglich von Q nach P zurückzurechnen. Des weiteren muss es möglich sein eine Art Unterschrift zu erstellen, die öffentlich beweist, dass man in Kenntniss der Zahl P ist, ohne diese selbst zu veröffentlichen. Will ich jetzt Coins die Q zugeschrieben sind wegüberweisen, veröffentliche ich meine Unterschrift (Signatur) um meine Kenntnis von P zu beweisen.

Hierfür gibt es mehrere Verfahren (RSA, DSA ...), Bitcoin benutzt den sogenannten Elliptic Curve Digital Signature Algorithm oder ECDSA. 
(https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm)

ECDSA benutzt immer eine sogenannte elliptische Kurve, mit den allgemeinen Parametern y^2=x^3+ ax + b, definiert auf einem Zahlenraum Z, einem sogenannten endlichen Körper. Auf der Kurve wird ein Punkt G(x/y) festgelegt, wobei gilt n * G(x/y) = 0. Dabei ist "*" eine spezielle Rechenoperation (modulo) in diesem Zahlenraum und n die Ordnung der Kurve. Wen die Mathe dabei interessiert kann sich mal allgemein mit der Mathematik auf endlichen Körpern befassen, insbesondere der "Multiplikativen Gruppe" und dem "diskreten Logarithmus". Der Spezialfall Bitcoin ist wird auf Englisch schön auf "https://www.coindesk.com/math-behind-bitcoin" erklärt.

Jetzt wähle ich meine beliebige Zahl P aus dem erlaubten Zahlenraum Z (mit P < n), und führe folgende Rechenoperation aus:

Q(x'/y') = P*G(x/y) wobei die Multiplikation wie gesagt eine spezielle Rechenoperation in diesem Zahlenraum Z ist. Da die Rechnung modulo erfolgt, ist es insbesondere nicht möglich P=x'/x o.ä. zu rechnen.

Das Zahlenpaar x' y', hintereinander aufgeschrieben, ist der PublicKey, die Zahl P der PrivateKey. Man kommt sofort von P nach Q, kann aber von Q aus nicht nach P zurückrechnen.

Die Kryptographie benutzt ne Reihe von ECDSA Kurven, vom NIST (das amerikanische Pedant zur PTB) zertifiziert, mit ihren jeweiligen Parametern und Eigenschaften. Weil in den Parametern a und b der Kurve liegt der Hund begraben, diese definieren die "Kurveneigenschaften", und durch geschickte Parameterwahl lassen sich evtl. mathematische Hintertüren einbauen, dies lässt sich sehr schwer bis nicht überprüfen, weil man dazu auch "zurückrechnen" müsste. 

Der Paranoiker fragt: Könnte das NIST Interesse haben, Hintertüren in weltweite Verschlüsselungsstandards einzubauen?

Die von Satoshi Nakamoto gewählte Kurve ist y^2 = x^3 + 7 (also a = 0, b = 7). Die Kurve mit den dazugehörigen Parametern nennt man secp256k1. Jedenfalls hat Nakamoto bewusst nicht die NIST Kurven genommen weil er ihnen misstraute, ne ganz simple Kurve gewählt, die leicht auf Hintertüren überprüfbar ist, und die vor ihm praktisch noch nie jemand benutzt hat aber ne Reihe von eleganten Eigenschaften bzgl. Effizienz u.a. hat, seit Bitcoin ist sie Standard in vielen Anwendungen. Ein weiteres Puzzlestück im Mysterium Nakamoto...

Aber weiter zum Bitcoin:

Das errechnete Zahlenpaar (2 mal 32 Byte) wird jetzt im Hexadecimalformat aufgeschrieben und gehasht (SHA256). 
("Hashen" ist ein Algorithmus der aus ner beliebigen Zeichenkette ne Art Fingerabdruck erstellt, eine 256 bit Zeichenkette, die voll zufällig wirkt und welcher bei Änderung nur eines Bits in der Eingabe-Zeichenkette ein vollständig anderes Ergebnis liefert. Es gibt keinerlei Möglichkeit um vom Hash auf den Dateneingang zurückzuschliessen, allerdings ist das Ergebnis für den gleichen Dateneingang immer gleich)
Da die Kurve y^2 = x^3 + 7 symmetrisch zur x-Achse ist, reicht im Prizip eine Koordinate plus Vorzeichen. Das ergibt zwei mögliche PublicKeys, einmal "uncompressed", beide Koordinaten nacheinander mit dem Byte "0x04" vorgestellt (also 65 Byte insgesamt), einmal nur eine Koordinate plus Vorzeichen-Byte (0x02 oder 0x03 vorgestellt)(33 Byte insgesamt). Der Hash des PublicKeys wird dann nochmal gehasht, mit nem anderen Algorithmus (RIPEMD160) und das Ergebnis ist dann im Prinzip die Bitcoin Adresse.

 

Zusammenfassung: PrivateKey --> BitcoinAdress
 

Private Key: Eine 256 bit Zahl, bzw. eine Zahl zwischen (00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000) und (FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141), also 32 Byte, hexadezimal dargestellt (in Blöcken a 4 Byte, jedes Byte eine Zahl zwischen 00 und FF).

Die Zahl (FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141) ist die Ordnung von G(x,y) auf der Kurve y^2=x^3+7, ne mathematische Geschichte, ne Primzahl übrigends, wie auch immer, der gewählte PrivateKey ist ne beliebige Zahl kleiner dieser.

In Dezimal ausgedrückt: 0 < P < 115.792.089.237.316.195.423.570.985.008.687.907.852.837.564.279.074.904.382.605.163.141.518.161.494.337 oder 0 < P < 1,15 *10^77

Zur Einordnung: Anzahl Atome der Erde: ca 10^49. Anzahl Atome im Universum ca 10^85.

Wenn ich jetzt ne Bitcoin Adresse generiere, passiert im Hintergrund eigentlich folgendes: Das Programm wählt einen zufälligen PrivateKey, errechnet dann die Adresse und gibt sie aus. Transaktionen die ich von dieser Adresse wegschicken will muss ich mit meinem PrivateKey signieren, damit sie gültig werden. Das macht meine Wallet für mich, in dem Moment wo ich "Bitcoins versende".

[Das bedeutet u.a. man kann Bitcoin auf jede mögliche, gültige Adresse schicken (siehe WIF, oder Wallet-Import-Format), auch wenn die Adresse nie von jemandem "generiert" wurde, und somit niemand PrivateKey (oder PublicKey) kennt, mit dem man die Adresse ausrechnen könnte und somit eine gültige Transaktion signieren könnte. So ein Bitcoin wäre dann unwiderbringlich verloren. Die Bitcoin Adresse enthält allerdings ne Prüfsumme um vor Schreibfehlern zu schützen (und wieder, siehe WIF)]

Jetzt wird deutlich, dass des Pudels Kern im ZUFÄLLIGEN Pick einer Zahl aus dem Zahlenraum bis 10^77 steckt. Die Zahl ist einfach so hoch, das es absolut ausgeschlossen ist, das jemals, in x Universen Zeitaltern, auch wenn jeder Billiarden von Adressen erstellen würde, über Milliarden von Jahren, von Milliarden von Leuten, das jemals zufällig der gleiche PrivateKey gepickt würde.(10^9*10^9*10^9*10^9 ist auch erst 10^36 und noch n Faktor 10^40 kleiner). Das muss man mal wirklich sinken lassen, und bischen drüber nachdenken, weil das der Kern ist meiner Meinung nach, um die Funktionsweise und das Sicherheitskonzept der Adressen von Bitcoin wirklich zu verstehen.

Zur Anzahl möglicher Adressen: Aus dem 32 Byte (256 Bit) PrivateKey P wird ein 33 Byte (compressed) oder 65 Byte (uncompressed) PublicKey Q. Durch SHA256 gibts nen 256 bit Hashwert. Nach dem anschliessenden RIPEMD160 hat man als Adresse eine 160 bit Zahl, also gibt es 10^48 verschiedene Adressen bei 10^77 verschiedenen PrivateKeys. Das bedeutet: Für jeden PrivateKey gibt es genau eine zugehörige Adresse, aber pro Bitcoin Adresse gibt es ~10^28 PrivateKeys. Das Problem nennt man "Kollission", die Wahrscheinlichkeit ist in der Grössenordnung kleiner 1:10^48, das zufällig zwei verschiedene PrivateKeys gepickt werden, die die gleiche Bitcoinadresse "erzeugen" und somit zum gültigen Signieren benutzt werden könnten.

Oder unterm Strich: Es gibt 10^48 verschiedene Bitcoin Adressen mit dazugehörigen 10^48 verschiedenen PrivateKeys.


Die Sache mit dem Seed, oder den 24 Wörtern
 

Mit BIP39 wurde folgende Erweiterung in Bitcoin aufgenommen: Aus einer zufälligen 256 Bit Zahl wird über eine bestimmte Vorschrift ein Baum von PrivateKeys erzeugt. Dabei sind die unterschiedlichen PrivateKeys voneinander völlig unabhängig (= statistisch gleichverteilt im Zahlenraum 0<P<n), nur mit Kenntnis der ursprünglichen 256 Bit Zahl lassen sich alle errechnen.

Das funktioniert sinngemäss irgendwie so: die 256 bit werden auf 512 bit erweitert, gehasht, die Hälfte vom Hash wieder mit der Hälfte der Ursprungskette kombiniert, gehasht, das ergibt PK 1. Dann wieder gehasht, Hälfte abgeschnitten, mim letzten gehasht, usw, dann bekommt man ne Reihe von völlig zufälligen PKs, die man durch Anwendung der Hashfunktion reproduzierbar immer wieder herstellen kann, wenn man die ursprüngliche Zeichenkette und die Erzeugungsvorschrift kennt. Gern mal unter BIP39 genauer ansehen.

Der Trick ist somit, ich brauch nur einmal ne 256 bit Zeichenkette, daraus lassen sich dann unendlich viele PrivK/PubK Paare erzeugen. Heisst ich muss mir nur einmal sone Zeichenkette merken, kann die in jede beliebige Walletsoftware eingeben, welche dieses Feature unterstützt, und hab dann direkt Zugriff auf alle abgeleiteten "Walletadressen". Da man jede Bitcoinadresse nur einmal verwenden soll, kann man immer wieder ne Neue nehmen, zB. jeden Kunden auf ner neuen Adresse bezahlen lassen etc, und braucht zum Errechnen und Prüfen aller Adressen nur einmal die 256 bit Zeichenkette.

Damit man die sich leichter merken kann, gibts den Standard mit den 24 Wörtern.

Die Erzeugungsvorschrift ist die folgende:

Man habe als Ausgangspunkt eine ZUFÄLLIGE 256 bit zahl.

Die wird unterteilt in 11-bit Blöcke, das ergibt 23*11bit + 3 bit

Aus der 256 bit Zahl wird ne 1 Byte Prüfsumme gebildet (also 8 bit) und die werden an die letzten 3 bit angehängt, dadurch bekommt man den 24ten 11-bit-Block bzw. das 24te Wort.

[zur Prüfsumme: man erstellt ne binäre Datei mit der 256 bit Zahl drin, also 32 byte Hexadecimal. Binär abspeichern, dann Datei sha256 hashen. Vom Hash ist das erste Byte die Prüfsumme]

Jetzt hat man 24 Zahlen a 11 Bit, wobei die letzte Zahl die Prüfsumme enthält.

2^11 ist 2048, also hat jede Zahl einen Wert zwischen 0 und 2047.

Zum leichteren Merken gibt Wortlisten mit 2048 Wörtern, 24 Wörter aus der Liste machen einen "Seed", womit praktisch heute alle Wallets arbeiten. Kennst du deinen Seed, kannst in jeder beliebigen Wallet Zugriff auf deine Coins bekommen (so sie denn nach BIP39 Standard arbeiten. Gibt Wallets die haben ihre eigene Erzeugungsvorschrift, den Seed kann man dann logischerweise nur in der entsprechenden Wallet benutzen). Kennt jemand deinen Seed, hat er alle ableitbaren PrivateKeys und somit Zugriff auf alle auf den zugehörigen Adressen "gespeicherten" Coins.

Wie bei der Sache mit dem PrivateKey, der Kern der Geschichte ist der ZUFÄLLIGE Pick einer 256 bit Zahl aus dem vollen Zahlenraum! Nur dann ist die Sache wirklich sicher.

Der Paranoiker könnte fragen:

- ist der Seed den mir meine Wallet beim "wallet erstellen" ausspuckt wirklich zufällig?? Oder aus nem Pool gegriffen, der dann regelmässig abgefragt wird?

- sind die zugrundeliegenden Zufallsgeneratoren wirklich zufällig? oder geht der Zahlenraum von 10^48 auf 10^20 runter, seis durch Böswill, seis durch Fehler, und ist dann langsam in Reichweite von paar Supercomputern und genügend Zeit...?

Es sei angemerkt, dass der Mensch allgemein als schlechte Zufallsquelle gilt, ein zufälliges Picken von 24 Wörtern bzw. 256 mal 1 oder 0 bzw einer 77 stelligen Zahl scheint viel zufälliger als es ist, da der Mensch wohl stark gebiast handelt. Man bedenke dass es ziemlich schwer ist einzuschätzen, ob man sich mit seinem "zufälligen" Picken von Wörtern/Zahlen wirklich gleichverteilt im vollen Zahlenraum bewegt, oder aber in einem Unterraum der nur 10^20 o.ä. gross ist und der durch geschickte Analyse (lass 1000 Menschen ne Reihe von 1en und 0en aufschreiben und schau welche Patterns auftreten) durchaus "abgrasbar" wäre.
Und man davon ausgehen dass das ständig passiert und irgendwelche Algorithmen ständig PrivateKeys erzeugen und die Adressen auf Guthaben checken. Und wer Lust hat kann sich mal die Adressen von privk= "00000...001" bzw "AAAAA..AAAA" o.ä. ausrechnen lassen, fast alle hatten schonmal Guthaben drauf, nur meistens nicht lange :) Manche erst im Jahr 2020 wo man sich doch fragt, wer ist so bescheuert auf ne Adresse zu nem derart simplen PrivateKey echte Coins zu schicken???

Würde nichtsdestotrotz sagen, das ein "zufälliger" Pick eines Menschen zumindest Bedienen-in-einem-Pool, und ähnliche Angriffe ausschliesst und jetzt auch nicht das Schlechteste ist. Und bei dem zufälligen Pick kann man sich ja selbst "zufällige" Inputs ausdenken..

Die sauberste Sache ist jedenfalls, wenn man ne wirkliche Zufallsquelle hat.

In irgendeinem von euren Posts war mal was verlinkt, da hat einer vorgerechnet, das mit die "zufälligste" Sache (also echte p=50,0%) der gleichzeitige Wurf einer ungeradzahligen Anzahl von Münzen ist (am besten noch alle unterschiedlich), wobei dann bei zB. geradzahliger Anzahl von Köpfen ne 1 gilt, bei ungeradzahliger ne 0. Da kriegste alle Einflüsse ausgebiased, auch wenn die einzelnen Münzen mit 70% Wahrscheinlichkeit auf einer Seite landen, oder korrelieren, oder sonstwas.. Je mehr Münzen umso besser, ich machs mit 7 :)

Es dauert natürlich ein bischen bis man 256 Würfe durchgeführt und aufgeschrieben hat, aber ich muss sagen, es ist ne äusserst befriedigende Angelegenheit, alleine die Tatsache dass man dem "echten Zufall" quasi bei der Arbeit zuschaut und das schöne Gefühl, dass die erworfene Zahlenkette wirklich allen Entropiekriterien genügt, voll zufällig aus dem gegebenen Zahlenraum gegriffen ist, kein elektronisches Medium gesehen hat und von nichts und niemandem erraten werden kann.

 

 

Also, jetzt die detaillierte Anleitung:



Erstellen einer Paperwallet: (also ein simples privK/adress paar)
 

- Werfen (oder irgendwie Erstellen) einer 256-stelligen Folge von 0en und 1en.

- Umwandeln der binären Zahl in ne 32 byte Hex Zahl. (Der Paranoiker lässt sich die Tabelle mit den 256 Möglichkeiten pro Byte bzw 8 Bit anzeigen und schreibt die Folge per Hand auf, nie in ein internetfähiges Gerät eingeben, zB. "https://www.elektronik-kompendium.de/sites/dig/0710081.htm")

- Öffnen von "bitadress.org" an nem offline PC

- Auf "wallet details" gehen.

- Die Hexfolge bei "privaten Schlüssel eingeben" eingeben.

Es wir ein Schlüsselpaar für "compressed" und "uncompressed" ausgegeben. In einem Fall (uncompressed) werden beim PublicKey beide Koordinaten verwenden und ein Byte "04"(HEX) vorgestellt (also 65 byte lang), im anderen wird nur eine Koordinate (x) plus ein Byte für das Vorzeichen ("02" oder "03") verwendet, das geht da die kurve y^2 = x^3+7 symmetrisch zur x-Achse ist.

Wie die Seite das endgültige Format von Privk/adress ermittelt kann man googlen (Stichwort WIF, base58)

Im Prinzip kannste das alles per Stift notieren (Privk/adress), den PC formatieren, oder verbrennen, oder einfach neu Starten, das nie irgendwo eingeben, und auf die Adresse Bitcoins schicken. Wennde die irgendwann benutzen willst, dann nen Client wie "Electrum", oder direkt "Bitcoin Core" öffnen, deinen PrivatKey importieren (sollt ein saubere Pc und ein sauberes "Electrum" sein), dann taucht dein Guthaben in der Wallet auf, und dann versenden.

Das ist aus meiner Sicht auf jeden Fall mit die sicherste Methode Bitcoins langfristig aufzubewahren.

Einziger Haken: verlier deinen PrivateKey nicht! :)


Erstellen eines Seeds:
 

- Werfen (oder irgendwie Erstellen) einer 256-stelligen Folge von 0en und 1en.

- Umwandeln der binären Zahl in ne 32 byte Hex Zahl. (Der Paranoiker lässt sich die Tabelle mit den 256 Möglichkeiten pro Byte bzw 8 Bit anzeigen und schreibt die Folge per Hand auf, nie in ein internetfähiges Gerät eingeben, zB. "https://www.elektronik-kompendium.de/sites/dig/0710081.htm")

- Erstellen einer binären Datei mit einem Hex Editor, mit der 32 byte Zeichenfolge, abspeichern.  (Natürlich alles am offline PC)

- SHA256 hashen der Datei, mit einem beliebigen, downloadbaren SHA256-Hash-Programm, man notiere sich das erste Byte des Hashes. Umwandeln in Binär. (8er folge 0en und 1en)

- Anhängen der 8 bit an die 256 bit vom Anfang, macht eine 264 bit Kette.

- Erstellen von 24 x 11 bit Zeichenfolgen und Berechnen der 24 Dezimalzahlen deren Wert zwischen 0 (00000000000) und 2047 (11111111111) sein sollte. (Der Paranoiker rechnet per Hand aus... Ausserdem wird eh zu wenig gerechnet, heutzutage)

- Jede Zahl mit 1 addieren. (weil die binären Zahlen bei "0" beginnen, die Wortliste per Definition bei "1")

- Notieren der korrespondierenden 24 Wörter (https://kryptodots.com/bip39-word-lists) englische liste!

- Eingeben der Wortliste bei "ian coleman, bip39-standalone" auf einem offline-PC und Überprüfen auf Gültigkeit, (wenn man sich nicht verrechnet hat ist er gültig) dabei werden auch die zugehörigen PrivateKeys/Adressen angezeigt. Das Ian-Coleman-Tool ist ne mächtige Sache mit der man sich eingehender befassen sollte, sehr lehrreich!!
Es ist open source, und auch der verwendete Zufallsgenerator scheint solide zu sein, falls man nicht würfeln will.
Das Tool eignet sich zum Erstellen von Seeds, aber auch zum Überprüfen eines manuell erstellten Seeds und Extrahieren der zugehörigen Adressen.

Das ´Vorgehen wäre jetzt zB folgendes: man kauft sich ne Cold-Wallet, zB die Bitbox 2.0.

Erwürfelt sich seinen seed, und beim In-betrieb-nehmen gibt man seinen erwürfelten Seed ein. Das passiert nur am Gerät, also dem Stick, NIE am pc direkt. Die Cold Wallet ist so aufgebaut, das der Seed, bzw. zugehörige PrivateKeys NIE den stick verlassen und nicht ausforschbar sind. Transaktionen werden auf dem Stick signiert und nur die signierte Transaktion verlässt den Stick und kommt auf den PC. Mit der Signatur kann jeder überprüfen ob der Signierende echt ist (also den PrivateKey kennt) ohne den PrivateKey explitit zu sehen.

Das ist der Sinn von diesen Cold Wallets. Eigentlich sollte man NIE einen Seed in irgendein Gerät eigeben, es sei denn die ColdWallet selber. Damit ist man immer safe, egal wie ausgefuchst ein Angriff wäre...

Einziger Haken: verlier deinen Seed nicht!


Eine lehrreiche Übung wäre zum Beispiel:

 

- Erwürfel dir ne Paper Wallet, komplett offline.

- Schicke nen kleinen betrag auf die Adresse (ok, die Transaktionskosten sind recht hoch, ist halt Lehrgeld, aber trotzdem ne geile Übung.)

- Schau im blockexplorer ob auf der Adresse was drauf ist

- Such dir ne gute desktop wallet, oder handy wallet die PrivateKeys importieren kann (zB Electrum)

- Importier den PrivateKey, dann musst du das Guthaben sehen, und schick die Bitcoins zurück auf deine Wallet.

Kostet zwei mal Gebühren, aber dann weist du, du kannst ne beliebige echt zufällige Adresse erzeugen, die GARANTIERT niemand kennt, egal wie paranoid man ist, du kannst BTC "drauf speichern", und wann immer du willst kannst du es wegüberweisen. Und bis zum "wegüberweisen" hat der PrivateKey nie ein elektronisches, mit dem internet verbundenes Gerät gesehen.

Genauso mit dem Seed:

- Erwürfel nen Seed

- Prüfe bei Ian Coleman seine Gültigkeit und notiere ein paar der angezeigten Adressen

- Schick nen kleinen Betrag auf eine der Adressen

- Nach Reset einer ColdWallet (oder neue Wallet) die Wallet mit dem erwürfelten Seed in Betrieb nehmen.

- Das überwiesene Guthaben muss auftauchen


Den PrivateKey (oder ne PrivateKey liste) könnte man jetzt per Veracrypt in nen Container packen, die auf 5 usb Sticks sichern und verteilen, das Passwort für den Container bei nem Notar hinterlegen, oder im Bankschliessfach, Testament o.ä., und es braucht einen der Sticks + das Passwort um an die Coins zu kommen. Naja, man kann sich vorstellen das man das beliebig verfeinern kann, jeder halt bis zu welchem grad er spinnt :)

Die gleiche Geschichte mit dem Seed.

 


Nachtrag, zum Thema PubKey, Adressen und Quantenrechner:


Zur Erinnerung: Aus einer 32 Byte zahl errechnet sich via ECDSA der 65 Byte Public Key uncompressed bzw. 33 Byte compressed, daraus SHA256, daraus RIPEMD160. Die erzeugten 160 Bit werden dann nach WIF erweitert und in base58 wird die tatsächliche Bitcoin Adresse dargestellt.

Wie erläutert ist der Hash ne Operation die keinerlei Schluss auf den Ursprung zulässt, also auch eine "assymmetrische" Operation.

Jetzt könnte man ja sagen, wofür brauchts eigentlich nen Public key, könnt ja direkt den PrivateKey hashen und als Adresse verwenden.

Der Grund ist, wie weiter oben ausgeführt, dass ich den mathematisch errechneten PublicKey brauche, um mit meinem PrivateKey eine Signatur zu erstellen, und diese öffentlich prüfen zu lassen. Das heisst, aus der Kombination (und somit durch Veröffentlichung) von PublicKey und Signatur kann bewiesen werden, das mit dem PrivateKey unterschrieben wurde, ohne das dieser selbige öffentlich bekannt wird. Das brauch ich, um öffentlich nachzuweisen das ich der Besitzer des PrivateKeys zu einer Adresse bin und das Recht habe die Coins zu versenden (Sprich, um ne gültige, vom Netzwerk akzeptierte Transaktion auszusenden).

Diesen Vorgang könnte man mit einem Hash-Wert nicht durchführen, dafür brauchts ECDSA oder nen vergleichbaren Algorithmus.

Wie bereits erwähnt ist das Sicherheitskonzept, dass es zu aufwendig ist vom PublicKey zum PrivateKey zurückzurechnen. An dieser Stelle kommt das Argument mit den Quantencomputern rein. Man kann zeigen das diese prinzipiell sone Rechnung effektiver ausführen können, und theoretisch wäre es bei nem geil funktionierenden Teil mit 2000+ QBITS (davon ist man noch Jahrzehnte weg) möglich, in endlicher zeit den PrivateKey aus dem PublicKey zu berechnen.

Es wird jedoch der PublicKey zweimal gehasht, um auf die öffentlich einsehbare Adresse zu kommen. Die Hash Operationen sind quantensicher, es ist unmöglich den Hash zurückzurechnen, auch für Quantenrechner, die einzige Möglichkeit ist brute force, also zufällige Eingaben ausprobieren und sich den Hash dann ansehen und auf nen zufälligen Treffer hoffen. Über die schiere Anzahl möglicher Hashes (also adressen), haben ich mich schon ausgeführt... Anzahl Atome auf Erde, und so weiter... Das gesamte Bitcoin Netzwerk berechnet momentan ca 2*10^20 Hashes pro Sekunde. Selbst die tausendfache Rechenleistung (!!!), eine Milliarde Jahre lang gerechnet, könnte nur 6*10^39 Hashes abchecken, also immer nur erst ca ein milliardstel der Gesamtheit aller PublicKeys ausprobieren. Und dann wäre es immer noch ein leichtes per SoftFork auf SHA512 oder SHA1024 zu wechseln.
Wie gesagt, man muss diese Zahlen mal richtig sitzen lassen, Potenzen sind so einfach aufgeschrieben, die damit beschriebenen Dimensionen nur schwer vorstellbar. 


Allerdings wird bei jeder Transaktion die übers Netz gesendet wird, der PublicKey mit der Signatur öffentlich ausgegeben.
Dies ist neben Anonymitätsüberlegungen der eigentliche Grund, warum man jede Bitcoin Adresse nur einmal verwenden sollte. Selbst im Falle eines möglichen erfolgreichen Quantenangriffes wäre der PubKey erst dann bekannt, wenn die Adresse bereits leergeräumt ist.

Also, eine Bitcoin Adresse, von der nie eine Transaktion wegging, ist 100% quantensicher.

Es gibt tatsächlich relativ viele Adressen bei denen der PublicKey bekannt ist, die aber noch unversendetes Guthaben drauf haben. Mit ein wenig gutem Willen kann man sich vorstellen, dass es kein Hexenwerk ist, im Falle sich anbahnender funktionierender Quantenrechner die Besitzer der Coins dazu zu bringen ihre Coins auf jungfräuliche Adressen zu migrieren. Überhaupt macht es Sinn, da funktionierende Quantenrechner nicht über Nacht vom Himmel fallen, sich erst bei gegebener Zeit Gedanken zu machen, wie mit der Thematik umzugehen ist. Dann weis man auch über alle dann aktuellen Bedürfnisse des BTC Netzwerks Bescheid und kann mit den zu dem jeweiligen Zeitpunkt zur Verfügung stehenden Mitteln auf diese Geschichte reagieren.

Von allen möglichen zukünftigen Problemen des Bitcoin Netzwerkes (zB. der zur Sicherheit des Netzwerkes zwingend notwendige, immense Energieverbrauch in Zeiten einer sich anbahnenden Klimakatastrophe) spielt das Problem der Quantenrechner bestimmt keine Rolle, da voll verstanden, Lösung bei richtiger Anwendung bereits implementiert, und mit mehr als reichlich Vorlaufzeit um sich darum zu kümmern. (Wie gesagt, ein simples Migrieren allen Guthabens von Adressen mit bekanntem PubKey auf neue Adressen würde reichen).

Wenn also jemand immer noch den Quantenrechner-Teufel an die Wand malt um Bitcoin tot zu reden, kann man ihm mindestens nahelegen sich besser mit der Materie auseinanderzusetzen, maximal durchaus FUD, Böswilligkeit oder komplette Ignoranz unterstellen.


Soviel dazu, wünsche viel Spass beim Seeds und PaperWallets erwürfeln, Coins rumschieben, und Stichworte nachgoogeln.

Ich finde jeder BTC Hodler sollte sich die Zeit nehmen diese Spielchen mal durchzuspielen und sich in diesem Zuge intensiv mit den Grundlagen und dem Sicherheitskonzept dieses neuen, faszinierenden Geldes auseinandersetzen.


der mahatma

bc1q0wfda8vllnyf9yf494nzwzmlfwpm5lt5mr77rs

  • Love it 1
  • Thanks 5
  • Like 4
Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 3 Wochen später...
vor 14 Stunden schrieb Cricktor:

Interessanter Post zum Thema böswillig verschleierte Priv. Key-Generierung: https://bitcointalk.org/index.php?topic=2488493.0

Es gibt ja nichts, was es nicht gibt...

 

Danke @Cricktor für den Post!

Genau deswegen ist es essenziell sich seine PrivateKeys bzw. Seeds selber zu erstellen!! Es muss eine 256bit Zahl ZUFÄLLIG aus dem vollen Zahlenraum gewählt werden, sonst greift das Sicherheitskonzept der Adressgenerierung von Bitcoin nicht!!

Am besten KEINER Software das selbstständige Erstellen von Einzahlungsadressen erlauben (mit Ausnahme vielleicht von bitcoin core)!

 

  • Up 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 2 Stunden schrieb Janbtc:

Wie begründest Du das?

??? Wie begründe ich was? Das Bitcoin Core OK ist? Oder das man keiner Software das Erstellen des PrivateKeys erlauben soll?

Hast du den Einganspost gelesen? und die ersten paar Posts im Link? Wenn ja, dann formuliere was du nicht verstanden hast und ich geh gern drauf ein... 

vor 2 Stunden schrieb Janbtc:

Welche Software meinst Du genau?

JEDE ausser Bitcoin Core.

Um Missverständnisse zu vermeiden: Wenn die Wallet auf einem BIP39 Seed basiert (und dieser zufällig gewählt wurde) kann man sich natürlich Einzahladressen von der Software generieren lassen, da die dann nicht-zufällig, deterministisch von dem zufälligen Seed abhängen.

Problematisch ist, wenn die Walletsoftware selbstständig den PrivateKey auswählt und daraus die Adresse generiert wird. Weil man nie ganz sicher sein kann, WIE GENAU der PrivateKey ausgewählt wird.

  • Like 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 10 Stunden schrieb mahatma:

Danke @Cricktor für den Post!

Genau deswegen ist es essenziell sich seine PrivateKeys bzw. Seeds selber zu erstellen!! Es muss eine 256bit Zahl ZUFÄLLIG aus dem vollen Zahlenraum gewählt werden, sonst greift das Sicherheitskonzept der Adressgenerierung von Bitcoin nicht!!

Am besten KEINER Software das selbstständige Erstellen von Einzahlungsadressen erlauben (mit Ausnahme vielleicht von bitcoin core)!

Gern geschehen. Mir ist beim Lesen der Analyse des anonymen Schreibers in dem bitcointalk.org-Thread ja echt die Kinnlade runtergeklappt und erstmal unten geblieben. Auf was für Ideen die Leute so kommen, wirklich faszinierend. Meine pers. Einschätzung ist, daß dies wirklich ein clever böswilliger Weg irgendeiner Wallet ist, um für die dahinter stehenden Gauner quasi deterministische Priv.Keys zum Ausräumen bei Gelegenheit zu geben. Private Keys aus Hashes von erratbaren Daten zu generieren, ob gewollt oder erzwungen/verschleiert, ist ein Spiel mit dem Feuer und wie sich zeigt, findet sich schon jemand, der dem Schema auf die Schliche kommt. Es scheint ja keine hieb- und stichfesten Beweise zu geben, welche Wallet nun tatsächlich für diese zahlreichen Pseudo-Private-Keys verantwortlich ist. Etwas reichlich blauäugig finde ich ja, wie man dem "Nein, nicht unser Problem" vom Support von blockchain.info (oder blockchain.com) blind vertraut. Ich habe jetzt keinen Grund, die schlecht zu machen, aber wer glaubt denn ernsthaft, der Support würde da irgendetwas zugeben, falls sie in ihrem System so eine Hintertür finden würden. Den Gesichtsverlust inkl. Schadensersatzforderungen wird sich keiner ans Bein binden wollen. Im besten Fall wird das heimlich repariert. Jeder Gauner soll von mir aus in der Hölle verkommen, aber diese Hintertür ist beeindruckend clever.

@mahatma würde ich nicht vollständig zustimmen, das ist mir etwas zu absolutistisch. Ich würde Software vertrauen, die Open Source ist und wo man ggf. nachsehen kann, ob deren Pfade zur Schlüsselgenerierung "sauber" sind.

vor 8 Stunden schrieb Janbtc:

Warum ist Bitcoin Core 0.21.0 sicherer als z. B. Electrum-4.1.2 von electrum.org ?

Da dürfte kein Unterschied bestehen, beide geben sich Mühe, "guten" Zufall mit ausreichend Entropie zu nutzen. Wegen der Popularität und des Alters der Software dürfte dieser wichtige Teil davon einigermaßen ausgereift und von genug Augen betrachtet und geprüft worden sein.

Ein ganz anderer Punkt ist, wieviele Cryptocoin-User haben auch nur ungefähr eine Ahnung, welche Bedeutung und Wichtigkeit die, ich nenne es mal korrekte Schlüsselgenerierung hat (zufällig, nicht erratbar, vertraulich, nicht auf einem deterministischen Verfahren basierend (für den Seed, ich meine hier nicht die aus dem Seed deterministisch abgeleiteten Keys)). Warum vertraue ich der Software oder Hardware, daß sie genau alle Punkte einhält?

Bearbeitet von Cricktor
  • Like 2
Link zu diesem Kommentar
Auf anderen Seiten teilen

Danke für diesen umfangreichen und fundierten Beitrag.

Das gibt sicherlich Anfängern etwas zu denken um die Risiken zu verstehen.

Man glaubt ja nicht wie viele unbedarfte Leute sich irgendwo online eine Wallet erstellen und da munter Geld hin schicken.

Und dann verstehen sie nicht wenn es plötzlich weg ist.    LOL

Der Link auf  bitcointalk ist auch sehr interessant.

Den Thread habe ich jetzt komplett gelesen und das gibt mir schon zu denken.

Wenn mich ein Kollege zum Code-Review einladen würde in einem Projekt das nur so von SHA256 wimmelt dann bin ich nicht mehr sicher den Zweck eines weiteren Aufrufs wirklich zu erkennen. Wenn dann noch ein netter Kommentar mit einer falschen Erklärung dran steht könnte das durchaus durch gehen.   :(

  • Thanks 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Beispiel für das berechnen des 24. Wort (Checksumme) bei einem gewürfeltem Seed:
Hilfsmittel: Ein Vordruck von hier.

 

Zitat

Beispiel-Seed: 
mushroom velvet protect dry license antique yellow engine aerobic shoe health during clock helmet fossil obvious supply gesture decline fade below amount vivid taxi

Passendes Bild von iancoleman:
https://ibb.co/bgMdgQZ



Berechnung passend zu diesem Beispiel-Seed: 
 

  1. Eine Zufallszahl mit 256 Stellen könnte so aussehen (zb: gewürfelt oder mit Münze): 1001000111011110010000101011001010100001110110000001001000010011111111111100001001010011000001000011100011001101101010001010001000010010101101101101010111010110111111001100010111011001110011000010110011100011101010001110000101001100000100000011110101001110
    (was beim Beispiel-Seed dem «Raw Binary» in iancoleman entspricht, ...einfach unter «Show entropy details» im Feld «Entropy» eingeben)

    Diese binäre Zahl, wird ins hexadezimale Zahlenformat umrechnet (Eingabe hier: «Binary» Ergebnis: «Hexadecimal»).
    Ergebnis:
    91DE42B2A1D81213FFC2530438CDA8A212B6D5D6FCC5D9CC2CE3A8E14C103D4E
    (Gegencheck: Diesen Wert, statt der Zufallszahl bei iancoleman unter «Show entropy details» im Feld «Entropy» eingeben, ergibt den selben Seed)
     
  2. Davon wird mithilfe des SHA256-Algorithmus ein 64 Zeichen langer Hash erstell (Eingabe hier: «Binary hash» Ergebnis unter «SHA-256»)
    Ergebnis:
    f39f69191547240f0d69e1fc46f89bcbc059f90f01b5cbffe192a90a5d82bf70
     
  3. In unserem Fall (256-Bit-Zufallszahl) nehmen wir nun die ersten 2 Zeichen, «f3» (wir brauchen nur die ersten 8 Bit), und rechnen es zurück ins binäre (Eingabe hier: «Hexadecimal» Ergebnis: «Binary»)
    Ergebnis:
    11110011
    (zu sehen bei iancoleman unter «Binary Checksum», und das ist auch ist der restliche Teil für das 24. Wort)
  4. Man hängt diese Checksumme nun ans Ende der ursprünglichen 256 Bit langen Zufallszahl (Binärzahl).
    Ergebnis:
    100100011101111001000010101100101010000111011000000100100001001111111111110000100101001100000100001110001100110110101000101000100001001010110110110101011101011011111100110001011101100111001100001011001110001110101000111000010100110000010000001111010100111011110011
     
  5. Die nun 264 Bit lange Zeichenkette wird dann in Gruppen von 11 Zeichen unterteilt (zu sehen bei iancoleman unter «Raw Binary»)
    10010001110 ... 11011110011
    Jede dieser Gruppen wird dann umgewandelt in eine Dezimalzahl umgewandelt (Eingabe hier: «Binary» Ergebnis: «Decimal»)
    Zu den einzelnen Dezimalzahlen (zu sehen bei iancoleman unter «Word Indexes»), kann man auf der englischen Wortliste (BIP39) das passende Wort suchen (Position = Zahl+1)
    Ergebnis:
    Wort 1:    (binär) 10010001110   -> (dezimal) 1166    -> (Wort) mushroom 
    Wort 24: (binär) 11011110011     -> (dezimal) 1779    -> (Wort) taxi 
Bearbeitet von o0dy
  • Thanks 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Man kann sich mit diesen Spielchen ja unbegrenzt Mühe machen.

Ich benutze da einfach eine Excel-Tabelle.  :)

Die hat zwei Spalten mit Zufallszahlen und eine dritte in der der Wert mit einer Formel aus den beiden ersten berechnet wird.

Wenn ich die beiden Spalten einzeln neu berechne oder auch Teile davon dann kann niemand das Ergebnis nachvollziehen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

@o0dy Danke, nochmal ne saubere Darstellung wie man easy an die Checksumme kommt. Einfach über IanColeman, dann brauchts kein Hashen und keine weiteren involvierten Programme...

Schöne Sache, so kommt man mit einem Blatt Papier und der ausschliesslichen Verwendung von IanColeman an einem Offline PC an nen 100% zufälligen Seed, kann sich paar Adressen rausschreiben, zur Not per Hand, und wenn danach noch der PC formatiert wird hat man ne Liste von absolut sicheren Einzahladressen für langfristige Aufbewahrung. Ohne jemals eine Wallet, ob Hot oder Cold, in Verbindung mit dem Seed gebracht zu haben...

 

vor 1 Stunde schrieb Crusader:

Man kann sich mit diesen Spielchen ja unbegrenzt Mühe machen.

Ich benutze da einfach eine Excel-Tabelle.  :)

Die hat zwei Spalten mit Zufallszahlen und eine dritte in der der Wert mit einer Formel aus den beiden ersten berechnet wird.

Wenn ich die beiden Spalten einzeln neu berechne oder auch Teile davon dann kann niemand das Ergebnis nachvollziehen.

Es ging doch drum die Checksumme, also das 24te Wort selber möglichst einfach auszurechnen. Wie willst das mit der Excel Tabelle machen?

 

  • Like 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 4 Minuten schrieb mahatma:

Einfach über IanColeman, dann brauchts kein Hashen und keine weiteren involvierten Programme...

Klar, mir gings nur darum dass man es auch nachvollziehen und gegenchecken kann, für die interessierten und paranoiden wie mir 🤣.

Bearbeitet von o0dy
  • Love it 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 10 Minuten schrieb mahatma:

Es ging doch drum die Checksumme, also das 24te Wort selber möglichst einfach auszurechnen. Wie willst das mit der Excel Tabelle machen?

 

Zunächst ging es doch darum den Seed zu erzeugen.

Und da halte ich die Arbeit mit den Würfeln eben für unnötig.

Wenn man einen vermutlich "schlechten" Zufallszahlen-Generator verwendet dann kann man eben mehrere Zahlenreihen kombinieren. Wenn eine dann nur 10^20 liefert habe ich mit drei auch 10^60.

Oder man nimmt einen guten Generator der OpenSource und geprüft ist.

Die Berechnung der Prüfsumme ist hingegen nicht kritisch.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 4 Minuten schrieb Crusader:

Oder man nimmt einen guten Generator der OpenSource und geprüft ist.

...und musst immer im Hintergedanken haben, dass der vllt doch doch nen Fehler haben könnte, wenn ich diese Würfel ists zu 100% Zufall. Feddisch.
Und das mache ich auch für den Ledger z.B. Falls irgendwann ein Bug rauskommt schlafe ich ruhig weiter.

Bearbeitet von o0dy
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 4 Minuten schrieb o0dy:

Und das mache ich auch für den Ledger z.B. Falls irgendwann ein Bug rauskommt schlafe ich ruhig weiter.

Wenn die Software auf den Ledger einen Bug oder eine Hintertür hat musst du dir um die Qualität deines Seeds wohl keine Gedanken mehr machen.  :)

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 6 Minuten schrieb Crusader:

Wenn die Software auf den Ledger einen Bug oder eine Hintertür hat musst du dir um die Qualität deines Seeds wohl keine Gedanken mehr machen.  :)

Es geht um die Erstellung dessen vom Ledger, falls er doch nicht so zufällig war ;) 

Bearbeitet von o0dy
Link zu diesem Kommentar
Auf anderen Seiten teilen

Mega cooler Beitrag, besten Dank. Hatte mit etwas ganz anderem gerechnet wegen dem Titel. Werde ich mir noch durchlesen, in diesem konkreten Detailgrad hast du diverse Infos im Artikel, die mir nicht bekannt sind.

Kleine Anmerkung zum QC Teil: Man sollte stets zwischen logischen und physikalischen Qubits unterscheiden Wiki-Link. Wenn es um reale Maschinen geht, dann wird stets von physikalischen Qubits gesprochen, Algorithmen gehen aber (afaik) üblicherweise von logischen Qubits aus. D.h. deine Angabe mit den 2000+ Qubits ist evtl. um den Faktor 1.000 zu niedrig angesetzt.

  • Thanks 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 3 Minuten schrieb o0dy:

Von was redest du da, ist das auf meinen Beitrag bezogen?

Ja klar, du sprichst von  "die Erstellung dessen vom Ledger, falls er doch nicht so zufällig war".

Also wieso sollte man so einem Gerät vertrauen auf dem eine unbekannte Software läuft?

  • Confused 1
Link zu diesem Kommentar
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...

Wichtige Information

Wir haben Cookies auf Deinem Gerät platziert. Das hilft uns diese Webseite zu verbessern. Du kannst die Cookie-Einstellungen anpassen, andernfalls gehen wir davon aus, dass Du damit einverstanden bist, weiterzumachen.