Newsticker

Corpus Ventures startet DM3: Wallet-zu-Wallet-Mails durch ENS

Themenschwerpunkt Standort Deutschland

Alles wollen es, aber es fehlt ein Standard: Wallet-zu-Wallet-Mails werden kommen, doch noch tobt ein Kampf darum, welches Protokoll sich durchsetzt. Mit DM3 wirft Corpus Ventures aus Mittweida seine Version in den Ring.

1. Wallet-zu-Wallet-Nachrichten

Manche Sachen liegen so nahe, so unmittelbar auf der Hand, dass es schwer fällt, zu begreifen, dass es sie nicht gibt. Eine dieser Sache sind Wallet-to-Wallet-Nachrichten: Textnachrichten, die man von einer Wallet zur anderen sendet.

Die Voraussetzungen sind perfekt: Jeder User von Kryptowährungen hat eine Wallet, diese Wallet hat Schlüssel, mit denen man Nachrichten signieren kann, und Adressen, die als Endpunkt für eingehende Nachrichten dienen.

Doch stattdessen verwendet die Community nach wie vor Email, Telegram, Whatsapp, Discord, Slack, Twitter und so weiter. Es fehlt nicht an Versuchen, einen Wallet-to-Wallet-Messanger aufzubauen – es fehlt ein Standard, der in die Wallets integriert ist.

Dabei wäre es so praktisch. Man könnte zu Transaktionen Nachrichten mitsenden, könnte Nachrichten in Smart-Contract-Protokolle integrieren, und vieles mehr. Nicht zuletzt wäre es hilfreich, um regulatorische Anforderungen wie die Travel Rule zu erfüllen.

Da die Taube noch nicht in der Hand, aber auf einem recht niedrigen Dach gelandet ist, wundert es nicht, dass es mehrere Anwärter auf DEN Standard für Wallet-zu-Wallet-Nachrichten gibt. Mehr als zehn Projekte werfen ihre Variante in den Ring; die prominentesten sind Skiffmail, WalletConnect und der Chat von Blockscan. Mit Corpus Ventures hat vor kurzem auch ein deutsches Unternehmen seinen Vorschlag ins Spiel gebracht: DM3.

2. Corpus Ventures

Corpus Ventures nennt sich ein “Venture Studio”. Mit ihm haben sich Christoph Jentzsch und einige andere Ethereum-Entwickler zusammengeschlossen, um in rascher Folge Projekte zu realisieren, über die sie schon längere Zeit nachdenken. Diese Projekte sollen, wenn sie Erfolg haben, zu eigenen Startups werden.

Eines davon ist nun DM3. Wir schauen es uns etwas genauer an.

3. Verschlüsselung

So vielfältig die Versionen sind, die die Kryptoszene für Wallet-zu-Wallet-Mails vorschlägt, so sind sich doch alle über eine Sache einig: Man darf auf keinen Fall die Fehler wiederholen, die man mit der Email gemacht hat. Bloß nicht.

Dass das Email-Protokoll nicht standardmäßig verschlüsselt ist, war der Kardinalfehler der Online-Privatsphäre. Man kann Emails zwar verschlüsseln, und es gibt dafür viele Werkzeuge und Protokolle. Es gibt sogar einen Standard, die PGP-Verschlüsselung. Allerdings konnte weder sie noch eine andere Version sich außerhalb einer Nische durchsetzen. Das Ergebnis: Viele Milliarden Mails werden jeden Tag im Klartext durch das Internet geschleudert. Euer Mail- und Internetprovider kann mitlesen.

Dies soll sich also nicht wiederholen. Mails im Web3 sollen verschlüsselt sein, standardmäßig und immer. Aber wie setzt man dies am klügsten um?

4. Ethereun Name Service (ENS)

Der Ansatz von DM3 setzt bei ENS an: dem Ethereum Name Service (ENS). Man kann sich auf der Ethereum-Blockchain .eth-Domains registrieren. Diese verknüpfen einen Namen mit einer Ethereum-Adresse und erlauben es, entweder onchain oder über das Interplanetary File System (IPFS) Daten und ganze Webeiten damit zu verbinden.

Eine Blockchain ist nicht für jede Anwendung gut, vielleicht sogar für sehr wenige. Aber die Registrierung von Domains gehört dazu. Eine absolut vertrauenswürdige, unfehlbare und immer verfügbare Instanz löst die Domains auf.

ENS dient schon heute als Onchain-Identität, als einfacher Name, um Geld zu empfangen, ohne eine Adresse weiterzugeben, und auch als Ansatz für ein neues, dezentrales Internet, in dem der User die volle Kontrolle über seine Domain behält. Allerdings sollte man im Kopf behalten, dass die ENS-Domain auch Informationen über alle mit dieser Wallet verbundenen finanziellen Transaktionen öffentlich macht.

Mit DM3 soll ENS auch zur Basis von Emails werden. Wer eine .eth-Domain registriert, soll künftig auch automatisch eine Art E-Mail-Server dazu bekommen. All das ohne Mittelsmann, dem man vertrauen muss, der vollkommenen Kontrolle über die Domain, standardmäßiger Verschlüsselung und mehr.

3. DM3

Im Kern erlaubt DM3 genau dies: Man kann verschlüsselte und signierte Nachrichten an die Besitzer anderer ENS-Domains senden. Ich als Besitzer von sagen wir bitcoinblog.eth kann dir, als Besitzer von bitcoinblogleser.eth, eine verschlüsselte und signierte Mail schreiben.

Das funktioniert, an sich, schon heute. DM3 ist ein marktreifes, fertiges Produkt. Mehr oder weniger.

Man sollte dabei aber zwei Punkte wissen: Erstens verwendet DM3 nicht den öffentlichen Schlüssel, der mit der Ethereum-Adresse verbunden ist. Das wäre schön, weil es die einfachste und klarste Variante wäre. Die von Ethereum und auch Bitcoin verwendete Kryptographie ist vor allem für Signaturen gemacht. Man kann durch sie zwar verschlüsseln, aber das wäre nicht sicher genug. Darüber sind sich alle einig, die sich damit beschäftigt habe

Daher verwendet DM3 einen anderen kryptographischen Verschlüsselungsalgorithmus, der ein neues Schlüsselpaar generiert. Dieses Schlüsselpaar wird in der aktuellen Version im Browser gespeichert. Der öffentliche Schlüssel wird über sogenannte “Delivery Services” veröffentlicht. Er soll in Zukunft aber entweder direkt onchain – im ENS-Eintrag – oder auf dem IPFS gespeichert werden.

Die Delivery Services sind quasi die Nodes von DM3. Sie teilen öffentliche Schlüssel und leiten Nachrichten weiter. Das Protokoll sieht vor, dass die Nachrichten nach der Weiterleitung sofort gelöscht werden. Auch sie werden bisher lediglich im Browser Cache gespeichert, sollen aber in Zukunft entweder in einer Cloud oder im IPFS aufgehoben werden.

Bisher ist der einzige Delivery Service der Server von Corpus Venture. Aber das soll sich ändern. User werden eine URL angeben können, die zu ihrem bevorzugten Delivery Service führt. Dieser übernimmt quasi die Funktion eines Mailproviders, so wie yahoo, web.de, gmx, googlemail und so weiter – nur dass er Nachrichten weder speichert noch lesen kann.

Im Idealfall soll DM3 Teil der Wallets werden, so dass die Wallets direkt Nachrichten an ENS-Domains senden können.

Noch gibt es einiges zu tun. DM3 wird sich gegen eine starke und breite Konkurrenz behaupten müssen, und die Integration in die Wallets, die notwendig sein wird, um das Protokoll zur Massenreife zu führen, dürfte eher der Abschluss eines längeren Weges sein. Aber es macht einen vielversprechenden Eindruck.

Über Christoph Bergmann (2557 Artikel)
Das Bitcoinblog wird von Bitcoin.de gesponsort, ist inhaltlich aber unabhängig und gibt die Meinung des Redakteurs Christoph Bergmann wieder ---

8 Kommentare zu Corpus Ventures startet DM3: Wallet-zu-Wallet-Mails durch ENS

  1. Etheriumm ist voll gut.

  2. Vielen Dank, Christoph, für den Beitrag. Hinsichtlich dem DM3-Protokoll möchte ich ein paar Ergänzungen hinzufügen. (Disclaimer: ich leite bei corpus.ventures das DM3-Projekt):

    Bzgl. Schlüssel: Alle verwendeten Schlüssel werden direkt (per Signatur) von dem Ethereum-Schlüssel abgeleitet. Hintergrund dafür ist, dass eine DM3-App ja keinen Zugriff auf den private-Key hat (der in einem Wallet wie zum Beispiel Metamask gehalten wird. Künftig kann auch jedes andere geeignete Wallet inkl. Hardwarewallets wie Ledger, Lattice1, o.ä. verwendet werden). Auf diese Weise ist DM3 komplett unabhängig vom verwendeten Wallet. Es müssen sich aber auch keine neuen Schlüssel/Key-Phrases o.ä. gemerkt werden, da alle Schlüssel direkt von dem Ethereum-Schlüssel abgeleitet werden.

    Bzgl. Delivery-Dienst: Der Public-Schlüssel für die Verschlüsselung (und weitere Informationen wie die URL zum Delivery-Dienst und der public-Schlüssel für die Signatur) wird NICHT über den Delivery-Dienst veröffentlicht (das wäre ja ein single-point-of-failure), sondern im ENS Profil eingetragen (also in der Blockchain gehalten). Damit sind diese Informationen öffentlich und völlig dezentral zugänglich. Der Delivery-Dienst dient ausschließlich dazu, eine Message zu übermitteln und ist hinreichend dezentral, da jeder selbst entscheiden kann, welchen er verwenden will oder ihn sogar selbst hostet. Der Delivery-Dienst speichert die verschlüsselten Messages auch nur solange, bis sie dem Empfänger übergeben werden können.

    Bzgl. Speicherung: der Anwender entscheidet selbst, wo seine (wiederum verschlüsselten) Daten (also alle seine Messages und Informationen) gespeichert werden (entweder lokal, in einem dezentralen Speicher oder auch bei einem Cloud-Dienst). Zu keiner Zeit kann jemand außer dem Besitzer auf diese Daten zugreifen. Diese Optionen werde bald verfügbar sein.

    Bzgl. Integration: Neben der DM3-App, mit der die Anwender direkt kommunizieren können, lässt sich ein Widget auch direkt in eine DApp integrieren (z.B. ein Wallet, ein Marktplatz, ein Spiel, …)

    • Hallo Steffen, vielen Dank für die Korrekturen!

      Der Schlüssel – verwendet man den privaten Schlüssel der Wallet, um Nachrichten zu entschlüsseln?

      Der ENS-Eintrag ist nicht optional? Macht derzeit dm3 das bei der ersten Verwendung?

  3. Danke für den Artikel und die Aufmerksamkeit um das Thema Verschlüsselung, aber ich musste um Hilfe schreien und habe das drei Mal gegengelesen…

    Die von Ethereum und auch Bitcoin verwendete Kryptographie ist vor allem für Signaturen gemacht. Man kann durch sie zwar verschlüsseln, aber das wäre nicht sicher genug. Darüber sind sich alle einig, die sich damit beschäftigt habe

    Das ist schlichtweg falsch. Steffen hat das auch schon klargestellt… Falls die Sicherheit einer Signatur nicht gegeben wäre, dann wäre gerade ein monetäres Netzwerk angreifbarer als simple Nachrichtenverschlüsselung. Am Ende ist jede Transaktion eine signierte Nachricht und falls diese nicht sicher genug wäre, dann könnte man mit entsprechendem Aufwand z.B. die frühen Patoshi-Coins ausgeben….

    • steffencorpusventures // 3. September 2022 um 18:23 // Antworten

      Auf den privaten Schlüssel (Key im Wallet) kann (und darf!) NICHT direkt von DM3 zugegriffen werden, da dieser das Wallet (ggf. sogar ein Hardware-Wallet wie Ledger, Lattice, o.ä.) niemals verlassen darf! Für eine Verschlüsselung müsste dies das Wallet unterstützen. Damit DM3 unabhängig von dem Wallet arbeiten kann (z.B. ist diese Funktion bei Metamask deprecated, andere Wallets unterstützen sie gar nicht), werden die verwendeten Schlüssel von einer Signatur des Ethereum (Wallet) Schlüssels abgeleitet. Auch die Schlüssel zum Signieren der Messages sind abgeleitete Schlüssel. Ansonsten würde sehr häufig das Wallet aufgehen müssen, um eine Signatur zu bestätigen (z.B. bei jedem Senden einer Message, …), was hinsichtlich der Nutzbarkeit sehr negativ wäre.

      Bzgl. ENS-Eintrag: Um eine verschlüsselte Nachricht zu versenden, benötigt der Sender den public-Schlüssel des Empfängers, den public-Key für die Signatur und die URL vom Delivery-Service des Empfängers. ENS wird als dezentrales Register verwendet. Dort können die Infos direkt gelesen werden. Daher ist ENS nicht eine Option, sondern zentraler Info-Punkt (ansonsten müsste ein anderer zentraler oder dezentraler Dienst dafür verwendet werden).
      Beim Einrichten wird dieser Eintrag ins ENS als Text-Record des ENS-Domain geschrieben (Transaktion auf der Blockchain). Eine Message kann erst verschlüsselt und versandt werden, wenn diese Informationen vorhanden ist.
      Künftig werden wir subdomains für jeden anbieten, der keine eigene ENS-Domain hat (*.dm3.eth), ggf. auf einem Layer2.

      Mehr Details zum Protokoll gibt es hier: https://medium.com/corpus-ventures/dm3-protocol-d22d5e964b98

      • Mooooooment…

        Für eine Verschlüsselung müsste dies das Wallet unterstützen. Damit DM3 unabhängig von dem Wallet arbeiten kann (z.B. ist diese Funktion bei Metamask deprecated, andere Wallets unterstützen sie gar nicht), werden die verwendeten Schlüssel von einer Signatur des Ethereum (Wallet) Schlüssels abgeleitet.

        Wie werden diese “abgeleitet”? Deterministisch, sodass sie jederzeit wieder davon abgeleitet werden können? Dein Link zu den Details des Protokolls eröffnet mehr Fragen als er Antworten liefert.

        Auch die Schlüssel zum Signieren der Messages sind abgeleitete Schlüssel. Ansonsten würde sehr häufig das Wallet aufgehen müssen, um eine Signatur zu bestätigen (z.B. bei jedem Senden einer Message, …), was hinsichtlich der Nutzbarkeit sehr negativ wäre.

        Bitte um Details, wie diese Schlüssel abgeleitet werden. Natürlich ist Verschlüsselung immer mit Einschränkungen der Usability verbunden, man generiert stets Overhead, wenn man nicht gerade ein Verfahren verwendet, welches Zeichen simpel austauscht wie Rot13. Ob jetzt mein privater Schlüssel eines Ethereum Wallets in Verwendung ist oder ein davon abgeleiteter Schlüssel, ist meiner Ansicht irrelevant. Falls man einen dieser höher wertet als den anderen, dann kanns um die Sicherheit der Nachrichten nicht gut bestellt sein.

        Mit PGP/GPG existieren wohl erprobte Standards, die man hätte implementieren können. Die “Ableitung” von Schlüsseln, ohne sie genau zu definieren (die ich jetzt nirgends auf die Schnelle nachsehen konnte) halte ich für einen Unsicherheitsfaktor, ähnlich der eigenen kryptographischen Funktionen bei z.B. IOTA.

      • steffencorpusventures // 5. September 2022 um 17:17 //

        /quote Wie werden diese „abgeleitet“? Deterministisch, sodass sie jederzeit wieder davon abgeleitet werden können? Dein Link zu den Details des Protokolls eröffnet mehr Fragen als er Antworten liefert.

        Ja, der Schlüssel wird aus dem Hash einer mit dem private-Key signierten Information erzeugt. Zusätzlich kommt eine Nonce zum Einsatz, um eine Key-Rotation zu ermöglichen, falls ein Schlüssel kompromittiert wurde. Das ist natürlich deterministisch, d.h. man kann dieses neue Schlüsselpaar jederzeit neu erzeugen. Warum wird das so gemacht? Ein wichtiger (Sicherheits-)Grundsatz ist, dass ein privater Schlüssel niemals das Gerät verlassen darf (was ja im Falle eines Hardware-Wallets auch gar nicht möglich wäre). Eine DApp, die mit dem Wallet interagiert, kann eine Signatur bekommen, Informationen prüfen usw., aber niemals direkt auf den privaten Schlüssel zugreifen!

        /quote Bitte um Details, wie diese Schlüssel abgeleitet werden. Natürlich ist Verschlüsselung immer mit Einschränkungen der Usability verbunden, man generiert stets Overhead, wenn man nicht gerade ein Verfahren verwendet, welches Zeichen simpel austauscht wie Rot13. Ob jetzt mein privater Schlüssel eines Ethereum Wallets in Verwendung ist oder ein davon abgeleiteter Schlüssel, ist meiner Ansicht irrelevant. Falls man einen dieser höher wertet als den anderen, dann kann’s um die Sicherheit der Nachrichten nicht gut bestellt sein.

        Hinsichtlich der Sicherheit ist der abgeleitete Schlüssel identisch mit dem originalem. Der Unterschied besteht lediglich darin, dass der abgeleitete Schlüssel von der DApp verwaltet wird und somit direkt genutzt werden kann. Er wird erzeugt aus dem Hash der Signatur einer Information. Warum? Damit dieser abgeleitete Schlüssel (für die Erzeugung wird eine Interaktion mit dem Wallet benötigt!) danach von der DApp genutzt werden kann, ohne ständig neue Interaktionen notwendig sind. Im Falle des Verlusts des abgeleiteten Schlüssels, kann dieser stets neu erzeugt werden. Im Falle, dass er kompromittiert wurde, kann ein neues Schlüsselpaar (mit einer anderen Nonce) erstellt werden.

        Kleines Beispiel: Der Nutzer möchte eine Nachricht abschicken. Dazu muss die Nachricht einerseits signiert werden und dann mit dem public Key des Empfängers verschlüsselt werden. Würde die Signatur über den Ethereum Key (z.B. im Hardware-Wallet) signiert, würde der Nutzer bei jeder Nachricht sein Hardware-Wallet für die Signatur nutzten müssen. Das würde kein Nutzer tun wollen. Wird der abgeleitete Schlüssel verwendet, muss der Nutzer genau eine Information signieren (nämlich beim Erzeugen des Schlüssels) und danach kann die DApp jede Message signieren, ohne dass mit dem HW-Wallet interagiert werden muss. Analog ist es beim Verschlüsseln.

        /quote Mit PGP/GPG existieren wohl erprobte Standards, die man hätte implementieren können.

        Genau das wird am Ende ja auch gemacht (aus Sicht Verschlüsselung!). Das entscheidende am DM3-Protokoll ist jedoch, dass es hier ein “zentrales” Register (Vorsicht Paradoxon!) gib (nämlich ENS), wo man die öffentlichen Schlüssel der Empfänger herbekommt und dieses völlig dezentral erreichbar ist (da on-chain).

        /quote Die „Ableitung“ von Schlüsseln, ohne sie genau zu definieren (die ich jetzt nirgends auf die Schnelle nachsehen konnte) halte ich für einen Unsicherheitsfaktor …

        Die Ableitung ist offen und klar definiert (und übrigens eine gängige Vorgehensweise) und das System ist open-source. Es ist also keine Unsicherheit (siehe Erläuterung oben…)
        Und der Vergleich … 🙁

      • > Ja, der Schlüssel wird aus dem Hash einer mit dem private-Key signierten Information erzeugt. Zusätzlich kommt eine Nonce zum Einsatz, um eine Key-Rotation zu ermöglichen, falls ein Schlüssel kompromittiert wurde.

        Welchen Algorithmus verwendet ihr dabei?

Kommentar verfassen

%d Bloggern gefällt das: