Hallo, ich benutze Atomic Wallet.
Nachdem ich mir überlegt habe, dass man private Schlüssel auch erraten könnte indem man diese 12 Wörter brutforced, frage ich mich aus welchem Pool von Wörtern diese Wörter genommen werden.
Weiss da jemand genaueres ?
Vielen Dank!
Your 12-word phrase is a set of words randomly taken from a dictionary, with each word assigned to a number. The words are taken from a wordlist of the BIP39 standard (2048 words). So if the phrase contained only 12 random words, the number of possible combinations would be 2048^12 = 2^132 and the phrase would have 132 bits of security.
aja danke, warum hat man es nicht gleich mit 24 Wörtern gemacht ?
Wäre doch wesentlich sicherer, oder ?
VG
Ja, das schon.
Aber das ist in etwa so, als ob Du Dir
Bei 12 Worten sind 2048^12 = 2^132 Kombinationen schon so f*cking viel, dass weitere 12 Worte das System nicht wesentlich sicherer machen.
(Zumindest nach dem Stand der heutigen Technik. In 10 Jahren sieht’s vielleicht anders aus.)
Man wird sich dann immer fragen: Wieso nicht noch ein Wort mehr?
edit: Halbwissen: Abgesehen davon ist glaube ich der Key trotzdem gleichlang. Ein Bruteforce auf den BIP39 Seed und Rootseed (nicht Mnemonic) ist unabhängig von der Anzahl an Wörtern genau so leicht/schwer.
Joah, 24 Wörter sind halt etwa
mal sicherer als 12. 
Das ist auch eine f*cking große Zahl!
Übrigens ist es durch die Checksumme etwas weniger (beim letzten Wort stehen keine 2048 Wörter zur Auswahl). Es sind 2^{128} insgesamt, du hast auch nur 128 bit Entropie aus der die Mnemonic gebildet wird.
Nein Jein
Hinter einer Mnemonic mit 24 Wörtern liegen 256 bit Zufall, also 2^{256} Kombinationen möglich.
Hinter einer Mnemonic mit 12 Wörtern liegen 128 bit Zufall, also 2^{128} Kombinationen möglich.
Der Seed hat 512 bit (was direkten Angriff auf diesen sinnlos macht) also ist die Chance was gültiges zu finden über eine 12-Wort Mnemonic realistischer.
Wobei man natürlich sowieso über einen private key angreifen würde, davon hatten wir es ja schon öfters.
Wahrscheinlich habe ich Begriffe durcheinander gebracht. Also wenn man einen Bruteforce auf den Wallet Private Key macht (und nicht Mnemonic), sollten die Anzahl an Wörtern für den Seed egal sein. Falls ich das jetzt richtig verstehe.
Aber wie oben gesagt wurde, sichert man sich gegen einen Bruteforce auf die Mnemonic mit mehr Wörtern ab.
Genau. Da bleibt die Wahrscheinlichkeit gleich (gering), da ein private key unabhängig von der ursprünglichen Mnemonic immer 256 bit lang ist. Allerdings gewinnt man dann (meistens) auch nur Kontrolle über eine Adresse.
Hier hat skyrmion das noch weiter ausgeführt und die 2^{160} möglichen Adressen (durch RIPEMD160) ins Spiel gebracht:
Wobei das soweit ich weiß nicht auf bech32 Adressen zutrifft, also wäre dann der Weg über die 12-Wörter Mnemonic immer noch besser (trotz der deutlich höheren Kosten durch das mühsame Ableiten). Aber da müsste man sich nochmal richtig rein denken, und am Ende kommt man sowieso immer bei Es ist verdammt sicher raus.
Langfristig ist es in jedem Fall besser auf 24 Wörter zu setzen, da die dadurch enstehenden Kosten (12 Wörter mehr aufschreiben) minimal sind. 
Stimmt, aber in der Praxis macht es das trotzdem nicht sicherer.
Ob ich 1 Mio. Jahre an einem BruteForce sitze oder 1000 Mio. Jahre spielt keine Rolle.
Ja ja…dann sind’s halt nur 10.000 Jahre. Spielt auch keine Rolle. 
Mathematisch gesehen: Ja.
In der Praxis: Nein.
Zumindest laut meines damaligen Mathematik- und Verschlüsselungs-Profs.
Pff… Spaßbremse… 
Wir kommen den 128 bit aber trotzdem langsam näher. Die aktuelle Empfehlung des BSI beträgt 100 bit für Schlüssellängen. Nach Ende 2022 wird die Empfehlung auf 120 bit angehoben. Das hat mir mein Prof auch eingetrichtert.
Geht man vom Moore’schen Gesetz aus kannst du gedanklich alle 2 Jahre 1 bit dazu nehmen. Ein Angriff ist auch in Zukunft unwahrscheinlich, aber wir werden früher oder später an der Grenze „praktisch möglich“ kratzen.
Wie oben schon erwähnt:
24 Wörter kosten nichts. Gratis Sicherheit, wenn auch rein kryptographisch, schadet niemandem. Ist oftmals auch praktischer, da z.B. ein Mnemonic Split erst mit 24 Wörtern relativ sicher möglich ist.
Du hast Realist falsch geschrieben. 
Absolut.
Das ist richtig. Aber Panik zu haben oder zu machen, weil es „nur“ 12 Worte sind, muss man auch nicht. 
Hier mein grobes Verständnis. Ich lasse mich aber sehr gerne korrigieren, da ich mich erst langsam einarbeite.
Ich kann mir eigentlich auch nur vorstellen, dass man die 24 Wörter erstens aufgrund der langfristigen Zukunftssicherheit eingeführt hat. Selbst ggü. Quantencomputern, welche die Sicherheit evtl. von 256 Bit auf 128 Bit reduzieren könnten, wäre das wahrscheinlich noch sicher.
Zweitens handelt es sich eben um das „Master-Passwort“, von dem alles andere abgeleitet wird. Es kann also ruhig etwas sicherer als der Rest sein.
Auch ein Argument.
Ansonsten ist in der Kette der verwendeten Verfahren vom Mnemonic bis zum Private Key das schwächste Glied entscheidend. Im Vergleich mit der Sicherheit der anderen Verfahren ggü. Brute Force Angriffen wären die 128 Bit eines 12 Wort Mnemonics wahrscheinlich ausreichend.
Die SHA-2 Hash-Funktionen bieten ggü. Brute Force Angriffen (Preimage Resistance, nicht Collission Resistance) heute noch immer die volle Sicherheit (Quelle). Also z.B. 256 Bit für SHA-256.
Mnemonic 12 Wörter → 128 Bit
Gerade weil der Mnemonic so wichtig ist, wird vor der weiteren Schlüssel-Ableitung erst einmal die PBKDF2 Funktion mit 2048 Iterationen von HMAC-SHA512 verwendet, um einen Brute Force Angriff auszubremsen.
Bei einem 12 Wort Mnemonic hätte man also 128 Bit Sicherheit plus langsames Brute Forcen.
Bitcoin Adresse → 160 Bit / 256 Bit
Eine Bitcoin-Adresse bietet ggü. Brute Force Angriffen nur 160 Bit Sicherheit, da der Public Key bzw. das Skript bei fast allen Adresstypen letztendlich RIPEMD160 gehasht wird. Bei Native Segwit (bech32) wird der Public Key Hash RIPEMD160(SHA256(PubKey)) nur anders codiert.
Allerdings gilt das nur für Public Key Hash und alte Script Hash Adressen (P2PKH, P2WPKH, P2SH). Bei den Native Segwit Skripten wird nur SHA256 gehasht (P2WSH), man hat dort also wohl eine höhere Sicherheit.
Unabhängig davon muss man beim Durchführen einer Transaktion den Public Key veröffentlichen, wobei dann für einen Brute Force Angriff allerdings kaum Zeit bleibt.
Bitcoin Public Keys und Taproot Adressen → 128 Bit
Für das Brute Forcen eines Elliptic Curve Public Keys von 256 Bit benötigt man „nur“ eine Größenordnung von 2¹²⁸ Schritten (Quelle), also hat man eine Sicherheit von 128 Bit.
Wie meint ihr das genau?
Absolut. Wenn’s nach mir geht, würde ich heute schon alles auf 512 ändern.
Aber man muss halt Kosten/Nutzen abwägen und 12 Worte für eine simple Software Wallet reichen. Was steckt da im Maximum drin? 1 BTC? 5 BTC?
Der Aufwand für ein BruteForce lohnt sich nicht einmal ansatzweise, selbst bei „nur“ 128 bit Entropie.
Ansonsten bin ich ganz bei Euch: Je höher, je besser.
Darf ich noch einmal mein Schusswesten-Beispiel bringen? Ich finde das nämlich sehr passend. 
Natürlich ist es sicherer, sich 10 Schusswesten anzuziehen als 5. Rein Mathematisch gesehen.
Aber in der Praxis, in der eigentlich schon 1 Schussweste reichen sollte, bist Du mit 10 Westen nicht geschützter als mit 5, weil schon die 2. oder spätestens die 3. Weste die Kugel aufhalten wird.
Ändert der Angreifer in der Zukunft die Kugelgröße (=Computer werden schneller und BruteForce wird dadurch effizienter), braucht man mehr Westen.
Was wiederum bedeutet dass SHA-512 4096 mal angewendet werden muss, das wird oft noch vergessen.
Okay, das ist mir noch nicht ganz klar geworden. Bin gerade dabei Mastering Bitcoin mal ausführlich komplett zu lesen (habe mir endlich eine physische Ausgabe organisiert) und tue mich mit Kapitel 7 etwas schwer.
Du sprichst jetzt von 160 bit Sicherheit bei P2SH und 256 bit Sicherheit bei P2WSH, da hier nur SHA-256 angewandt wird. Das verstehe ich.
Diesen Absatz in Kapitel 7 verstehe ich dann aber nicht:
(Fettmarkierung von mir)
While P2SH uses the 20-byte RIPEMD160(SHA256(script)) hash, the P2WSH witness program uses a 32-byte SHA256(script) hash. This difference in the selection of the hashing algorithm is deliberate and provides stronger security to P2WSH (128 bits of security in P2WSH versus 80 bits of security in P2SH). It is also used to differentiate between the two types of witness programs (P2WPKH and P2WSH) by using the length of the hash (see below).
Link
Woher kommen die 80/128 bit?
Und du hast natürlich recht, auch unsere bech32 Adressen (P2WPKH) laufen durch RIPEMD160, ich komme andauernd durcheinander zwischen P2WPKH, P2WSH usw. (muss die Namen immer gedanklich aufsagen 
)…
Das hatte ich bei dir glaube ich schon einmal gelesen. Auch wenn es etwas Richtung OT abdriftet würde mich das kurz im Detail interessieren.
Im BIP39 steht:
To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string „mnemonic“ + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).
Bei Wikipedia zu PBKDF2:
The PBKDF2 key derivation function has five input parameters:
DK = PBKDF2(PRF, Password, Salt, c, dkLen)
Und zur verwendeten Pseudo Random Function (PRF) HMAC-SHA512:
H is a cryptographic hash function
m is the message to be authenticated
K is the secret key
K’ is a block-sized key derived from the secret key, K; either by padding to the right with 0s up to the block size, or by hashing down to less than or equal to the block size first and then padding to the right with zeros
Ich finde die Bezeichnungen verwirrend. Der Mnemonic wird als Password und ‚mnemonic‘ + Passphrase als Salt an PBKDF2 übergeben. Soweit klar. Aber reicht PBKDF2 das Password dann als message m oder als secret key K an HMAC-SHA512 weiter?
Den letzteren Fall verstehe ich so, dass der Mnemonic, der mehr als 64 Byte hat, bei jeder Iteration bereits einmal mit SHA512 vorgehasht werden muss, um K’ auf die gewünschte Länge zu bringen. Man hätte dann zusammen mit dem eigentlich Hash zwei Hashes pro Iteration (4096 total).
Im ersteren Fall, also als message m würde allerdings nach meinem Verständnis nicht vorgehasht werden müssem, da ‚mnemonic‘ + Passphrase weniger als 64 Byte haben.
Kannst du den ersten Fall so bestätigen? Normalerweise kommt man mit diesem Detail nicht in Berührung, da man nur PBKDF2 mit den entsprechenden Argumenten aufruft.
Anscheinend wird und wurde auch bei Bitcoin schon länger diskutiert, ob die Collission Resistance oder die Preimage Resistance der Hash-Funktionen entscheidend ist.
Bei meinen Zahlen oben zur Sicherheit ggü. Brute Force Attacken habe ich mich auf die Preimage Resistance bezogen. Also wie aufwendig man den Klartext (Mnemonic oder Private Key) zu einem gegebenen Hash (Adresse) suchen muss.
Die Collission Resistance gibt dagegen an, wie aufwendig man nach zwei Klartexten suchen muss, die einen (beliebigen) gemeinsamen Hash ergeben, Also in unserem Kontext zwei Mnemonics oder Private Keys mit gemeinsamer Adresse.
Dieser Aufwand ist wegen des Geburtstagsparadoxons typischerweise wesentlich geringer, Größenordnung = Wurzel(Hash-Sicherheit). Deshalb empfiehlt das BSI auch mindestens 240 Bit Hash-Länge, damit eine Kollisionssicherheit von 120 Bit erreicht wird (Seite 41).
Bei SHA-256 hat man also 128 Bit Sicherheit gegen Kollisionen. Bei RIPEMD160 nur 80 Bit. Daher kommen ziemlich sicher die Zahlen in Mastering Bitcoin.
Hier eine interessante Diskussion in der Bitcoin Developers Mailing Liste aus 2016, u.a. zwischen Gavin Andresen und Pieter Wuille, genau zu diesem Thema:
. Man kann sich mit „Next message“ durchklicken)Pieter Wuille meinte, dass die Collission Resistance auch bei Bitcoin entscheidend ist. Für mich hört es sich etwas sehr konstruiert an, aber ich habe es wahrscheinlich noch nicht ganz verstanden.
P. Wuille meint, ein Betrüger könnte nach zwei unterschiedlichen Skripten suchen, die einen gemeinsamen Hash ergeben. Eines der Skripte könnte man nun als Nachweis ggü. jemandem verwenden, um einen (Zahlungs-)vorgang nachzuweisen, wobei nachher nur der Hash in der Transaktion steht. Anschließend verwendet der Betrüger aber das andere Skript mit dem selben Hash, um den UTXO anderweitig zu transferieren.
Lange Rede, kurzer Sinn:
Wenn diese Entwickler recht haben, dann ist ein RIPEMD160 Hash auch bei Bitcoin schon nicht mehr ausreichend.
Wem sagst du das… 
So wie ich es verstehe, müsste man Skripte bzw. P2WSH Adressen auch für eine normale Native Segwit Single Sig Wallet verwenden können. Ich habe bei der Walleteinrichtung noch nie darauf geachtet. Wahrscheinlich ist P2WPKH Standard.
Ich hatte mich ehrlich gesagt nicht wirklich damit befasst sondern das war einfach reine Intuition.
Ganz allgemein soll ein HMAC ja verhindern dass eine Nachricht manipuliert wird. Um das sicher hinzukriegen wird zwei mal gehasht weil man sich nicht auf Kollisionsresistenz verlassen will.
\text{HMAC}(m)=h(k_2|h(k_1|m)) vs. \text{MAC}(m)=h(k|m)
Ich auch!
Password (also unserere Mnemonic) wird zunächst als K in die PRF gegeben, und der Salt ist am Anfang zusammen mit einem Index die Nachricht m.
Bei der nächsten Iteration wird dann wieder Password als K übergeben, jetzt ist aber der vorherige PRF Output die neue Nachricht m. (Und so weiter)
HMAC-SHA512 führt wie oben beschrieben zweimal SHA-512 aus. PBKDF2 selbst wendet keine Hashfunktion an, das ist am Ende nur XOR (?)
Also kommen wir auf 4096 SHA-512 Aufrufe bei c = 2048.
DK = T1 + T2 + ⋯ + Tdklen/hlen
Ti = F(Password, Salt, c, i)
The function F is the xor (^) of c iterations of chained PRFs. The first iteration of PRF uses Password as the PRF key and Salt concatenated with i encoded as a big-endian 32-bit integer as the input. (Note that i is a 1-based index.) Subsequent iterations of PRF use Password as the PRF key and the output of the previous PRF computation as the input:
Zumindest verstehe ich das so - Angaben ohne Gewähr 
Edit: Das mit den 4096 steht auch in diesem How I checked over 1 trillion mnemonics in 30 hours to win a bitcoin Artikel; da hatte ich das wahrscheinlich aufgeschnappt:
BIP-39 does this using a Password-Based Key Derivation Function with HMAC-SHA512 as the hash function, the string “mnemonic” as the salt, and the 12-word mnemonic as the password. It also uses 2048 iterations and each iteration requires two SHA512 calculations. This means this step will cost in total ~4096 SHA-512 calculations.
Wenn wir schon bei verwirrenden Bezeichnungen sind. Die deutschen Begriffe hier sind meiner Meinung nach auch suboptimal gewählt:
„schwache Kollisionsresistenz“ → second pre-image resistance
„Einwegeigenschaft“ → pre-image resistance
„starke Kollisionsresistenz“ → collision resistance
Ich kann mir das jedenfalls nicht merken.
Das macht natürlich Sinn. Wobei mir (mit Halbwissen) unsere Version auch einleuchtender erscheint.
Aber das kann man gut als Todschlagargument für einen Mnemonic Split nutzen, nach dem Motto: Egal, deine Adresse hat sowieso nur 80 bit Sicherheit, nicht schlimm. 
Super spannend. Ernsthaft. Kryptografische Überlegungen sind wirklich interessant.
Ich habe bei der ganzen Sicherheitsdebatte nur immer ein Verständnisproblem:
Wie kann ein gezielter Angriff überhaupt aussehen? Wie kann ein BruteForce realisiert werden?
Die Richtung von den 12/24 Wörtern → Seed → …-> Public Key → Adresse wird über Hashfunktionen umgesetzt, deren Umkehrung sehr schwer/unmöglich ist. Heißt also hier BruteForce, dass versucht wird, zu einer bestimmten Adresse auf den Private Key zurückzurechnen?
Das Rückrechnen von einem Public Key zurück zum Seed ist ja wohl noch schwieriger/unmöglich.
Ist das aber das aufgezeigte Szenario für einen BruteForce Angriff?
Einen Seed (512 Bit) zu finden, der genutzt wird, ist hier ja sinniger, da man alle Adressen „leerräumen“ könnte. Hier ist aber das Problem, dass es kaum genutzte Seeds im Verhältnis zur Gesamtanzahl gibt, oder?
BruteForce bedeutet, dass Du jede mögliche Kombination durchprobierst.
Wenn Du an Deinem Fahrrad ein 3-stelliges Zahlenschloss hast, fängst Du an mit 000, dann 001, 002, 003 usw. bis Du die richtige Kombination gefunden hast.
Richtig, wir reden hier immer über Einwegfunktionen. Das muss nicht zwingend eine (kryptographische) Hashfunktion sein, beispielsweise wird der Public Key mit Hilfe von Elliptic Curve Multiplication (ECM) aus dem Private Key ausgerechnet.
Das ist hier näher in Mastering Bitcoin erklärt, falls dich das interessiert.
Brute Force („Rohe Gewalt“) bedeutet daher dass man einfach alle möglichen Kombinationen durchprobiert, gerade eben weil weil man nicht zurück rechnen kann.
Genau, es gibt mehr Seedwerte (2^{512}) als es überhaupt Adressen gibt (2^{160}). Daher macht ein Brute Force Angriff hier wenig Sinn.
Achtung: Die Hälfte von 2^{512} ist nicht 2^{256} sondern 2^{511} !