Topic: Thunderbird Bitcoin-Plugin fuer Signierung von Nachrichten - page 2. (Read 4745 times)

Meinst du einen daemon für Namecoin, oder hab ich das falsch verstanden?!
MfG Christian

Hallo Leute,

schoen dass die Diskussion in Gang kommt. War grad ein paar Tage im Urlaub und hatte praktisch keinen Internetanschluss. Was aber dem "Projekt" eher zutraeglich war.

Aktueller Zwischenstand: das Commandline-Tool (bitcoinj) zum einfachen signieren von Nachrichten und das entsprechende Testen ob Nachricht mit Signatur und Adresse uebereinstimmt funktioniert schon. Import und export von Schluesseln geht auch.

Habe das angesprochene Projekt als Ausgangspunkt genutzt. Ist jetzt auch nicht so schwer zu implementieren gewesen jedoch habe ich mich noch nicht um Sicherheitsaspekte gekuemmert. D.h. aktuell soll das Programm erstmal das machen wofuer es gedacht ist. Wobei ich noch nicht so ganz hinter das System der DeterministicKeys in bitcoinj gestieben bin ... das scheint aber nicht der einzige neue Aspekt zu sein. Mal schaun ...

Wie gesagt, ich aeussere mich noch zu den erwaehnten Dingen wie z.B. Namecoin etc.pp.. Leider gibt es fuer Namecoin kein namecoinj (oder irre ich mich???).

Gruss,
cu

Ursprünglich wollte Curiosity einen Ersatz für PGP mit Bitcoinadressen zum signieren und verschlüsseln.

Der Privatekey verlässt den User eigentlich nicht. Entweder nutze ICH den MEINEN Privatekey zum signieren, DU kannst dann mit dem MEINEM Publickey prüfen ob es passt. Oder ICH nutze DEINEN publickey zum verschlüsseln und nur DU kannst es mit DEINEM privatekey entschlüsseln.

Und das ganze soll als Plugin für ein Emailprogramm programmiert werden und statt auf die PGP-Keyserver eben auf die Blockchain zugreifen als keyserver. Nur hat halt die Blockchain bei Bitcoin kein Datenfeld für eigene Zwecke frei. Namecoin hat das wie du sagst, dann wäre es natürlich als Datenbank geeignet.

Bleibt aber das problem des verifizierens. Mit transfer eines Betrages lässt sich eben nichts verifizieren, da jeder einen Betrag transferieren kann. Und in Namecoin kann sicherlich auch jeder in diese ID was reinschreiben. Also kann ich für die Email-adresse [email protected] eine Adresse als Publickey festlegen indem ich diese einfach eintrage. Namecoin prüft ja nicht, ob ich auch Besitzer der Email-adresse bin. Das müsste also wieder eine seperate Stelle machen. Dieses WIE ist aber noch ungeklärt und mir fällt wenig ein. Selbst eine Doppeleintragsprüfung dürfte nicht existieren. Also kann die Adresse wie bei PGP auch mehrfach eingetragen werden.

Also sollte man nicht zuerst ein Plugin programmieren um dann rauszufinden was man damit machen kann, sondern eben zuerst mal definieren, was man genau für Ziele hat und dann dran gehen, wie man sie erreicht. Und diese Zieldefinition fehlt Curiosity völlig. bzw beschränkt sich drauf: ich will mit einer Bitcoinadresse signieren, so das man aus dem publickey der transaktion die Signatur prüfen kann. Kein weiteres Ziel. Welche transaktions man benutzen muss, muss man wohl händisch eintragen und irgendwie dem Empfänger mitteilen. Sinn des ganzen...keine Ahnung.

Also da fallen mir ein paar Dinge auf, die mir vielleicht auch einfach nicht ganz klar sind.
Du willst die Bitcoin-Adresse aus der Email-Adresse erzeugen? Schlechte Idee, dann ist der Private Key nicht private, oder verstehe ich da was falsch?
Wohin geht die Überweisung?
Und die zweite Überweisung muss von der selben Adresse kommen, wie die erste? D.h. wenn ich den Key verliere, kann ich meine Adresse auch nicht mehr ungültig markieren?
Jeder kann sich also jede beliebige Adresse "grabben"? [email protected] ist mein!
Welche Lösungen sollten das verhindern?
"Irgendwie so" klingt jetzt nicht ganz überzeugend.

Der Private Key zu dem Email-Account ist ja jedermann bekannt, da will ich kein Geld drauf empfangen
Aber vielleicht habe ich da einfach wirklich was nicht verstanden.

Das kommt drauf an, was das eigentlich sein soll.
Du willst auf eine Lösung hinaus, die es ermöglicht, Bitcoins quasi an eine Email-Adresse zu senden. Richtig?
Dafür gibt es keine etablierte, funktionierende Lösung.
Mein Vorschlag wäre da aber eindeutig auch in Richtung Namecoin, das ist genau dafür gemacht.

Ja:

Man kann natürlich auch einfach einen anderen namespace definieren und den nutzen, dafür ist Namecoin ja gemacht.

Salopp gesagt kannst du in Namecoin alle hierarchischen Daten sauber ablegen, sollte halt nur nicht zu groß sein.
Das bietet sich also für alle key=value pairs an, solange values nicht gerade riesige Blobs sind

ok, ich bin nur grob drüber geflogen. Wäre da allerdings ein Feld für eine Email wäre das natürlich die benötigte Datenbank. Und als P2P scaliert sie eigentlich auch ganz gut und ist nur sehr schwer in die Knie zu zwingen.

ist in Namecoin nicht
  id/
dafür vorgesehen?
Hab das aber schon lange nimmer angesehen, aber ich hatte "damals" doch irgendwann mal eine "E-Mail adresse gesichert"

Auch Namecoin hat kein Datenfeld für Emailadressen. Daher ist auch hier wiederum eine seperate Datenbank erforderlich. Jedes auf einem asymetrischen Verfahren basierendem Keysystem kann für Signierung oder Verschlüsselung benutzt werden.

Das Problem bleibt letztendlich immer das selbe. Wie schaffe ich es, Missbrauch zu verhindern ohne gleichzeitig 100% eindeutig mich mit der Email zu verbinden. Also ohne meine Pseudonymität aufzugeben. Und dann das ganze in eine Form verpacken, das man nur die Emailadresse eingibt und der Button Signieren und Verschlüsseln wird aktiv.

Sobald man das so umgesetzt hat, wird es massenweise benutzt. Aber irgendwelche Clones für etwas das keiner nutzt ist so den Traffic kaum wert den dieser Thread erzeugt. Und ohne Lösung der genannten Probleme ändert sich daran auch nichts.

nur mal auch als Denkanstoss für eine Implementierung, die Key und Datenhinterlegung kann man ja mit namecoin machen. dafür wurde das ja gedacht...

Danke erstmal fuer diesen Kommentar, der scheint diesmal etwas konstruktiver zu sein  .

Ich werde diesen diesmal schrittweise beantworten, da ich ueber die einzelnen Punkte erstaml nachdenken muss.


Mich interessiert akutell nur Punkt eins, weil er am einfachsten zu implementieren ist. D.h. die Mail wurde vom Absender geschrieben und auf dem Weg zum Empfaenger nicht veraendert. Egal wer der Absender war. Dafuer ist die Veroeffentlichung des oeffentlichen Schluessels essentiell.

Punkt zwei, Verschluesselung, interessiert mich im Moment nicht. Geht ja mit Bitcoin-Privatekeys sowieso nicht, und ganze Schluessel in die Blockchain zu schreiben scheint mir dann doch etwas zu unhandlich.

Fuer Punkt drei wuerde man eine vertrauenswuerdige, zentrale Instanz benoetigen, welche die Schluesselvergabe ueberwacht und vertrauenswuerdige Zertifikate austellt. Davon lass ich auch mittelfristig die Finger. Edit: BTW, den Job koennte eigentlich Bitcoin.de bzw. jeder groessere und vertrauenswuerde Handelsplatz uebernehmen, denn um dort sinnvoll handeln zu koennen muss man sich eh nackig machen. D.h. die registrieren die Email-Adressen zu einer Identitaet in der Blockchain (Bitcoin, Namecoin, whatever) und ich habe keine Arbeit .

Auf deine folgenden Kommentare gehe ich wie gesagt noch ein, muss aber vorher auch noch in mich gehen.

Gruss,
cu

Am besten lege mal fest für welches Ziel dein Plugin sein soll. Was soll es erreichen können.

Soll es eine Mail signieren, damit ich sie nicht verändern kann?
Soll es eine Mail verschlüsseln, damit keiner mitliest?
Soll es eine Mail signieren, das die Mail wirklich von mir kommt und nicht von jemanden der meine Mailadresse gehackt hat?
Sollen die Kommunikationspartner sich kennen oder einfach ohne vorherige Kontaktaufnahme key-basierend kommunizieren können?

Die ersten 3 Dinge zusammen würden eine personalisierten key benötigen, also eine Zuordnung zwischen key und Person.

Gegen Veränderung sichern bedeutet das ich den Publickey eigentlich garnicht öffentlich machen muss, da ich die abgeschickte eh nicht verändern will und kann. Eventuell besteht Gefahr das sie auf dem Weg verändert wurde, dann könnte das veröffentlichen helfen.

Verschlüsseln heist, das ich den Publickey nehmen muss, also erstmal wissen muss, mit wem ich kommuniziere damit ich den richtigen key benutze. In dem Fall würde ich aber AES vorziehen. Sprich ich gebe dir ein Passwort mit dem ich den Inhalt verschlüssel. Eine asymetrische Verschlüsselung wäre hier unnötig. Es sei den alle übertragungswege sind überwacht. Dann allerdings wäre die Blockchain ein guter Ort, den Key manipulationssicher zu hinterlegen. Aber wie publiziere ich die richtige transaktion welche mein Kommunikationspartner benutzen soll? Unter dem Aspekt meine komplette Kommunikation wird überwacht(und damit auch leicht veränderbar). Ein Angreifer würde mir einfach eine andere Bitcoinadresse unterjubeln und könnte so MitM spielen und die Mails lesen(oder verändern) bevor er sie mit dem richtigen key neu signiert oder verschlüsselt und weiter leitet. Du hast keine Möglichkeit das zu erkennen.

Für alles andere fehlt in der Blockchain einfach das Datenfeld um ein weiteres Merkmal unter zu bringen. Man kann ja nur den Betrag und die Adresse dort ablesen. Somit muss ich alles andere selbst irgendwo anders in Erfahrung bringen und hinzufügen. Dann aber würde ich eine passwortgestützt AES-Lösung vorziehen. Im gegensatz zu asymetrischer Verschlüsselung ist AES nicht knackbar, auch nicht mit Quantencomputern.

In einer Publikation habe ich mal folgendes gelesen:
Angenommen, jedes Atom wäre eine CPU die einen Wert berechnet und wir takten das ganze mit der höchsten uns bekannten Frequenz von 10.000 *10^24Hz, benutzen die geschätzte Anzahl an Atomen von 10^85 jeweils als CPU und nehmen die Zeit die uns noch bleibt von ungefähr 2,7*10^10 Jahren, so könnten wir ungefähr 8,5*10^130 Versuche machen einen Schlüssel via Bruteforce zu knacken. Das sind 2^435 Versuche. Da man statistisch nach 50% der versuche den key hat ist ein 437bit Key als unknackbar anzusehen. Wir benutzen AES256, aber es wäre auch kein Problem auf 512 hochzuscalieren. Das darf dann als Unknackbar angesehen werden. Und zwar nicht nur theoretisch sondern praktisch. Lediglich die Implementation kann dann angegriffen werden. Das ist aber lösbar, man muss nur die Enthropie ausreichend gut machen.

AES ist zb in Truecrypt drin und ist unknackbar solange man keine Schwächen in die Implementation einbaut. Das ist wohl inzwischen ausreichend geprüft worden. Asymetrische Verschlüsselung hat hier viele Nachteile und wird daher nur benutzt, wenn ein Schlüsseltausch angreifbar wäre. Allerdings muss dann sicher gestellt werden, das die Schlüssel nicht ausgetauscht sind, also muss eine Verifizierung her, die nicht angreifbar ist. Blockchain ist eine solche Verifizierung aufgrund seiner großen Verbreitung bzw der Tatsache das so viele eine Kopie vorhalten. Aber du musst nun etwas dazu bringen, das die Bitcoinadresse zur Email oder zur Person festlegt. Und dieses Feld fehlt dir in der Blockchain. Daher muss eine weitere Datenbank her, die hier aushilft und da ist wieder das Problem, das es nicht manipulationssicher ist. Ich kann dort alles mögliche eintragen, wie bei pgp-keyservern auch und man hat nichts gewonnen. Den die PGP-Infrastruktur ist ja vorhanden, nur einfach nicht massentauglich und nicht manipulationssicher.

Also selbst wenn du nun ein Plugin bastelst, das eine Bitcoinadresse benutzt um Signier oder Verschlüsselungsfunktionen zu implementieren, bleiben die Probleme die PGP hat bestehen. Es wäre nur ein PGP mit anderer Keybasis. Aber man müsste eine Serverlandschaft aufbauen die hier das Suchen des richtigen keys ermöglicht. Wie oben schon gesagt, wenn du dann drauf setzt das Menschen sich einfach die tx weiter geben, dann kann man auch PGP nutzen oder AES, weil ... wenn ich meinen Kommunikationspartner bereits so gut kenne das ich mit ihm kommuniziere, reicht PGP völlig aus.

Ich hoffe du liest das auch bis zu ende, dann verstehst du warum es nichts bringt ein Plugin zu programmieren, ohne zu wissen was man eigentlich will. Also musst du dir überlegen was du willst. Welcher Input wird genutzt und welcher Output soll kommen. Und erst wenn du das hast, weist du was du machen musst. Dann aber sieht man auch ob etwas Sinn macht oder nicht. Bei Bitcoin würde man also eher ein Plugin benötigen welches eine Bestellung zu einer Bezahlung zuordnet. Also signiert man eine Bestellung mit seinem Privatekey, sendet vom selben Privatekey das Geld weg und über den Geldempfang kann der Händler erkennen welcher Bestellung er das zuordnen muss. Das könnte ein Mail-system sein, aber benötigt keine feste Keyzuordnung, sondern muss den Bezahlvorgang erkennen. Also eher ein Plugin in einer Walletanwendung, das zum Mailprogramm Daten sendet oder dort über ein weiteres Plugin eine API zum signieren bereit stellt.

Wie gesagt, überlegt dir input und output und dann entwickel eine Idee draus.

Hier hat doch mal einer nen Programm gepostet, dass GPG-Keys in die Blockchain schreibt. Da hast Du sogar noch Deinen Senf dazu gegeben (bin grad zu faul den Link rauszukramen, kann jeder selber nach suchen). Da gibt es sogar nen Git-Repository fuer.

Man kann beliebiges in die Blockchain schreiben, auch E-mail-Adressen. Nur verteilt sich die Info bei langen Strings auf mehrere Bitcoin-Adressen bzw. wird von mehreren Bitcoin-Adressen repraesentiert. Da gaebe es aber noch alternative vllt bessere Loesungen zu.

Mir scheint Du hast weniger Ahnung bzw. Fantasie von der Materie als Du versuchst vorzugeben.

Ich will nicht bashend, aber du kapierst es nicht.

Du willst etwas machen, weil du es machen kannst, aber das ergibt keinen Sinn. Es bringt keinen Nutzen, weil die benutzten Mittel nicht dazu passen. Die Blockchain hat keinerlei Verknüpfung zu irgendwas. Es ist eine Kette aus unzähligen Transaktionen. Du kannst diese nicht einer Email zuordnen. Man könnte nun zwar die transaktion als solches publizieren, aber dann brauche ich eine Datenbank die Transaktionsnummern zu Email verknüpft.

Aber mach du dein Plugin, dann lernst du wenigstens programmieren. Der Rest kommt dann wenn du älter wirst von alleine.

GPG ist das beste was wir haben und schon das ist unhandlich. Ich werde doch nicht das Rad neu erfinden, welches dann am Ende eckig ist. Ich bleib dabei, die Idee macht aktuell noch Sinn, bis die implementiert ist aendere ich vllt noch meine Meinung.


Ich bin mir nicht ganz sicher was Du willst. Bashing besteht naemlich nicht aus objektiven Argumenten. Nochmals: keyserver koennen gehackt oder geddost werden. Mit der Blockchain ist das nicht mehr so einfach.

Bei GPG kann jemand zu einer beliebigen Email-Adresse einen beliebigen oeffentlichen Schluessel eintragen ohne, dass jemand aufmerksam wird. Vorrausgesetzt, derjeinge ist der Erste. Auch bei GPG spielt es keine Rolle, dass mit der Email-Adresse und dem Schluessel noch die Identitaet hinter der Person garaniert wird. Satoshi Nakamoto war auch nur irgendein Pseudonym mit Email-Adresse. K.A. ob er GPG bzw PGP benutzt (hat), aber irgendwann hat die Person oder Gruppe sich als relevant herausgestellt, Nachrichten, welchen heute entsprechend signiert sind und schon seit damals mit dem gleichen Schluessel signiert wurden, wuerden heute als echt angenommen. Auch dann, wenn die Person oder Gruppe von der NSA ausgetauscht bzw. unterwandert worden waere.

Nochmals, erstmal eine Thunderbird-Integration mit simpler Signierung (imho nuetzlich), dann kann man weitere sehen.

Sinnlos finde ich das ganze nicht, aber vllt. kannst du ja beitragen / helfen, dass es noch was wird.
Alle versuchen hier einen "down zunmachen", anstatt zu helfen...

Naja...als Argument zu bringen, das andere das Problem auch haben löst das Problem nicht wirklich. Aber das Fakeproblem bei einer Email belastet deinen Geldbeutel doch weniger als wenn du deine Bitcoins ins Spiel bringst.

Und ja, du hast recht, es ist noch kein Design. Du suchst die Türen und Fenster raus, legst die Ziegel fest, aber weist noch nicht was für ein Haus es wird, wie groß, ja...noch nichtmal ob es vieleicht Flachdach ist. Du kannst damit garnichts nachweisen, weil jeder sich am keyserver eintragen kann indem er einfach einen betrag von einer Bitcoinadresse transferiert und sagt das die Email ihm gehört. Du prüfst schliesslich nur die Transaktion und nicht die Email-adresse as solches.

Sinnlos was du da verzapfst.

Das ist aber auch ein Problem mit dem heutigen GPG/Enigmail und den Keyservern, oder irre ich mich. Wer zuerst kommt mahlt zuerst. Denn einen Publickey kann man leicht direkt auf den Keyserver importieren ohne dass die Email dabei gecheckt wird.


Der Kleinbetrag stellt sicher, dass der Account mit dem oeffentlichen Schluessel zusammenhaengt. Genauso wie Keyserver dies sicherstellen. Wenn man alle Keyserver austauscht, dann kann man auch die Signatur tauschen. Zmdst fuer alle die den oeffentlichen Schluessel noch nicht importiert haben. Man kann also bei allen mit den man zum ersten Mal kommuniziert sich als der Besitzer der Email-Adresse ausgeben. Die Blockchain entsprechend zuaendern duerfte um ein vielfaches schwieriger sein.


Bis jetzt ist da gar kein Design. Schritt eins waere erstmal ein Plugin, dass gegeben ein Keypaar einen simplen Datensatz signiert. Der oeffentliche Schluessel laege sofort in der Blockchain vor sobald dort eine Transaktion ausgeht. Dies beweist, dass jemand Zugriff auf den Privatekey hat. Das koennte man dazu nutzen den Besitz von etwas anzuzeigen: die erste Transaktione auf die E-mail entspricht dem gueltigen oeffentlichen Schluessel fuer die E-mail-Addresse. Das ist dann einfach eine Konvention. Das ist aber vorerst Kuer.


Nochmals, da ist ueberhaupt nichts hardwaremaessig notwendig: Blockchain entspricht Keyserver, Addon entspricht GPG/Enigmail.

Der erste Schritt waere erstmal das GPG-Analogon zu programmieren. Das ist schlicht eine Minimalwallet mit Input to Signatur(Input) Funktionalitaet.
Der zweite Schritt waere, dies in Thunderbird als Plugin einzubinden: Email als Input fuer oberes.
Der dritte Schritt waere, nun noch das ganze Transaktionsgeraffel zu implementieren. Und da es da um Geld geht muss das etwas sorgfaelltiger gemacht werden.

Vielleicht wirklich Schwachsinn das ganze, aber sonnen kleines Plugin (Schritt eins und zwei) waere doch ganz nuetzlich, da ja auch hier im Forum Addressen zum Identitaetsnachweis gepostet wurden. Und das macht keinen Sinn wenn das nur kompliziert zu nutzen ist. Ich z.B. habe noch keine Adresse zum Identitaetsnachweis angegeben, weils fuer mich persoenlich einfach zu umstaendlich ist bzw ich zu faul bin jedesmal eine Fullwallet zustarten. Das muss einfacher gehen. Imho wird das sonst nix mit dem Mainstream.

Und wie löst du das fake-problem?

Meine Email-adresse ist zb relativ bekannt, da ich ja auch Kleinhändler bin. Theoretisch kann jeder nun die Email-adresse eintragen und einen Key dazu hinterlegen. Eventuell wäre eine Aktivierungsmail eine Möglichkeit.

Was es bringen soll, da sman die Bitcoin-adresse checked erschliesst sich mir nicht. Es geht nicht drum nachzuweisen das die Bitcoin-adresse dir gehört sondern die Mail-adresse. Also muss man diese prüfen. Das Gedöns mit Transaktionen kannst also weglassen. Wenn ich nachweise das es meine Email-adresse ist kann ich eh nur signieren wenn ich den PrivateKey auch habe. Deine Überprüfung mittels absenden eines Kleinbetrages prüft eigentlich garnichts.

Und da komme ich zum Punkt, das ich mich Frage, wieviel Ahnung du eigentlich hast, wenn du schon im ersten Schritt derartige Desginfehler einbringst. Hier lässt es sich ja nun ausbessern, weil es viele lesen und sich Gedanken machen. Aber wie wird es im Code sein, wo eben nicht so viele prüfen. Ich denke, wenn du sowas programmierst such dir jemand der wirklich Ahnung von Design hat und nicht nur jemand der coden kann.

Im Prinzip hast du dein Design so gestaltet, als würdest du am Besitz des Nummernschildes festmachen wem das Auto gehört. Ich müsste also nur ein Nummernschild auf mich zulassen, an dein Auto montieren und dann könnte ich sagen, das dieses Auto mir gehört. So versuchst du eine x-beliebige Bitcoin-adresse dazu herzunehmen um nachzuweisen das diese Emailadresse demjenigen gehört(oder das er berechtigt ist einen Publickey für diese Email zu hinterlegen...was ja eigentlich das selbe bedeutet).

Unterm strich wird das also nur funktionieren, wenn du eine stabile Serverbasis bereit stellst. Der Code für das Addon ist kaum mehr als der Sprit im Tank eines Autos. Aber du musst zuerst das Auto bauen. Also einen Server mit entsprechendem Frontend, Datenbank, Zugriffstabil, Hacksicher, starkem Mailserver der auch akzeptiert wird bei den anderen Anbietern. Das setzt also mindestens einen großen Rootserver voraus, der dich auch mal locker 100Euro/mtl kostet.

Vieleicht ist das der Grund warum es noch keiner gemacht hat. Aber natürlich wäre es uns eine freude wenn du das bereit stellst. Das bischen Addon programmiert dann jemand schnell mal nach Feierabend. Soll heisen, die Arbeit ist nicht das Addon sondern das drum herum und solange das nicht steht ist es blödsinn ein Addon zu machen. Du weist ja noch nichtmal welche Schnittstelle dein Server haben wird auf den das Addon zugreifen soll.

Freut mich, nutzt selbst auch Thunderbird, und könnte "testen" wenn Interesse besteht.

Ok. Hab mich entschieden und mach das nun selbst.