Topic: Nach Verschluesselung der Wallet durch Originalclient, wird Plaintextwallet ... (Read 919 times)

Maedels und Jungs, vielen Dank fuer die Infos. Bin heute um einiges schlauer geworden.

Gruss,
cu

Genial! Gibt es dazu eine Quelle und seit wann das in Bitcoinqt drin ist? (Edit: https://en.bitcoin.it/wiki/Wallet_encryption, letzter Absatz und das ist mindestens seit 2012 drin: https://bitcoin.stackexchange.com/questions/5800/how-does-an-encrypted-wallet-persist-used-keys-from-getnewaddress-and-the-keyp)

Nichtsdestotrotz, lass mich das aber nochmal zusammenfassen:

0. Viele Sachen ueber die ich jetzt erst stolpere sind schon lange in die Entwicklung von Bitcoinqt eingeflossen!
1. Erzeuge Wallet auf Rechner ohne Internetanschluss
2. Verschluessle Wallet sofort nach Erstellung
   => 1. Key wird verschluesselt, die anderen 99 Keys werden geloescht als benutzt markiert, werden von nun an durch getnewaddress ignoriert und 99 verschluesselte Keys werden neu erzeugt
3. Markiere erste Adresse als unsicher
4. Wallet kann geschlossen und abgespeichert werden und man kann sich wohlgemut anderen Dingen widmen
5. Alles unter der Vorraussetzung, dass kein Keylogger das Passwort abgreift

Edit: Wuerde auch folgendes funktionieren?

1. bitcoinqt mit -keypool=1 Parameter starten
2. Wallet verschluesseln
3. dann im Debug-Fenster: keypoolrefill 99

Naja, irgendwie beides. Wenn Du bitcoin core das erste mal startest erzeugt es eine wallet.dat die sieht in etwa so aus:


Wenn Du jetzt ein Password setzt dann werden keys 2 bis 100 entfernt und neue erzeugt.

Nachtrag: Wenn Du dann 13 benutzt, erzeugt bitcoin core bei nächster Gelegenheit (wallet.dat wird entschlüsselt durch z.B. senden von BTC) neue um den sog. keypool wieder aufzufüllen.

Ok. Ich sehe worauf ihr hinaus wollt:

Erst verschluesseln und dann die Keys erzeugen!

Einfach aber genial. Muesste man die Anzahl an automatisch erzeugten Schluessel minimieren.

Nur um Missverstaendnissen vorzubeugen: die Aussage "Da die automatisch generierten Keys nach der Umstellung des Core Client für neue Anfragen nicht mehr genutzt werden, [...]" soll eigentlich heissen

"Da die automatisch generierten Keys nach der Umstellung des Core Client für neue Empfaenge Anfragen nicht mehr genutzt werden sollten, [...]"

so wie bei shorena. Richtig?

Mit der Methode kann ich leben

Richtig. Maximal der erste erzeugte key ist ein Problem, weil der über das verschlüsseln und das neue erzeugen existiert und benutzt werden kann. Wenn man also paranoid ist:

#1 bitcoin core starten
#2 alle angezeigten Addressen mit "DO NOT USE INSECURE" labeln
#3 password setzen
#4 neue Adressen/keys erzeugen (anzeigen lassen)

Da die automatisch generierten Keys nach der Umstellung des Core Client für neue Anfragen nicht mehr genutzt werden, sollte es bezüglich der Platten kein Problem sein. Swap und RAM sind, unabhängig vom Tool, nochmal ein anderes Thema.

Richtig! Aber irgendwann muss die Coldwallet ja auch erzeugt werden. Und sie wird nicht automatisch verschluesselt erzeugt, sondern erst als Plaintextwallet. Zmdst nicht mit Bitcoinqt. Deswegen dieser Thread hier.

Ergo wird immer ein Abbild der Plaintextwallet auf einem nichtfluechtigem Speicher erzeugt. Oder ich mach was bei der Bedienung von Bitcoinqt falsch. Vllt geht es ja mit bitcoind, waere gut zu wissen wie.

Das muss bei modernen Platten nicht so funktionieren, bei SSD noch weniger.


Hängt vom Angreifer ab. Gegen ein Script-Kiddy hilft schon ein 'rm', während man gegen einen fähigen Angreifer am besten die Platte komplett verschlüsselt - auch bzw. vor allem den Swap!

Solange das System läuft hilft das alles nicht, weil dann die relevanten Informationen im Speicher liegen. Auch deshalb sollte man sein Vermögen nicht unbedingt in der Hot-Wallet lagern.

Es spielt nicht immer, aber öfters eine Rolle. Massenspeicher haben mehr Speicherkapazität als sie angeben. Festplatten ca 5% mehr. Flashspeicher bis zu 15%. Bei Flash wird dieser Mehrspeicher mitgenutzt beim Zyklen, bei der Festplatte ersetzt er defekte Sectoren. Bei der Festplatte kann das randvoll füllen noch sicherheit bedeuten, da sie den Mehrplatz erstmal in ruhe lassen. Beim Flash hingegen könnte die gelöschte Datei gerade nicht im Zugriff sein. Den mehr als der "freie" Platz wird nicht geschrieben. bei sagen wir 16GB und 1GB reserve sowie 8GB gefüllt ist die chance bei 12,5% das deine gelöschte Datei in den 1GB reserve liegen. und nach 8GB schreiben ist Ende.

Allerdings taucht dieser Speicher natürlich wieder auf früher oder später. Jede Zelle wird zyklisch mal beschrieben. Auch diese reserven.

Unter der Annahme es ist eine Festplatte (bin mir nicht sicher ob das ueberhaupt eine Rolle spielt), sollte das dd-Kommando den freien Speicherplatz ueberschreiben und wenn gefuellt mit Fehlermeldung abbrechen. Daraufhin kann blahhh geloescht werden. Sollte doch eigentlich praktisch alle mit "kann geloescht werden" geflagten Dateien, und somit auch die zu loeschende Zieldatei, ueberschreiben.

Mir gehts auch darum alles auszuloten was machbar ist um die Sicherheit zu erhoehen. Wenn der Worstcase eintritt, weil ich irgendwas nicht versucht habe, dann liegt der Fehler bei mir, und das ist der Psyche abtraeglich. Ansonsten kann man es aufs System schieben. Die Zeit war einfach noch nicht reif ...

Weil es sonst System- und Hardwareabhängig ist, ob Du den freigegebenen Speicher der Wallet tatsächlich überschrieben hast. Dann kannst Du fast schon gar nichts machen und hoffen, dass das System selbst den Platz irgendwann mal tatsächlich überschreibt.

Warum?

Bringt nichts, eher sowas:

Besser wäre allerdings gewesen, die Platte von Anfang an komplett zu verschlüsseln.

Ok. Besser ist dann wohl sowas wie


auf dem fraglichen Device.

Auf der anderen Seite ueberschreibt Bitcoinqt bei Verschluesselung der Plaintextwallet, welche nur als Softlink im .bitcoin-Ordner liegt, den Link.

D.h. die eigentliche Datei am Ende des Links wird verschluesselt (zmdst wird sie derart modfiziert das sie so aussieht als waere sie verschluesselt), jedoch wird auch der Link ersetzt. Aus welchen Gruenden auch immer.

ok, einfache Antwort: Egal ob der Client es macht(er macht es nicht) es kann nicht sicher gesagt werden ob es erfolgreich ist.

Und weil das nicht sicher gesagt werden kann, wird es nicht mit eingebaut.

Übrigens wird auch shred versagen, wenn ich zb eine SSD benutze, sei es nativ oder als Spiegelplatte zur Beschleunigung. Dort weis nur der Controller wo die Datei liegt, diese Info rückt er aber nicht raus. Und er lässt auch nicht zu, das man diese Speicherzelle explizit beschreiben kann. Er rotiert grundsätzlich. Aber auch mechanische Festplatten nutzen inzwischen eigene Mechanismen zur Beschleunigung die dazu führen, das das Betriebssystem nicht mehr weis, welcher logische Block wo liegt. Kann noch der alte Platz sein, kann aber auch schon wonanders sein.

Nochmals meine Frage als Einzeiler:

Macht bitcoinqt, nachdem man eine Plaintextwallet zum ersten Mal verschluesselt hat, soetwas wie: https://wiki.ubuntuusers.de/shred?

Vieleicht solltest du dich zuerstmal damit beschäftigen wie ein Betriebssystem Dateien speichert.

Ich kenne momentan kein Dateisystem das nicht folgenden Mechanismus benutzt:

Neue Datei schreiben unter Tempnamen
Alte Datei löschen
Neue Datei umbenennen

Jedesmal wenn du speicherst wird also eine neue Kopie angelegt. Die Alte wird nur als gelöscht markiert und erst später überschrieben. Würde man das anders machen, hat man das Problem, das ein Stromausfall Datenverlust bedeutet. Es gibt zwar OS das es anders macht, aber muss nun mit vielen anderen Nachteilen leben die langfristig gravierend sind. Eine Datei die gespeichert wird ändert sich meistens in der Größe. Wird sie kleiner entstehen Lücken die man eigentlich nicht füllen kann bzw wenn man sie füllt fragmentieren die Dateien enorm. Bei den mechanischen Festplatten ein großer Nachteil. Erst neuerdings mit SSD ändert sich das. Aber ein Dateisystem ist erstmal unabhängig vom Medium und muss mit dem Worstcase zurecht kommen. Und wenn die Datei größer wird kommt es erst recht zu Fragmentierungen.

Ich weis ja nicht genau was deine Zielsetzung ist, die dir im Kopf rumschwebt. Willst du nur wissen wie es technisch abläuft? Oder gehts mehr um reale Anwendung, zb die Altersabsicherung zu hinterlegen? Oder willst du einige Millionen verstecken vor dem Zugriff Dritter.

Je nach dem ist es eben garnicht nötig derartige Sicherheit zu haben. Wenn ich weis, was du willst, kann ich dir gerne einen Tipp geben, in welche Richtung du dich absichern solltest. Gegen Alles abzusichern geht grundsätzlich nicht, da du ja immer in der Lage sein willst zuzugreifen. Und folglich muss man keine wochenlangen Wartenzeiten in Kauf nehmen bis ein Verfahren gehackt ist. Sondern nur soviel Zeit mitbringen, dich weichzukochen. Sag uns doch mal die Summe die nötig ist, das du dich umbringen lässt statt das Passwort zu verraten. Sie dürfte vermutlich irgendwo zwischen unendlich Hoch  und weit Drüber sein.

Um meine Frage zu praezisieren:

Bei Verschluesselung der Wallet durch den Originalclienten kommt zuerst die Abfrage des gewollten Passworts, dann eine Abfrage ob man wirklich verschluesseln moechte und dass der Verlust des Passworts zum Verlust der Coins fuehrt, dann die Meldung das der Client geschlossen werden muss um die Verschluesselung abzuschliessen.

Wieso dieses Verhalten mit dem Neustart, wenn dies nicht der Sicherheit geschuldet ist, ist der Neustart doch eigentlich nicht zwingend notwendig? Aus irgendeinem Grunde wird die Wallet vollstaendig neu geschrieben. Wuerde sich ja an dem Punkt anbieten mehrfach den Plaintextfile zu ueberschreiben. (Deswegen dauert die Verschluesselung auch ein paar Sekunden, zmdst auf meinem Rechner).

Nein.


Shred funktioniert nur bedingt, z.B. müsstest Du bei einer SSD die gesamte Festplatte überschreiben um wirklich sicher zu gehen das die Daten überschrieben wurden.


Nein, die alten privaten Schlüssel werden verworfen. Bitcoin core generiert 100 Keys vor, nach dem verschlüsseln werden alle Keys die dir noch nicht angezeigt wurden neu erzeugt.


Die 100 keys werden regelmäßig erneuert, Du musst also regelmäßig backups machen. Was das Passwort angeht wird die Verschlüsselung so ausgelegt das jeder Versuch die Datei zu entschlüsseln an Deinem Rechner ca. 1 Sekunde braucht. Das gilt natürlich nicht für andere Rechner, da diese ggf. schneller sind.

zur Stärke von Passwörtern -> https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password-strength-estimation/

... "geshreddert"?

Ich frage, weil die Loeschung von Plaintextwallets durch shred empfohlen wird um die Datei vollstaending vom Datentraeger zu loeschen.

Ich gehe mal davon aus, dass dies von bitcoinqt nach Verschluesselung der Wallet automatisch durchgefuehrt wird. Liege ich mit meiner Annahme richtig? Zumindest wuerde dies das Verhalten des Clienten erklaeren.

Edit: Gibt es sonst noch irgendwelche Tipps worauf man achten sollte bei der Verschluesselung der Privatekeys durch den Originalclienten bzw. Probleme die auftreten koennten? Also sowas wie Passwort laenger als 12 Zeichen, Zeichen aus der Menge {a-z, A-Z, 0-9, Sonderzeichen} ...