Thunderbird Bitcoin-Plugin fuer Signierung von Nachrichten

[Christian1998]

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

[curiosity81]

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.

[curiosity81]

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

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

Gruss,
cu

[curiosity81]

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

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.

[qwk]

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

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.

  (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???).

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

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

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

[qwk]

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

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

[curiosity81]

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

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

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

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.

[qwk]

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

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

[curiosity81]

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

[Chefin]

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.

[mezzomix]

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

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.

[Chefin]

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.

[qwk]

Face to Face Beglaubigung ist unsicher.

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

[Chefin]

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.

[mezzomix]

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.

[qwk]

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.

[Chefin]

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.

[qwk]

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?

[Chefin]

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.

[qwk]

Du kannst dem Account SebastianJu nicht trauen, nur der Person die den Account besitzt.

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.