Ein Wort zur Finanzierung: CypherpunkGuide schaltet keine Überwachungswerbung — keine Werbenetzwerke, keine Tracking-Pixel, keine gesponserten Inhalte. Die Finanzierung ist transparent: heute Leserspenden, später ein Abo und redaktionell passende Affiliate-Partnerschaften. Wir fühlen uns unseren Leserinnen und Lesern verpflichtet, nicht den Werbetreibenden.
Eine private Zahlung, ein verschlüsseltes Gespräch und ein verschlüsselter Cloud-Ordner sehen nach drei gelösten Problemen aus. Monero, SimpleX und Cryptomator schützen tatsächlich wichtige Daten. Daraus folgt aber kein anonymes Gesamtsystem für den Weg von der Zahlung bis zur Dateiübergabe.
Für diesen Artikel habe ich anhand der am 13. August 2026 aktuellen offiziellen Dokumentation 18 beobachtbare Angaben geprüft — sechs pro Werkzeug. Die an Quellen gebundene CSV-Datei unterscheidet vier Zustände. Ein deterministisches Prüfskript, das bei derselben Eingabe immer zum selben Ergebnis kommt, lehnt Zeilen ohne Beobachter, Quelle oder Stichtag ab. Eine Gesamtnote gibt es bewusst nicht: Felder mit verschiedenen Beobachtern und Folgen zu addieren, würde eine Rangliste ohne sachliche Grundlage erzeugen.
Schwierig wird es, wenn die drei Vorgänge gemeinsame Merkmale hinterlassen. Die Prüfung ergab sechs wiederkehrende Anhaltspunkte: Alias, Gerät, Internetverbindung, Gegenpartei, das Muster aus Zeitpunkt und Datenmenge sowie Wiederherstellungsdaten. Wer mehrere Datensätze einsehen kann, kann damit Zahlung, Nachricht und Dateivorgang einander zuordnen. Deshalb muss jede dokumentierte Schutzwirkung zusammen mit den Daten bewertet werden, die weiterhin erhalten bleiben.
Drei Werkzeuge schützen drei verschiedene Datensätze#
Mehrere Datenschutzmaßnahmen haben jeweils einen eigenen Geltungsbereich; zusammen garantieren sie keine allgemeine Anonymität. Monero schützt bestimmte Angaben in Zahlungsdaten, SimpleX schützt die Nachrichtenübermittlung und Cryptomator schützt Cloud-Dateien. Keines der Werkzeuge schützt vor jedem Beobachter.
Beginne beim Datensatz, nicht beim Produkt. Ein Blockchain-Analyst, der Internetanbieter, ein Nachrichten-Relay — also ein Zwischenserver für die Zustellung —, der Cloud-Anbieter, die Gegenpartei und Schadsoftware auf deinem Gerät sehen unterschiedliche Informationen. Derselbe Wert kann für einen Beobachter verborgen und für einen anderen sichtbar sein.
| Einsatz | Dafür ist das Werkzeug gedacht | Das bleibt außerhalb seines Schutzes |
|---|---|---|
| Zahlung — Monero | erschwert die Bestimmung der echten Eingabe des Senders, schützt die Empfängeradresse und verbirgt den Betrag | IP-Verbindung der Wallet, Händlerdaten, freiwillig offengelegte Identität, Schlüssel und Klartext auf dem Gerät |
| Nachricht — SimpleX | Nachrichteninhalt während der Übermittlung, Zustellung ohne eine globale Profil-ID, Trennung von Quelle und Server des Empfängers | eigene Kennungen für die Nachrichtenwarteschlange jedes Kontakts, Zeitmuster, bestimmte Server- und Netzwerkdaten, Wissen des Kontakts, Verlauf auf dem Gerät |
| Speicher — Cryptomator | Inhalt und Namen vor der Cloud-Synchronisierung; erschwert das Lesen der Verzeichnisstruktur | Zeitstempel, Anzahl und Größe der Objekte, erkennbares Tresorformat, Identität des Cloud-Kontos, Klartext im geöffneten Tresor |
protected bedeutet in diesem Artikel: Die genannte Angabe ist innerhalb des dokumentierten Geltungsbereichs vor dem genannten Beobachter geschützt. Der Empfänger kann sie trotzdem kennen, ein kompromittiertes Gerät kann sie preisgeben und andere Datensätze können eine Zuordnung ermöglichen. partial bedeutet, dass eine Maßnahme die Sichtbarkeit verringert, ohne die Angabe oder jede Zuordnungsmöglichkeit zu beseitigen. exposed steht für ein Feld, dessen Sichtbarkeit oder fehlender Schutz aus der Quelle hervorgeht. unknown heißt, dass die Quelle weder Schutz noch Offenlegung belegt; der Zustand ist kein Beweis in die eine oder andere Richtung.
Ein brauchbares Bedrohungsmodell folgt derselben Regel: Benenne Beobachter, schützenswerte Angabe und Ereignis, bevor du eine Maßnahme wählst. Ändert sich der Beobachter, kann sich auch die richtige Antwort ändern.
Monero verschleiert Zusammenhänge auf der Blockchain, nicht die ganze Zahlung#
Monero erschwert es, die echte Eingabe des Senders zu bestimmen, nutzt einmalige Zieladressen für Empfänger und verbirgt Beträge durch vertrauliche Ringtransaktionen (RingCT). Das sind Eigenschaften des Zahlungsprotokolls. Die Verbindung zu einem Remote-Node, das Netzwerk, die Gegenpartei, das Konto und eine kompromittierte Wallet musst du getrennt absichern.
Die technischen Spezifikationen von Monero nennen eine Ringgröße von 16: Eine echte Eingabe steht neben 15 Decoys, also Eingaben, die ebenfalls wie mögliche Ursprünge der Zahlung aussehen. Dadurch entsteht plausible Abstreitbarkeit: Für die echte Eingabe gibt es mehrere glaubhafte Erklärungen. Daraus folgt nicht, dass ein Beobachter mit einer garantierten Wahrscheinlichkeit von „eins zu sechzehn“ richtig rät. Moneros OSPEAD-Forschung modelliert unter anderem ungleichmäßige Auswahl und zeitabhängige Risiken. Die Zahl im Protokoll ist keine persönliche Anonymitätswahrscheinlichkeit.
Empfänger und Betrag werden anders geschützt. Eine Stealth-Adresse ist eine einmalige Zieladresse für eine Zahlung; die öffentliche Blockchain zeigt dadurch nicht unmittelbar die wiederverwendbare Adresse des Empfängers. RingCT, kurz für Ring Confidential Transactions, verbirgt den übertragenen Betrag. „Monero-Privatsphäre“ umfasst daher drei unterschiedliche Aussagen über Sender, Empfänger und Betrag — keine pauschale Eigenschaft.
| Beobachter | Was Monero verändert | Was weiterhin vorliegen kann |
|---|---|---|
| Analyst der öffentlichen Blockchain | echte Eingabe, Zuordnung zum Empfänger und Betrag sind nicht direkt ablesbar | Existenz und Zeitpunkt des Protokollereignisses; probabilistische Schlussfolgerungen |
| Betreiber eines Remote-Nodes | Empfängeradresse und Betrag stehen nicht als Klartext in der Blockchain | Verbindung der Wallet und Quell-IP, wenn der Netzwerkweg nicht getrennt geschützt wird |
| Internetanbieter oder VPN-Betreiber | Schutz des Transaktionsverlaufs bleibt bestehen | Verbindungsweg, Zeitmuster und Abfolge der Verbindungsziele |
| Gegenpartei oder Börse | die öffentliche Blockchain legt diese privaten Zahlungsfelder nicht offen | Identität, Bestellung, Lieferadresse, Konto, Betrag oder Gespräch, das du offengelegt hast |
| Kompromittiertes Gerät | Gegen öffentliche Beobachter gelten die Protokolleigenschaften weiter | Wallet-Schlüssel, Ziel, Betrag, Bildschirminhalt, Zwischenablage und Passworteingabe |
Die offizielle FAQ widerspricht einer Garantie von 100 Prozent Anonymität. Sie nennt kompromittierte Geräte, offengelegte Schlüssel, schwache Passwörter und freiwillig weitergegebene Identitätsdaten als Risiken. Eine eigene Subadresse für jeden Zahler oder Zweck kann die Möglichkeit verringern, dass eine Gegenpartei mehrere Zahlungen über eine wiederverwendete Adresse zusammenführt. Die Lieferadresse, die du demselben Händler genannt hast, löscht eine Subadresse nicht.
Auch die Netzwerkherkunft ist getrennt zu behandeln. Laut Moneros Dokumentation verbirgt eine Wallet ihre IP standardmäßig nicht vor einem Remote-Node — einem fremden Server, über den sie auf die Blockchain zugreift. Tor oder I2P sind zusätzliche Netzwerkmaßnahmen. Das Verfahren Dandelion++ verändert die Weitergabe einer Transaktion, versteckt aber die Verbindung eines vollständigen Blockchain-Knotens nicht vor Internetanbieter, VPN-Betreiber oder erstem Kommunikationspartner. Wenn die Netzwerkherkunft geschützt werden muss, richte den Weg ausdrücklich ein und prüfe, ob die Wallet ihn tatsächlich nutzt.
Das Handbuch zur Bitcoin-Privatsphäre auf der Blockchain behandelt das breitere Bedrohungsmodell für Zahlungen. Das Protokoll ist anders, die praktische Grenze aber gleich: Schutz auf der Blockchain löscht weder Kaufdaten noch Spuren auf dem Gerät.
SimpleX nutzt keine globale Profil-ID, hinterlässt aber Metadaten#
SimpleX verwendet für die Nachrichtenzustellung keine globale Nutzerprofil-ID. Jede Verbindung nutzt eigene Kennungen für ihre Nachrichtenwarteschlangen (Queues), und die Nachrichten werden Ende-zu-Ende verschlüsselt. Relays, Netzwerke, Kontakte, Benachrichtigungsdienste und Geräte sehen jeweils andere Angaben.
Laut der Datenschutzerklärung von SimpleX liegen Profile und der Verlauf zugestellter Nachrichten auf den Geräten; Relays speichern diesen zugestellten Verlauf nicht. Noch nicht zugestellte verschlüsselte Nachrichten können bis zur Zustellung oder höchstens 21 Tage auf den voreingestellten Servern verbleiben. Für verschlüsselte Dateien beträgt die Aufbewahrung auf den voreingestellten Dateiservern 48 Stunden. Die Server speichern also zeitweise Daten, auch wenn sie keinen lesbaren Nachrichteninhalt besitzen.
Nachrichten werden auf 16 KiB aufgefüllt; Dateien bestehen aus Blöcken fester Größenklassen. Das verringert genaue Größeninformationen, verbirgt aber nicht, dass Datenverkehr stattgefunden hat. Unter iOS kann die Sofortbenachrichtigung außerdem die ungefähre Zahl aktivierter Queues und das ungefähre Nachrichtenaufkommen gegenüber dem Benachrichtigungsserver offenlegen.
| Prüfpunkt | Voreinstellung | Strengere Konfiguration | Was weiterhin sichtbar sein kann |
|---|---|---|---|
| Profilidentität | keine globale Profil-ID; jede Verbindung nutzt eigene Daten | nutze Inkognito-Profile, wenn verschiedene Beziehungen getrennte Profildaten brauchen | Kontakte kennen das ihnen gezeigte Profil; wiederkehrende Merkmale können Kontexte verbinden |
| Serverweg | Private Routing setzt einen konfigurierten Weiterleitungsserver vor den Zielserver; bei mehreren voreingestellten Betreibern bevorzugt die App einen anderen Betreiber | nutze Tor oder einen anderen zuvor bewerteten Netzwerkweg, wenn der gewählte Server deine Quell-IP nicht sehen darf | Weiterleitungs- und Zielserver müssen nicht unabhängig betrieben werden; lokale Beobachter sehen weiterhin Verkehr |
| Gemeinsam genutzte Verbindung | ein Profil teilt standardmäßig eine TCP-Verbindung | aktiviere nach Prüfung des BETA-Status eine getrennte Transportverbindung pro Kontakt | Zeitpunkt und Volumen können weiterhin zusammenpassen |
| Echtheit des Kontakts | ein Einladungslink stellt die Verbindung her | vergleiche den Sicherheitscode über einen unabhängigen Kanal | auch dieser Kanal muss der beabsichtigten Person gehören |
| Verlauf auf dem Gerät | zugestellte Nachrichten werden lokal gespeichert | schütze die App-Datenbank mit einer Passphrase und lege eine passende Aufbewahrung fest | entsperrtes Gerät, Empfänger, Bildschirmfoto und Schadsoftware können Klartext speichern |
Die Anleitung zu Privatsphäre und Sicherheit warnt davor, dass ein Einladungslink unterwegs ausgetauscht werden kann. Vergleiche bei einem sensiblen Kontakt den Sicherheitscode in der App über einen wirklich unabhängigen Weg, etwa einen bereits bestätigten Anruf oder ein persönliches Treffen. Eine zweite Nachricht über dasselbe ungeprüfte Konto ist keine unabhängige Bestätigung.
Auch das Bedrohungsmodell des Protokolls begrenzt die Aussage „keine Kennungen“. Kontakte können unter Umständen prüfen, ob nicht im Inkognito-Modus verwendete Profildaten identisch sind. Empfangsbestätigungen und automatische Antworten können Aktivität und ihren Zeitpunkt verraten. Keine globale Profil-ID für die Zustellung zu haben, bedeutet nicht, dass verbindungsspezifische Kennungen und beobachterabhängige Metadaten fehlen.
Anrufe haben einen anderen Geltungsbereich als Nachrichten. Der Leitfaden für Audio- und Videoanrufe erklärt: Bei einem über ein TURN-Relay vermittelten Anruf sieht dieser Zwischenserver die Dauer. Ein TURN-Relay überträgt Sprach- und Videodaten, wenn die Geräte keine direkte Verbindung aufbauen können. Bei einer direkten Verbindung sehen die Kontakte dagegen ihre IP-Adressen. Prüfe Anrufe getrennt, wenn sie zu deinem Ablauf gehören.
SimpleX schützt die Nachrichtenübermittlung, nicht automatisch jeden versendeten Inhalt. Der Leitfaden zur Privatsphäre von Telefonnummern zeigt, warum es hilft, diese Kennung zu entfernen. Kontaktverhalten und kompromittierte Geräte brauchen trotzdem eigene Maßnahmen.
Cryptomator verschlüsselt Dateien, aber nicht das Aktivitätsmuster#
Cryptomator verschlüsselt Dateiinhalte und -namen vor der Cloud-Synchronisierung und verschleiert die Verzeichnisstruktur. Zeitstempel, Anzahl der Objekte, gespeicherte Dateigrößen und das erkennbare Tresorformat bleiben laut Sicherheitsdokument für den Cloud-Anbieter sichtbar.
Das Sicherheitsziel von Cryptomator benennt ausdrücklich, was nicht geschützt wird. Der Cloud-Anbieter erhält weder lesbare Dateinamen noch lesbare Inhalte. Er kann aber erkennen, wann Objekte geändert wurden, wie viele vorhanden sind und wie groß sie gespeichert sind. Endungen wie .c9r und .c9s sowie Konfigurationsdateien können außerdem verraten, dass Cryptomator eingesetzt wird. Das ist Verschlüsselung, keine Steganografie — also keine Technik, die bereits die Existenz geschützter Daten verbergen soll.
Nach dem Öffnen des Tresors wird das Endgerät zum unmittelbareren Risiko: der Rechner oder das Smartphone, auf dem Schlüssel und entschlüsselter Klartext verarbeitet werden. Schadsoftware, ein böswilliger Administrator, Bildschirmaufnahmen, temporäre Dateien, der Verlauf der Zwischenablage und Kopien außerhalb des Cryptomator-Tresors können den Cloud-Schutz umgehen. Kopiert eine andere Anwendung eine geöffnete Datei, schützt Cryptomator diese Kopie nicht.
Cryptomator ersetzt weder Synchronisierung noch Sicherungen. Die offiziellen Empfehlungen verlangen regelmäßige Sicherungen des verschlüsselten Tresors. Die Anleitung zu Synchronisierungskonflikten behandelt die Synchronisierung als getrenntes System, das Konflikte verursachen kann. Bewahre Zugangsdaten und Wiederherstellungsmaterial getrennt vom Cloud-Konto und von dem Gerät auf, mit denen du den Tresor synchronisierst und öffnest. Die Tresorwiederherstellung stellt gelöschte verschlüsselte Dateien nicht wieder her. Können mehrere Programme den geöffneten Tresor lesen, musst du sie alle als vertrauenswürdigen Teil des Endgeräts behandeln.
Unsere Prüfung erfasst 18 beobachtbare Felder#
Die Prüfung erfasst für drei Werkzeuge jeweils sechs beobachtbare Felder. Jede Zeile nennt Beobachter, offizielle Quelle, Datum und Einschränkung. Sie findet Risiken beim Zusammenspiel; sie ist weder Benchmark noch Produktbewertung oder Datenschutz-Rangliste.
Ich habe die Tabelle mit 18 Zeilen aus den in diesem Artikel zitierten offiziellen Quellen erstellt. Anschließend bestätigte das Prüfskript genau 18 Zeilen, sechs pro Werkzeug, eindeutige Felder, zugelassene Quelldomains, Datumsangaben im ISO-Format und ausgefüllte Einschränkungen. Die erzeugte Zusammenfassung zählt die vier Zustände, warnt aber ausdrücklich vor einem Produktvergleich anhand dieser Zahlen.
Fünf Regeln begrenzen die Aussagekraft:
- Jedes Feld wird für einen klar benannten Beobachter bewertet. Die Netzwerkherkunft wird gegenüber einem Server- oder Netzwerkbeobachter bewertet, nicht gegenüber einem undefinierten Angreifer.
- Voreinstellung und zusätzliche Härtung bleiben getrennt.
hardenedbezeichnet eine dokumentierte Einstellung oder eine ausdrücklich genannte weitere Maßnahme. Es ist kein Nachweis eines praktischen Tests und kein Beleg dafür, dass Cora diesen Netzwerkweg geprüft hat. Die Möglichkeit, Tor einzusetzen, macht Tor nicht zur Voreinstellung. - Jede Zeile nennt, was ungeschützt bleibt. Eine während der Übermittlung geschützte Nachricht kann auf beiden Endgeräten als Klartext vorliegen.
- Fehlende Belege bleiben
unknown. Das Sicherheitsziel von Cryptomator verspricht keine anonyme Netzwerkverbindung zur Cloud. Deshalb bleibt dieses Feldunknown, statt mit einer Vermutung gefüllt zu werden. Der Zustand belegt weder Offenlegung noch Schutz. - Aus den Einstufungen wird keine Note. Die sechs Felder unterscheiden sich in Beobachter und Folgen; ihre Anzahl ergibt keine gültige Messzahl für die Privatsphäre eines Produkts.
Gerade die vierte Regel war nützlich. Ein Cryptomator-Feld blieb bewusst unknown, statt den Ruf des Produkts als Ersatz für einen Beleg zu verwenden. Außerdem wurde jeder Zeile vor der Einstufung ein bestimmter Beobachter zugeordnet. So verhindert die Methode, dass eine vollständig wirkende Tabelle dazu verleitet, die falsche Komponente abzusichern.
Sechs gemeinsame Merkmale können die Datensätze wieder zusammenführen#
Die folgende Tabelle ist eine Schlussfolgerung von Cora aus den Belegen zu den einzelnen Komponenten. Sie beschreibt weder eine gemessene Deanonymisierung noch eine Aussage der Anbieter über den gemeinsamen Einsatz aller drei Werkzeuge. Das NIST-Glossar definiert Dissoziierbarkeit als die Möglichkeit, Daten oder Ereignisse zu verarbeiten, ohne sie über das betrieblich nötige Maß hinaus einer Person oder einem Gerät zuzuordnen. Wiederholt sich ein dauerhaftes Merkmal in allen drei Vorgängen, geht diese Eigenschaft verloren.
| Gemeinsames Merkmal | Beispiel | Wer die Datensätze vergleichen kann | Geeignete Trennung |
|---|---|---|---|
| Alias oder Konto | derselbe Name erscheint im SimpleX-Profil, im Börsenkonto und im Cloud-Konto | Gegenpartei, Kontoanbieter, Datenhändler | getrennte Identitäten nach Zweck; keine gemeinsame Wiederherstellungsadresse |
| Gerät | ein infizierter Laptop sieht Wallet, Chat und geöffneten Tresor als Klartext | Schadsoftware, Geräteadministrator, Forensiker | getrennte Geräte oder stark isolierte Systeme, wenn das Risiko es rechtfertigt; gewöhnliche Betriebssystemkonten organisieren Zugriffe, stoppen aber keine Schadsoftware mit Administratorrechten |
| Internetverbindung | Wallet, Nachrichtenserver und Cloud erhalten Verbindungen von derselben stabilen IP-Adresse des Haushalts | Internetanbieter, VPN-Betreiber, Nachrichtenserver oder Cloud-Anbieter mit Zusatzdaten | plane jeden sensiblen Netzwerkweg bewusst; Datei- oder Protokollverschlüsselung verbirgt die IP-Adresse nicht |
| Gegenpartei | dieselbe Person erhält Nachricht, Zahlung und Dateilink | Empfänger oder Händler | gib nur nötige Angaben preis; nutze zweckgebundene Subadressen und Links |
| Zeitpunkt und Datenmenge | Nachricht, Zahlung und Cloud-Upload folgen innerhalb weniger Sekunden | Beobachter mit Zugriff auf mehrere Protokolle | bündele oder verzögere Vorgänge und nenne genaue Beträge oder Dateinamen nicht in Echtzeit |
| Wiederherstellungsdaten | dieselbe E-Mail-Adresse, derselbe Passwortmanager oder dieselbe Fotosicherung stellt alle drei Werkzeuge wieder her | Kontoangreifer, Cloud-Anbieter, eine Stelle, die dich zur Herausgabe zwingen kann | getrennte Wiederherstellungswege und Offline-Material; jeden Weg einzeln testen |
Zeitliche Nähe ist nur ein Hinweis. Sie beweist nicht, dass zwei Datensätze derselben Person gehören. Wiederholt sich jedoch stets die Abfolge Nachricht, Zahlung, Upload, kann das Muster aussagekräftiger werden als eine einzelne Überschneidung. Zufällige Verzögerungen schaffen keine Anonymität. Beseitige zuerst stärkere gemeinsame Merkmale wie Identität und Gerät; entferne erst danach unnötig genaue Zeitbezüge.
Das ähnelt dem Leitfaden zur Deanonymisierung mit KI: Viele schwache Signale lassen sich mit wenig Aufwand verknüpfen, wenn sie ein gemeinsames Merkmal haben. Hier stammen die Signale aus maschinenlesbaren Zahlungs-, Nachrichten- und Dateivorgängen, nicht aus dem Schreibstil.
Richte die drei Werkzeuge ohne eine Kennung für alles ein#
Beginne beim Bedrohungsmodell: Trenne Zwecke, prüfe Software und Kontakte, schütze die erforderlichen Netzwerkwege, verschlüssele vor der Synchronisierung und übe die Wiederherstellung. Die Konfiguration ist erst belastbar, wenn der Ausfall oder die Kompromittierung eines Kontos oder Geräts nicht alle drei Vorgänge offenlegt.
Übe die folgenden Schritte mit nicht sensiblen Testdaten, bevor du echtes Geld oder sensible Unterlagen verwendest:
- Benenne drei Beobachter und das jeweilige Schutzziel. Zum Beispiel: „Die öffentliche Blockchain darf Empfänger und Betrag nicht zeigen“, „der Nachrichtenserver darf keinen Klartext besitzen“ und „der Cloud-Anbieter darf Namen und Inhalte nicht lesen“. Ergänze Netzwerk und Endgerät nur, wenn das Risiko den Aufwand rechtfertigt.
- Trenne Identitäten nach Zweck. Entscheide, ob eine Gegenpartei Zahlung, Chat und Datei zuordnen darf. Falls nicht, verwende für diese Zwecke weder denselben Alias noch dieselbe Wiederherstellungsadresse, dasselbe Profilbild oder dasselbe Cloud-Konto. Verrate die Zuordnung auch nicht im Gespräch.
- Beziehe Software aus offiziellen Quellen und prüfe sie. Kontrolliere Release-Signaturen oder Hinweise zu reproduzierbaren Builds, wenn das Projekt sie anbietet. Teste Monero im Testnetz
stagenetund verwende in SimpleX und Cryptomator zunächst nicht vertrauliche Daten. Ist die Programmdatei ungeprüft, können die übrigen Maßnahmen ihre unklare Herkunft nicht ausgleichen. - Konfiguriere die Zahlung. Nutze eine eigene Subadresse pro Zahler oder Zweck. Darf der Remote-Node die Quell-IP der Wallet nicht sehen, richte den Netzwerkweg getrennt ein und teste ihn. Halte fest, welche Angaben bei der Gegenpartei verbleiben.
- Bestätige den Nachrichtenkontakt. Stelle die SimpleX-Verbindung her, vergleiche den Sicherheitscode über einen unabhängigen Kanal, prüfe Inkognito- und Transportisolierung und entscheide, ob Benachrichtigungen und Anrufe zum Bedrohungsmodell passen.
- Richte den Dateispeicher ein. Erstelle den Tresor lokal, verwende ein starkes Passwort, das du nur für diesen Tresor nutzt, bewahre Wiederherstellungsmaterial getrennt auf und synchronisiere erst danach die verschlüsselten Daten. Prüfe, ob temporäre Exporte oder Programmsicherungen anderswo Klartext hinterlassen.
- Übe Ausfälle mit nicht sensiblen Testdaten. Stelle einen Testtresor wieder her, stelle nach der aktuellen Dokumentation ein unkritisches Chatprofil wieder her oder übertrage es und nutze für die Wallet eine leere Test-Wallet oder eine bewusst isolierte Testumgebung. Gib eine Seed-Phrase, die echtes Geld schützt — also das Geheimnis zur Wiederherstellung der Wallet — niemals in eine Website, einen Cloud-Dienst, ein ungeprüftes Gerät oder ein unbekanntes Werkzeug ein. Überschreibe bei der Übung nicht die vorhandene Wallet. Finde vor dem Notfall heraus, ob alle drei Wiederherstellungswege von demselben Telefon abhängen.
- Prüfe gemeinsame Merkmale über alle Vorgänge. Vergleiche Alias, Gerät, Netzwerkweg, Gegenpartei, Zeit, Datenmenge und Wiederherstellung. Entferne gemeinsame Merkmale ohne betrieblichen Nutzen und dokumentiere diejenigen, die du akzeptierst.
Trennung kostet Zeit und erhöht die Zahl der Wiederherstellungsdaten. Außerdem drohen verpasste Benachrichtigungen, fehlerhafte Netzwerkwege und Bedienfehler. Das Ziel ist nicht größtmögliche Trennung, sondern der geringste Aufwand, der verhindert, dass der konkret benannte Beobachter die getrennten Datensätze zuordnet. Der Leitfaden zur Souveränität durch selbst betriebene Dienste wendet dieselbe Regel auf Infrastruktur an: Ein Dienst im eigenen Haus ändert die Vertrauensbeziehung, beseitigt aber weder Administration noch Wiederherstellungsrisiken.
Fazit: Entscheide zuerst, welchen Datensatz du schützen musst#
Nutze Monero für Privatsphäre im öffentlichen Transaktionsverlauf, SimpleX für Nachrichten ohne globale Profil-ID und Cryptomator zur Verschlüsselung von Cloud-Dateien. Prüfe danach gemeinsam genutzte Identitäten, Geräte, Netzwerkwege, Zeitmuster und Wiederherstellungsdaten.
Willst du nur verhindern, dass ein Cloud-Anbieter Dateinamen liest, kann Cryptomator bereits die vollständige Antwort sein. Kennt ein Händler deine amtliche Identität und Lieferadresse, löscht Monero diesen Geschäftsdatensatz nicht. Ist der Kontakt ungeprüft, kann SimpleX die Verbindung verschlüsseln, aber nicht bestätigen, dass du mit der richtigen Person sprichst. Mehr Werkzeuge beheben kein falsch formuliertes Bedrohungsmodell.
Ein vertretbares Schutzkonzept benennt für jede Aussage einen Beobachter und testet jeden Wiederherstellungsweg. Lass ein Feld ehrlich unknown, wenn der Beleg fehlt. Das ist sicherer als eine lückenlos wirkende Tabelle, die einem Produkt eine unbelegte Eigenschaft zuschreibt.
Häufig gestellte Fragen#
Die Werkzeuge schützen bestimmte Protokoll- und Speicherfelder, nicht sämtliche Daten zu Identität, Netzwerk, Endgerät und Wiederherstellung. Benenne zuerst den Beobachter und wähle nur Maßnahmen, die seine Sicht tatsächlich verändern.
Machen mich Monero, SimpleX und Cryptomator zusammen anonym?#
Nein. Jedes Werkzeug schützt einen anderen Datensatz. Eine Gegenpartei, ein kompromittiertes Gerät, eine stabile IP, ein wiederkehrendes Zeitmuster oder ein gemeinsamer Wiederherstellungsweg kann die Vorgänge zusammenführen. Anonymität ist ein Ergebnis deines Bedrohungsmodells, keine Eigenschaft, die aus drei Produktnamen entsteht.
Verbirgt Monero meine IP vor einem Remote-Node?#
Standardmäßig nicht. Moneros technische Dokumentation behandelt die Netzwerk-Privatsphäre als zusätzliche Aufgabe und beschreibt dafür Tor oder I2P. Prüfe den tatsächlichen Weg deiner Wallet. Aus dem Schutz von Sender, Empfänger und Betrag auf der Blockchain folgt kein IP-Schutz.
Hat SimpleX weder Kennungen noch Metadaten?#
SimpleX nutzt für die Zustellung keine globale Nutzerprofil-ID. Es verwendet jedoch eigene Queue-Kennungen pro Verbindung, und betriebliche Metadaten fallen innerhalb der dokumentierten Grenzen weiterhin an. Nachrichtenserver, Kontakte, Benachrichtigungsdienste, Netzwerkbeobachter und Endgeräte sehen unterschiedliche Felder.
Kann mein Cloud-Anbieter erkennen, dass ich Cryptomator nutze?#
Ja. Cryptomator verschlüsselt Inhalte und Namen, verbirgt aber nicht das eigene Tresorformat. Dateiendungen der verschlüsselten Objekte, Konfigurationsdateien, Zeitstempel, Anzahlen und gespeicherte Größen können sichtbar bleiben.
Soll ich alle Wiederherstellungsdaten in einem Passwortmanager speichern?#
Nur wenn dein Bedrohungsmodell akzeptiert, dass dieser Manager samt Wiederherstellung alle drei Vorgänge zusammenführen kann. Bei höherem Risiko solltest du Material trennen, dessen gemeinsamer Verlust oder Diebstahl alles offenlegen würde. Teste danach die Wiederherstellung, damit die Trennung dich nicht aussperrt.
Quellen#
Für alle 13 veränderlichen offiziellen Quellen ist eine exakte Wayback-Momentaufnahme angegeben. Die Aussagen stützen sich auf die aktuellen Originalseiten; die Archivspalte schafft einen zweiten Weg für eine spätere Prüfung.
