Bergbau

Eine Alternative Anonyme Kryptowährung Apfelmünze Review

AppeCoin, Sergio D. Lerners Vorschlag für ein E-Cash-Programm, ist für ein Peer-to-Peer-Netzwerk konzipiert, das nicht auf eine vertrauenswürdige Drittpartei angewiesen ist. Wie die Kryptowährungen Monero oder Zcash ist AppeCoin ein Protokoll, das seinen Benutzern volle Privatsphäre garantieren soll. Lerners E-Cash-System nutzt das Münzmischen. Im Gegensatz zu ZeroCoin, wo die Geldeinheiten einen festen Wert haben und der Transaktionsbetrag aus der Anzahl der gesendeten Einheiten abgeleitet werden kann, ermöglicht es AppeCoin Benutzern, Transaktionsbeträge wirklich zu verstecken, indem sie die Option zum Teilen und Kombinieren von Münzen anbieten.

Hier finden Sie die aktuelle Version des AppeCoin-Entwurfs.

Übersicht:

Peers haben private Konten und können Geldeinheiten, sogenannte Rechnungen, an andere Peers senden. Die Rechnungssumme ist verschlüsselt und nur dem Rechnungsinhaber bekannt. Rechnungen können in kleinere Rechnungen aufgeteilt oder zu größeren Rechnungen kombiniert werden. Der Prozess des Rechnungssplittens und des Rechnungskombinierens kann durchgeführt werden, ohne den Wert der Rechnung oder ihrer Teile zu offenbaren. Zero-Knowledge-Beweise werden verwendet, um die Richtigkeit zu demonstrieren: Der Wert der Rechnung ist gleich der Summe ihrer Teile. Es gibt einen Mindest-Rechnungswert, um Inflation zu vermeiden.

Transaktionen an andere Peers können gesendet werden, ohne ihre öffentlichen Adressen durch universelle Neuverschlüsselung zu offenbaren. Sobald eine Zahlung gesendet wurde, muss sie vom Empfänger akzeptiert werden. Zahler und Zahlungsempfänger tauschen die geheimen Schlüssel der verschlüsselten Rechnung aus. Die Kommunikation zwischen Zahler und Zahlungsempfänger verwendet hybride Verschlüsselung und Entitätsauthentifizierung.

Die Community überprüft die Gültigkeit von Transaktionen und dass Münzen korrekt aufgeteilt oder kombiniert wurden. In einem "Proof-of-Work" -basierten Framework werden diese Änderungen in einem von den Minenarbeitern geführten Buch erfasst. Um die Anonymität zu erhöhen, bietet AppeCoin privates, delegiertes und öffentliches Bill-Shuffling. Die Richtigkeit der Shuffles wird von den Bergleuten verifiziert.

AppeCoin versucht sicherzustellen (siehe S. 6 im Entwurf):

Effizienz: geringe Transaktionswartezeit. Sicherheit: Keine Doppelausgaben, keine Mehrausgaben, Unverfälschbarkeit (von Rechnungen und Zahlungsprotokollen), Authentizität, Nichtabstreitbarkeit, Portabilität. Datenschutz: Anonymität (der Zahlungspflichtige kann nicht anhand von Daten identifiziert werden, die während der Zahlung ausgetauscht werden), unauffindbar (der Verlauf einer Rechnung nicht nachvollziehbar), nicht verknüpfbare Zahlungen, privater Kontostand, versteckte Transaktionsbeträge.

Die Schwierigkeit des entscheidungsbezogenen Diffie-Hellman-Problems und des Darstellungsproblems sollte Sicherheit und Datenschutz garantieren, solange das verwendete Verschlüsselungsschema Ciphertext-only-Angriffen und Chosen-Plaintext-Angriffen widersteht.

Weitere Details:

Im Folgenden beschreiben wir einige wichtige kryptografische Bausteine ​​und Algorithmen, die im AppeCoin-Protokoll verwendet werden.

A. 1: Universal Re-Encryption von Schnorr Public Keys: Eine Rechnung enthält den öffentlichen Schlüssel des aktuellen Rechnungsinhabers.Durch die universelle Neuverschlüsselung wird der öffentliche Schlüssel des Rechnungsinhabers neu verschlüsselt, ohne dass er seinen privaten Schlüssel ändern muss.

A. 2: Bill Shuffle: Der BillShuffle-Algorithmus mischt die Banknoten und liefert einen Null-Beweis-Beweis für die Richtigkeit des Mischens. Die Eingabe des BillShuffle-Algorithmus ist eine Liste A = (a1, ..., an) von Rechnungen ai mit i = 1, ..., n und seine Ausgabe ist eine Liste B = (b1, ..., bn) wobei bi die Verschlüsselung von ist aπ (i) für eine Permutation π mit dem Verschlüsselungsschlüssel k.

Im AppCoin-Vorschlag werden zwei Proof-Systeme berücksichtigt. Beide wenden die Fiat-Shamir-Heuristik auf ein interaktives öffentliches Münzprüfsystem an. Das vorgeschlagene zweite Beweisverfahren verwendet einen (pseudo-) zufälligen Teilsatztest, der es effizienter macht. Zero-knowledge wird erreicht, indem der Verschlüsselungsschlüssel geblendet wird und dem Verifizierer nur das Bild oder Urbild einer zufällig ausgewählten Teilmenge unter der gegebenen Permutation π gezeigt wird, aber nicht die Teilmenge selbst. Der Prüfer verpflichtet sich zur Verschlüsselung des Produkts der Elemente der Teilmenge. Die angenommene Härte des Darstellungsproblems macht es schwierig, das Produkt nur zu erraten.

A. 3: CoinSplitting: Die Eingabe des CoinSplitting-Algorithmus ist eine Rechnung a und erzeugt eine Ausgabe von zwei Banknoten b und c, deren Werte sich zum Wert von Rechnung a addieren. Der Algorithmus liefert einen Null-Wissens-Beweis für die Richtigkeit.

Der Betrag v einer Rechnung ist im Exponenten verborgen, d. e. als xv. (Beachten Sie, dass sich die Potenzierung im Vorschlag auf eine homomorphe Verschlüsselung bezieht). Die Kernidee des CoinSplitting-Algorithmus zum Beweis des Gleichgewichts, d. e. va = vb + vc, soll die Korrektheit der Gleichung xva = xvb × xvc überprüfen. Ein Blindheitsfaktor wird verwendet, um den Anteil zu verkleiden: xkva zk = xkvb zkb × xkvc zkc mit k = kb + kc für zufälliges kb und kc. Der Prüfer ändert Exponenten oder multipliziert Faktoren und stellt dem Verifizierer Wissensnachweise zur Verfügung.

A. 4: InRangeProof: Die Eingabe für den InRangeProof-Algorithmus ist eine Rechnung und ein Bereich für dessen Wert. Wenn die Rechnung in dem gegebenen Bereich liegt, ist die Ausgabe des Algorithmus 1.

A. 5: SendBill: Diese Aktion enthält zwei Algorithmen, die eine öffentliche und eine private Nachricht erzeugen.

Öffentliche Nachricht: Diese Nachricht wird über das Netzwerk verteilt und enthält den Hash des öffentlichen Schlüssels des aktuellen Rechnungsinhabers sowie die Zieladresse und Signatur des Absenders.

Private Nachricht: Diese Nachricht wird privat vom Absender an den Empfänger der Transaktion gesendet, und ist im Wesentlichen die Verschlüsselung der geheimen Schlüssel der Rechnung, so dass der Empfänger die Menge überprüfen und ändern kann die Rechnung.

A. 6: ReceiveBill: Der Empfänger überprüft die Identität des Absenders und überprüft, ob die Rechnung und die Menge, die an ihn gesendet wurde, korrekt sind.

A. 7: Öffentliche Überprüfung der Transaktion: Bergleute suchen nach der Seriennummer der Rechnung im Hauptbuch und verifizieren, dass die Rechnung nicht ausgegeben wurde und dass die Schnorr-Unterschrift des Absenders korrekt ist. Die öffentliche Adresse des Absenders ist vorübergehend sichtbar, bis sie durch erneute Verschlüsselung getarnt ist.

Kommentare:

Wir denken, der AppeCoin-Vorschlag ist aufregend und möchte einige seiner starken Punkte kommentieren und auf Orte hinweisen, von denen wir denken, dass sie mehr ausgefüllt werden sollten.

Ad A. 1: Universal Re-Encryption:

a) Anstelle des rechnerischen Diffie-Hellman (CDH) sollte der entscheidungsgebende Diffie-Hellman (DDH) angenommen werden (AppeCoin-Entwurf, S. 8).

b) Der AppeCoin-Entwurf behauptet, dass die universelle Wiederverschlüsselung für jedes Verschlüsselungsschema sicher ist, das Ununterscheidbarkeit erfüllt, aber keine Referenz bereitstellt. Young / Yungs Artikel Semantisch sichere Anonymität: Grundlagen der Re-Encryption zeigen die Sicherheit für ein solches Verschlüsselungsschema, die ElGamal-Verschlüsselung.

Anzeige A. 2: BillShuffle:

a) Sicherheitsaspekte: Für die Behauptung, dass BillShuffle einen nicht-interaktiven Null-Wissensbeweis bereitstellt, ist ein formaler Nachweis erforderlich.

Die Fiat-Shamir-Heuristik ist eine gängige Methode, um einen konstanten runden interaktiven Beweis in einen nicht interaktiven Beweis zu verwandeln. Die Heuristik hat sich als sicher erwiesen, d. e. rechnerisch fundiert, im zufälligen Orakelmodell. Einige Beispiele für unsichere Transformationen existieren im einfachen Modell, aber die Fiat-Shamir-Heuristik, die auf interaktive Beweise angewendet wurde, nicht nur Argumente, wurde kürzlich unter bestimmten Bedingungen für die beteiligten Hash-Funktionen als sicher bewiesen. Siehe Tauman-Kalai / Rothblum / Rothblum.

Für die Sicherheit des BillShuffle-Algorithmus gibt es einige Hinweise, aber im Entwurf gibt es keinen formellen Sicherheitsnachweis. Die Vollständigkeit ist einfach. Der Artikel von Tauman-Kalai / Rothblum / Rothblum könnte andeuten, dass der BillShuffle-Algorithmus selbst im einfachen Modell rechnerische Solidität erfüllt: Die Fiat-Shamir-Transformation wird auf Proofs angewendet. Obwohl es plausibel erscheint, dass Zero-Knowledge aus der Stärke des Verschlüsselungsschemas abgeleitet werden kann, fehlt der erforderliche Zero-Knowledge-Simulator.

b) Leistung: Das Proofsystem mit dem Random-Subset-Test benötigt einen Durchschnitt von Runden * 3/2-Exponentiationen, um ein Mischen von n Rechnungen zu beweisen und zu verifizieren, was zu einer sehr schnellen Laufzeit führt. [Vergleiche das Shuffle-Protokoll mit Abe (22 * n log⁡ (n) Exponentiationen), Sako-Kilian (642 * n Exponentiationen), Furukawa oder Groth oder Lipmaa-Fausti / Zajac (mit Paarungen: etwa 3n), Lindell-Pinkas ( cut-and-choose auf Schaltungen, etwa 15qn + 39n + 10q + 6 Exponentiationen, wobei q ein statistischer Sicherheitsparameter ist]].

Die privaten Schlüssel von Shuffle-Teilnehmern sind möglicherweise anfällig für Seitenkanalangriffe, da ein Teilnehmer eines Shuffle alle verschobenen Rechnungen entschlüsseln muss, bis er seine eigenen findet, was einen Durchschnitt von n / 2 Aufrufen seines privaten Schlüssels verursacht.

c) Technische Bemerkungen:

  • In Abbildung 4 fehlt die Definition von bw als bw: = awk.
  • In Abbildung 7, p. 13 sollte Blob D mit s beginnen (Anzahl der Runden), um den gleichen Hash H (C) wie im Beweis zu haben;
  • In Abbildung 7, p. 13, bj in 8. 2. 3 sollte mit aQ (s, i) in 9 ausgetauscht werden. 2. 3;
  • In Abbildung 8, p. 14, in 14. 1. 1. 3, sollte ts × k durch rs × k ersetzt werden. Index s sollte j sein. Ähnliches gilt für ts × k-1 in 1.4. 2. 1. 1.

Ad A. 3: CoinSplitting:

a) Sicherheitsaspekte: Für die Behauptung, dass CoinSplitting einen fehlerfreien Beweis für die Richtigkeit liefert, ist ein formaler Beweis erforderlich.

Heuristisch erschwert das Problem des diskreten Logarithmus es dem Prüfer, den Verifizierer zu betrügen, indem er die Exponenten wechselt. Der Prüfer könnte versuchen, einen Teil von vb in den Exponenten des Nachbarfaktors z zu schieben, aber er müsste den Logarithmus des Blindheitsfaktors (der nachweislich zufällig ausgewählt werden sollte) in Bezug auf den Basispunkt oder in Bezug auf x kennen . Der Entwurf fehlt jedoch ein formaler Beweis für die Richtigkeit. Obwohl wir keine Beweise finden konnten, dass der Beweis in CoinSplitting Informationen leckt, liefert der Entwurf keinen formellen Beweis für Zero-Knowledge.

b) Leistung: Der Nachweis und die Verifizierung für zwei Rechnungen erfordert 12 Exponentiationen und viele zk-Beweise für die Kenntnis der Verschlüsselungsschlüssel (z. B. Verwendung des Schnorr ID-Protokolls im Falle eines Pohlig-Hellman-Verschlüsselungsschemas). Der Autor des Vorschlags, Sergio Lerner, hofft, dies in Zukunft zu verbessern.

c) Technische Bemerkungen:

  • In DecompProof1, p. 23, schlagen wir vor, bu als bu = a'u zu definieren, d. e. , bu = auk qb; sonst bt = aber nicht halt;
  • In DecompProof1, p. 23, Schritt 6 sollte analog zu Schritt 3 sein.

Weitere Ressourcen

APPECoin, ein System mit vollständiger Anonymisierung - Schlüssel Design Punkte

APPECoin (anonyme Peer-to-Peer elektronische Münze) Design (2012)

AppeCoin Anonymous Cryptocurrency Draft (2014)

Wenn Ihnen dieser Artikel gefällt, könnte Ihnen auch gefallen:

zk-SNARKs Technisch erklärt: Grundprinzipien

Quantenresistenter öffentlicher Schlüsselaustausch: Das supersinguläre Isogene Diffie-Hellman-Protokoll

Vergleich der Kryptowährungsentwicklungen

Einige Kommentare zur Sicherheit von ECIES mit secp256k1