Bitcoin Forum

Hallo,

warum gibt es eigentlich kein Thunderbird Bitcoin-Plugin fuer Signierung von Nachrichten mit Wertueberweisungsfunktionalitaet?

Ich stelle mir das wie Engimail vor:

   1. es gibt irgendwo eine vertrauenswuerdige Liste wo man seinen oeffenlichen Schluessel + Email-Adresse hinterlegen kann:
      - z.B. in der Blockchain, hehe
      - e-mail-Adressstring erzeugt Bitcoin-Adresse (das ist trivial)
      - eine klitzekleine Ueberweisung von Adresse des Privat/Public-Schluesselpaars zeigt Besitzer an
      - zweite solche Ueberweisung zeigt an, dass Schluesselpaar nicht mehr gueltig ist
      - D.h., wer zuerst drauf ueberweist ist der Besitzer, gilt auch nach ungueltig machen
      - wuerde Run auf aus lesbaren Strings erzeugte Bitcoin-Adressen hervorrufen (gibt aber glaub ich Loesungen die das verhindern)
      - irgendwie so, geht vllt auch noch geschickter
   2. man signiert mit privatem Schluessel
   3. Privater Schluessel liegt symmetrisch verschluesselt auf einem Spechermedium vor (HD, USB-Stick etc.pp.)
   4. man kann Zahlungen ueber den Email-Account empfangen, d.h. in dem Plugin waere eine Minimalwallet enthalten.

Oder gibt es das schon? Klar, bitcoinqt enthaelt diese Funktionalitaet, aber es ist so einfach zu kompliziert ( ;D schoenes Oxymeron).

Man wuerde also sozusagen zu GPG noch die zusaetzliche Geldueberweisungsfunktion hinzufuegen und die Nutzung im "Mainstream" von Bitcoin weiter forcieren. Denn jeder, der das Plugin benutzen wuerde, waere automatisch Clubmember.

Kam mir grad so als Idee ...

Es gibt doch hier einige Leute die viel (nach) programmieren. Macht mal was Neues. Ich koennte mich auch beteiligen.

BTW, kann den Fred jemand in Projektentwicklung schieben, ich denke da gehoert der eher hin???

Ok. Hab mich entschieden und mach das nun selbst.

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

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.

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.

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.

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...

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.

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.

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.

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.

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 ;D.

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

Gruss,
cu

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...

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.

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"

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.

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 ;)

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"? gatesb@microsoft.com 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 ;D
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.

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 Hans.Mustermann@gmx.de 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.

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

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

Moin,

hab mal den Faden in Gaenze ueberflogen. Wichtige Fakten zu euren Kommentaren und nochmals vielen Dank fuer die Diskussion:

   (i) Das Tool soll nicht verschluesseln sondern nur signieren!
   (ii) Das Argument, dass asymmetrische Verschluesselung salopp gesagt "unsicher" ist gilt nicht, denn dann waere Bitcoin selbst "unsicher".
        Hier gibt es jedoch den kleinen Unterschied, dass Bitcoins selbst vor Quantencomputern sicher sind, solange sie auf Adressen gelagert
        werden, von welchen noch keine Transaktion abgeschickt wurde. Der entsprechende oeffentliche Schluessel wurde dann noch nicht in die
        Blockchain geschrieben. Zmdst verstehe ich das System so ...
   (iii) Aus den Email-Adressstrings lassen sich Bitcoinsadressstrings erzeugen. Ist eine Email-Adresse zu lang muessen mehrere Bitcoinadressen
         erzeugt werden. Eine Transaktion auf diese Adressen von einer Urspungsadresse markiert diese Ursprungsadresse als Besitzer der Email-
         Adresse. Der private Schluessel zur Ursprungsadresse wird dann zum Signieren von Nachrichten benutzt.
         Bekommt jemand eine Mail mit einer Signierung kann man die Signatur zur entsprechenden Bitcoinadresse umwandeln (sehr einfach via
         bitcoinj), und in der Blockchain nachgucken, ob die erste Transaktion dieser Adresse auf Bitcoinadressen verweisst, welche der Email-Adresse
         der Nachricht entsprechen.
   (iv) Eleganter scheint mir, waere es Namecoin zu verwenden. Jedoch
      (a) macht Namecoin das Tool fuer Max Mustermann noch komplizierter;
      (b) lass ich erst kuerzlich, dass Namecoin-Mining von einem Pool dominiert wird (muss den Link noch rauskramen);
      (c) Namecoin fuer Entwickler nicht so handlich ist wie Bitcoin (exisiert ein namecoinj???).
   (v) Es ist in der Tat ein Problem, dass
      (a) man Email-Adressen registrieren koennte ohne sie zu benoetigen;
      (b) der Besitz von Email-Adressen nicht verfaellt;
      (c) verlorengegangene Privatekeys zu Email-Adressen diese nicht mehr nutzbar machen, siehe (b).
   Wiederum, mit Namecoin waere das eleganter zu loesen! Wenn ich mich richtig erinnere verfallen bei Namecoin registrierte Eintraege insofern sie
   nicht reregistriert werden.

Fuer (v) gibt es zwar zu Namecoin alternative Teilloesungen, die sind aber in ihrer aktuellen Ausarbeitung ziemlich haesslich.

Nein, sondern ein Java-Framework fuer die Entwicklung von Namecoin-Software. C/C++ ist mir dann doch zu unhandlich.

Gruss,
cu

Hierfuer gaebe es eine eigentlich gar nicht so unelegante Loesung. Man muesste aber ein ausgearbeitetes Protokoll spezifizieren, welches das Tool akzeptiert.

Z.B. koennte eine Registrierung fuer maximal ein Jahr gelten, dann muesste neu registriert werden. D.h. das Tool akzeptiert die Signaturen nur, wenn zwischen der Registrierung der Email-Adresse und deren Nutzung maximal ein Jahr liegt. Um zu verhindern, dass, wenn man neu registrieren muss, einer einem die Adresse wegschnappt, wird dem aktuellen Besitzer die Moeglichkeit gegeben, z.B. zwei Wochen vor Ablauf des Jahres eine Neuregistrierung fuer ein weiteres Jahr durchzufuehren. Wie gesagt, ob ein anderes Tool dieses Protokoll akzeptiert ist eine andere Frage, fuer Emails die Mithilfe des Tools erstellt wurden wuerde aber das Pruefen von Signatueren mit Hilfe der Blockchain und des Protokolls funktionieren. Und Email-Adressen wuerden auch wieder frei werden.

Ja ich weiss, dafuer ist eigentlich Namecoin da, aber meine Gruende gegen Namecoin habe ich oben schon dargelegt.

Okay, also die Bitcoin-Adresse, die du aus der Email-Adresse erzeugst, wird nicht für den Empfang genutzt, sondern lediglich als "Marker" für die eigentliche Empfangs-Adresse.
Da sehe ich dann das folgende Problem:
1. ich habe eine Email-Adresse, nennen wir die mal mymail@example.ex
1. ich erzeuge aus mymail@example.ex die Email-Bitcoin-Adresse, nennen wir die mal 1myEmailBTCAddress
2. ich mache mir eine andere Adresse, die in Zukunft meiner Email-Adresse zugeordnet sein soll, die nennen wir mal 1myRealBTCAddress
3. ich schicke 0.00001 BTC von 1myRealBTCAddress nach 1myEmailBTCAddress
4. jetzt habe ich also eine öffentliche Zuordnung von mymail@example.ex zu 1myRealBTCAddress
5. wenn ich eine andere Bitcoin-Adresse registrieren möchte, muss ich vorher noch mal 0.00001 BTC von 1myRealBTCAddress nach 1myEmailBTCAddress schicken
6. wenn ich aber den Private key zu 1myRealBTCAddress verliere, kann ich die Zuordnung von mymail@example.ex zu 1myRealBTCAddress nie wieder löschen
6.a. ich kann auch keine neue Adresse zu mymail@example.ex registrieren.
6.b. für mich sind also praktisch sowohl die Email-Adresse mymail@example.ex als auch die Bitcoin-Adressen 1myEmailBTCAddress und 1myRealBTCAddress "verbrannt"
6.c. ich kann aber auch nicht öffentlich darauf hinweisen, dass man da keine Zahlungen mehr hinschicken soll
6.d. jemand, der mich kennt, wird möglicherweise Geld an 1myRealBTCAddress senden, ohne dass ich darauf zugreifen könnte

Scheint mir ehrlich gesagt mittel- und langfristig mehr Probleme zu erzeugen als es löst.
Ich würde niemandem dazu raten, das Tool zu verwenden.

(a) dein Tool soll dem User doch die Arbeit abnehmen, da sollte die Komplexität im Hintergrund keine Rolle spielen
(b) keine Ahnung, wie die Verteilung der Rechenleistung bei NMC im Moment ist. Aber: eine 51%-Attacke ermöglicht Double-Spending, aber keineswegs das "stehlen" von Domain-Namen oder anderen Einträgen in der Namecoin-Datenbank. Für deine Anwendung ist das also ein Nicht-Problem.
(c) für die Funktionen Signieren und Adressen erzeugen sollten die Werkzeuge von bitcoinj oder bitcoinjs o.ä. ebenfalls verwendbar sein, ggf. mit kleinen Anpassungen. Das müsste man sich aber im Detail ansehen.

Ja, Namecoin ist da die Lösung, mit Bitcoin ergibt das IMHO keinen Sinn.

Nein, du suchst nur Ausreden gegen Namecoin, weil du die Befürchtung hast, dass das komplizierter wird. ;)
Nimm es als Ansporn, deinen Horizont ein wenig zu erweitern ;D

Du musst aber auch den Text ueber der Aussage kommentieren. Sonst ist das irgendwie Cherrypicking  :P.

Eigentlich bin ich der Meinung, dass Namecoin genau das ist was ich brauche. Ist wie mit XML und ner aequivalenten Tabelle. Da nutz ich doch lieber XML zur Verkapselung meiner Daten, dafuer ist es gemacht. Jedoch straeuben sich mir momentan noch die Haare in den Code der Orginalclienten einzutauchen, das stimmt wohl. Aber vielleicht hat ja jemand Lust sich mit seiner Erfahrung zu beteiligen.

Wie auch immer, das ist eh noch Zukunftsmusik und ich lass das erstmal sacken, eins nach dem anderen.

Man nennt das landläufig auch quotemardern und ich mach das gern :P

So, muss denn wohl auch mal wieder nen Kommentar verfassen. Aktuell grueble ich ja noch ueber pay-to-hash-script nach. Damit kann man ziemliche coole Sachen machen. Aber im Zusammenhang zum Signaturkram fehlt mir eine geniale Idee.

Der Kollege Chefin hat das schon richtig erkannt, eigentlich benoetigt man jemanden, der die Identitaet und Signatur hinter einer E-mail garantiert. Leider scheinen da zentralisierte Loesungen die einfachsten zu sein ... aber ne P2P-Loesung ... ???

Z.B. koennten Xapo, Bitcoin.de u.ae. sowas uebernehmen, die Leute muessen sich bei denen ja sowieso identifizieren. Aber wenn die kompromitiert sind, sind frueher oder spaeter auch die Signaturen kompromitiert.

Ich knoble aber weiter ...

Wenn du das Problem sauber löst, lass es dir patentieren. Danach kannst du dir Apple kaufen. Immerhin versucht der Staat schon seit Jahrtausenden seine Einwohner 100% sicher zu identifizieren ohne Fälschungsmöglichkeit. Bisher erfolglos. Alle Ausweise wurden gefälscht, die Kontrollen die das verhindern könnten sind derart aufwendig, das sie unbrauchbar sind.

Und daher nützt der sicherste Hash nichts, wenn ich ihn umgehen kann statt zu knacken.

Man könnte zwar biometrische Merkmale einbringen die Unique sind, aber das ist es ja was wir NICHT wollen. Es muss wechselbar bleiben, damit wir, wenn der Key komprimittiert ist, den Key ändern können. Weder Finagerabdruck, noch Iris, noch DNA ist wechselbar.

Allerdings bewegst du dich inzwischen aufs richtige Ziel zu. Sobald dieser Knoten gelöst ist, hätten wir eine Technik, die funktioniert wie wir es uns wünschen. Zb wenn man den Hash der DNA zugrunde legen würde, den man mit einem geheimen Key mischt, so das man über die DNA immer nachweisen kann, das der Key zu einem gehört oder nicht ohne die DNA selbst zu veröffentlichen. Nur das dies ein sehr aufwendiger Weg ist. Man muss immer beweisen können das der Key nie aus dieser DNA erstellt werden konnte. Also eine DNA muss immer zu einer Menge an Schlüssel führen, die ausschliesslich aus dieser DNA erstellt werden konnte. Beispielsweise ein Key mit 2^256 Möglichkeiten, die aber alle auf die selbe DNA zurück zu führen sind. Das bedeutet das wir mindestens einen Schlüsselraum von 2^512 benötigen. Damit sind 2^256 verschiedene Schlüsselräume möglich. Davon ausgehend das 2^256 Möglichkeiten nicht innerhalb der Restexistenz unseres Sonnensystems berechnet werden können.

Das mal so als Brainstorming, wobei ich die DNA wiederum für unzuverlässig halte, da sie inzwischen behördenseitig bekannt ist und leicht eingeholt werden kann. Und dann lässt sich damit ein key faken und einem dritten unterjubeln.

Vieleicht könnte ein wechselseitiges aufeinander aufbauen der Keys eine Lösung sein. Mein Key baut auf deinem Key auf, den du nutzt und dann wiederum änderst du deinen Key aufbauen auf meiner Antwort bzw der darin benutzten Verschlüsselung. Setzt voraus, das man immer nur im Wechselsprechverfahren kommunizieren kann oder einen key doppel benutzt.

Vieleicht kann man daraus einen Ansatz konstruieren. In jedemfall muss man verhindern, das jemand einen key erzeugt und mir unterschiebt der nicht der ist der er vorgibt zu sein. Und das bleibt dann bei dem Problem hängen, das man jemanden identifizieren muss ohne ihn eindeutig zuzuordnen(wir wollen kein tracking, Abstreibarkeit der Kommunikation).

Noch ein Gedanke: eine Änderung eines keys einer Emailadresse muss immer aus dem letzten Key abgeleitet werden. Dabei darf es nicht rückrechnebar sein, da der letzte Key ja bekannt ist(komprimittiert) und so darf er nur als Seed dienen. Aber da muss man das Problem lösen, das jeder den Seed nutzen könnte und ab dann multiple gültige Keys möglich wären. Eine 1:1 Zuordnungen wäre hirnlos. Eine Oldkey + Zufall = Newkey wäre wiederum fakebar, da ab jetzt mehrere Menschen keys erzeugen könnten...alle die den Oldkey haben.

Vieleicht kannst du mit den Anregungen etwas anfangen, ansonsten denk dir was eigenen aus.

Hau rein.

Zentralisierte Lösungen sind da extrem schlecht, wie man bei den Online-Banken deutlich sieht. Es scheint kein grosses Problem darzustellen, mit einer Fake-Identität oder geklauten Papieren ein Bankkonto zu eröffnen. P2P bzw. Face2Face sieht die Sache deutlich anders aus. Daher halte ich Community Prozesse (PGP/GPG Signaturen) für sinnvoller. Gibt zwar keine garantierte/absolute Sicherheit, liegt aber dennoch weit vor den zentralen Ansätzen die praktisch nur mit Gewalt halbwegs durchgesetzt werden können.

Bevor das Argument kommt - ja es ist unbequem, wenn man sich dafür mit (möglichst vielen) anderen Menschen persönlich treffen muss.

Face to Face Beglaubigung ist unsicher. Den was sind viele? 10 Menschen die dich "beglaubigen"? Das faked eine Behörde locker. 100 Menschen? Was meinst du wie elitär das ganze dann wird und wie unbrauchbar?

Und sobald geschickt genug Gerüchte über Infiltration gestreut werden, zerbröselt das Vertrauen.

Face to Face ist Emotionen und daher nicht mehr logisch. Nur reine Berechnung ohne Emotionen kann den Anspruch erfüllen, unbestechlich zu sein. Menschen wären Bestechlich. Es kommt da natürlich auf die Moralvorstellungen des einzelnen an. Aber im prinzip müsstest du einen Menschen beglaubigen der gerade mit der noch rauchenden Waffe neben deinem erschossenen Kind steht. Beglaubigung ist Beglaubigung. Ich kenn jetzt keinen Menschen der das könnte. Und so hat jeder seine persönliche Grenze an der er bereit ist auch mal fakes zuzulassen um ein höheres Ziel zu erreichen.

Damit braucht man nur noch das Scenario aufbauen und ihm glaubhaft vermitteln. Und schon wäre er auch mal bereit zu lügen. Ab dann hast du Schläfer im System oder Sockenpuppen die weitere Fakes ermöglichen und das System manipulieren können. Menschen sind keine Computer. Versuch einen Computer zu überreden den key rauszurücken. Es gibt keine Drohung die das möglich macht. Siehe Sony PS3, da hat man den Verschlüsselungschip zerstört und seziert um an die Verschlüsselung ranzukommen. Du kannst keine Playstation mit irgendwas bedrohen, damit sie den key rausrückt oder ignoriert. Deswegen vertrauen wir einer verschlüsselten Email, weil der Computer nicht lügt.

Zumal das Gesicht keine einwandfreie Identifizierung erlaubt.
Sprichwörtlich hat jeder Mensch zig Doppelgänger, das mag richtig sein oder nicht, in keinem Falle aber sollte man sich darauf verlassen, dass ein Mensch keinen hat.
http://www.twinstrangers.com ;)

Definitiv, selbst meine Mutter hat schon einen Doppelgänger angepflaumt, weil sie ihn in der Stadt gesehen hat und auf meinen Namen natürlich nicht reagiert hat. Erst im direkten Face to Face und nach dem zweiten Satz erkannte sie ihren Fehler. Es dauerte aber noch weitere 10 Jahre bis ich ihn kennengelernt habe.

Aber unabhängig von Verwechslungsgefahr, hat Face to Face eben das Lügenproblem. Menschen lügen. Je nach Motivation mal mehr mal weniger und für den heroischen Zweck auch mal ganz massiv. Wir haben nicht die Möglichkeiten Seilschaften im Hintergrund zu erkennen, dazu fehlen uns die nötigen Daten.

Face to Face heisst auch, dass der entsprechende z.B. seinen Ausweis und Führerschein dabei hat. Und ja, die können auch gefälscht sein. Irgendwann sind wir dann an einem Punkt ab dem es keinerlei sichere Authentifizierung mehr gibt. Eine entsprechende Behörde kann jede beliebige Identität erstellen.

Nicht jede beliebige. Das ist doch das Schöne an Bitcoin, wir haben nicht fälschbare Identitäten, deren Aktivitäten sich nachvollziehen lassen.
Aber ist schon klar was du meinst, es gibt natürlich genug Anwendungsfälle, in denen wir auch eine Person zur Identität brauchen und spätestens da beginnt die Domäne der Autoritäten.

Und genau diese Eigenschaften müssen zusammen kommen. Einerseits die Fälschungssichereit der Kryptografie und andererseits die Bindung an eine Identität ohne dabei zum gläsernen Mensch zu werden. Und das dann in Code giessen.

Muss das sein? ::)
Nein im Ernst, der "richtigere" Weg ist doch wohl eher, dafür zu sorgen, dass eine solche Zuordnung von Prozessen zu Personen einfach seltener notwendig wird. Dann spart man sich den Intermediär für die Personen-Identifikation.

Stellt natürlich Teile unseres juristischen Gebäudes auf den Kopf, aber was soll's? ;)

Wenn du etwas NICHT an eine Person bindest besteht kein Risiko es zu missbrauchen zum eigenen Vorteil. Da im Business aber immer einer in Vorleistung gehen muss, öffnest du damit dem Missbrauch Tür und Tor.

Das virtuelle Objekt(ein Account, ein Login, eine wie auch immer gestalteter Zugang) ist emotionslos und moralfrei. Es ist ein Werkzeug, wie die Axt. Die Axt ist nicht böse, der Mensch der sie führt kann böse sein. Und bindest du etwas NICHT an eine Person, kannst du auch nie Vertauen dazu aufbauen. Du kannst dem Account SebastianJu nicht trauen, nur der Person die den Account besitzt. Oder noch genauer: pazor kannst du nicht mehr trauen...da dieser Account gehackt wurde. Der Person(pazor_true) kann ich weiterhin trauen.

Und deswegen ist völlig frei nur bedingt brauchbar und stösst schnell an die Grenzen. Man kann auch noch so gut aufpassen, es ist unvermeidlich das mal was schief geht. Es gibt keinen perfekten Menschen, im gegenteil...aber man kann ihnen trauen. Jedoch nicht einem Account der nicht so fest an den Mensch gebunden ist wie seine Hand. Aber ohne den Faktor das jeder nun die Fingerabdrücke kennt.

Das würde ich anders sehen.
Ich kann weder dem Account noch der Person trauen in irgendeinem "absoluten" Sinne.
Ich kann nur für jede Interaktion mit Person oder Account für mich das Risiko des Missbrauchs in Relation zum Nutzen abschätzen.
Ergibt sich dabei, dass mein Risiko geringer ist als der Nutzen aus meiner Vertrauensstellung, lohnt sich "der Deal".
Schätze ich mein Risiko aber höher ein als den Nutzen, sollte ich es lieber bleiben lassen.
Der Account hat hier lediglich insoweit eine Sonderstellung, als ich unter der Voraussetzung, dass er nicht gehackt ist, davon ausgehen kann, dass ich dem Account ebenso trauen kann wie der Person dahinter. Allerdings besteht immer ein Risiko des Hackens, womit mein Vertrauen in den Account zwangsläufig immer kleiner als das Vertrauen in die Person sein wird.

Diese schlussfolgerung ist falsch.

Man kann dem Account nicht weniger trauen sondern garnicht.

Der Account macht immer das was der Mensch macht der Zugriff hat. Du MUSST immer das vertrauen in den Menschen haben. Machst du das anders, merkst du nicht, wann er gehackt worden ist, bis du Opfer bist. Den wenn du dem Account auch nur 1cm weit traust, könnte ein Hacker genau diesen Punkt treffen und dich überlisten.

Wenn du aber immer den Mensch verifizierst bevor du eine Aktion startest, passiert das nicht. Aber das heist im Umkehrschluss dem Account null trauen. Dir fehlt nämlich die Information wann sich etwas verändert(sprich ein Hacker zugriff bekommt).

Natürlich ist es dann eine weitere Frage, in wie fern du Sebastian traust. Sagen wir es so, wenn du deine Freundin nackt neben ihn legst, dürfte das Risiko betrogen zu werden höher sein, als wenn du ihm 0,5btc in Escrow gibst. Also immer eine Abwägungssache.

So wie in meiner alten Firma. Anfang der 90er wurde Spesengeld oftmals vorschüssig gezahlt, Kreditkarten waren noch nicht sehr verbreitet. Eine Firma mit 50 Monteure hat da Montag morgens schnell mal 100.000 oder 150.000DM Spesengelder bereit halten müssen. Firmenumsatz 100 Millionen...so nebenbei als Info. Geholt haben wir Monteure das Geld selbst von der Bank. War schon ein geiles Gefühl, wenn man 100er und 500er im Beutel rumschleppt der mehr wiegt wie ne Flasche Bier. Ich fragte dann mal, wieso die Firma so ein Risiko eingeht und uns Monteure das holen lässt.
Die Antwort: Ihr verdient ziemlich gut, Geldmangel habt ihr kaum. Und wenn du wirklich wegen 150.000 DM das Land verlassen willst, bitte. Dir reicht das wenn du sparsam bist 2-3 Jahre, dann musst du doch wieder arbeiten. Nur hier in Deutschland kannst du dich nicht mehr Blicken lassen für lange lange Zeit. Für die Firma ist das ein Verlust, aber eigentlich Portokasse. Also war ich 150.000 DM Vertrauen wert. Natürlich muss man auch berücksichtigen, das ich Anlagen aufgebaut habe die Millionen gekostet haben. Wenn ich Fehler mache können da schnell 6 Stellige Summen flöten gehen. Es ist also Abwägung und deswegen ist die Maximalsumme auf diese 150.000DM begrenzt. Wenn mehr benötigt wird, wird es von 2 Kollegen geholt meist am nächsten Tag nochmal. Oder zumindest wusste man erst irgendwann danach das am selben Tag der Kollege auch geholt hat. Viel fragen stellen habe ich mir verkniffen, da dann leicht dieses vertrauen verspielt wäre. Den wer viel fragt, könnte unter Umständen ja auch was planen