Wie die optionale Cloud-Synchronisation von Filarr Zero-Knowledge bleibt (ein Blick in den Code)

Sie haben einen zweiten Laptop gekauft, oder Sie wollen Ihre Arbeitsnotizen auf dem Rechner zu Hause und auf dem im Büro haben. Sobald Ihre Dateien ein Gerät verlassen, stellt sich dieselbe stille Frage, die jedes Cloud-Werkzeug Sie zu übergehen bittet: Wer kann sie unterwegs lesen, und wer kann sie lesen, sobald sie angekommen sind?

Die Antwort von Filarr lautet: Seine Server speichern nur verschlüsselte Daten, die sie nicht lesen können. Ihre Dateien werden zwischen Ihren Geräten synchronisiert, aber der Server, der sie bewegt, hält Ihren Schlüssel nie im Klartext, sieht nie einen Dateinamen und berührt nie ein Byte lesbaren Inhalts. Dieser Artikel zeigt genau, wie das funktioniert, direkt aus dem Synchronisationscode, denn „Zero-Knowledge“ ist eine Behauptung, die nur etwas bedeutet, wenn man den Mechanismus dahinter sehen kann.

Ein Hinweis zum Umfang vorab: Die Cloud-Synchronisation ist in Filarr optional. Das Produkt ist Local-First, Ihre Dateien liegen verschlüsselt auf Ihrer Festplatte, ob Sie die Synchronisation je einschalten oder nicht. Alles Folgende beschreibt, was passiert, wenn Sie sich entscheiden, sie zu aktivieren.

Kurze Antwort

Filarr synchronisiert Ihre Dateien, indem es sie genau so hochlädt, wie sie bereits auf Ihrer Festplatte liegen: mit AES-256-GCM unter Ihrem Kontoschlüssel (dem FEK) verschlüsselt, mit einem neuen Zufallswert pro Datei. Der FEK erreicht den Server nie in lesbarer Form. Der Cloudflare Worker, der die Synchronisation abwickelt, speichert nur undurchsichtige verschlüsselte Blobs unter undurchsichtigen Datei-IDs (einem SHA-256-Hash des lokalen Pfads), dazu ein kleines Manifest, das seinerseits mit Ihrem FEK per AES-256-GCM verschlüsselt ist. Der Server kann sehen, wie viele Blobs Sie haben und wie groß sie sind, aber nicht ihre Namen, ihre Ordnerstruktur oder ihren Inhalt. Ein zweites Gerät erhält Ihren Schlüssel entweder durch Anmelden, wobei es die unter Ihrem Passwort eingepackte Kopie des FEK herunterlädt, oder von Gerät zu Gerät über einen ECDH-Schlüsselaustausch, bei dem der FEK eingepackt reist und der Server nur öffentliche Schlüssel weiterreicht.

Welches Problem das tatsächlich löst

Die meisten Synchronisationen heißen „Vertrauen Sie dem Anbieter“. Notion speichert Ihre Seiten im Klartext auf seinen Servern. Dropbox hält die Schlüssel zu den Dateien, die es im Ruhezustand verschlüsselt, was bedeutet, dass Dropbox (oder eine Behörde, die bei Dropbox anfragt) sie lesen kann. Selbst Werkzeuge, die bei der Übertragung verschlüsseln, entschlüsseln meist bei der Ankunft, damit sie Ihre Inhalte auf dem Server indexieren, in der Vorschau zeigen oder durchsuchen können.

Dieses Modell ist bequem, und es ist zugleich das ganze Problem. Bequemlichkeit auf dem Server bedeutet Lesbarkeit auf dem Server. Wenn der Anbieter ein Vorschaubild Ihres Dokuments erzeugen kann, kann der Anbieter Ihr Dokument lesen.

Die Vorgabe für Filarr war das Gegenteil: Das Synchronisations-Backend musste wirklich unfähig sein, irgendetwas zu lesen, was es speichert, und trotzdem die nützliche Arbeit erledigen, Bytes zwischen Ihren Rechnern zu bewegen und Konflikte aufzulösen. „Zero-Knowledge“ ist hier kein Marketingadjektiv, sondern eine Designanforderung, die bestimmt hat, wo die Verschlüsselung stattfindet und was der Server wissen darf.

So funktioniert es, Schritt für Schritt

1. Die Verschlüsselung ist schon passiert, bevor es die Synchronisation gibt

Das ist die Schlüsselidee, die den Rest einfach macht. In Filarr werden Dateien auf der Festplatte mit AES-256-GCM verschlüsselt, unter Ihrem Kontoschlüssel und mit einem neuen Zufallswert pro Datei, in dem Moment, in dem sie in Ihren Tresor gelangen. Die Synchronisation hat keine Verschlüsselung hinzugefügt. Die Synchronisation erbt sie.

Wenn der Synchronisationsdienst eine Datei zum Hochladen liest, liest er die bereits verschlüsselten Bytes von der Festplatte und sendet sie unverändert. Es gibt keinen Schritt „entschlüsseln, dann neu verschlüsseln“, keinen Zwischenbereich im Klartext. Der Kommentar am Anfang des Synchronisationsdienstes sagt es klar: „Files on disk are already encrypted with FEK, uploaded as-is.“ (Die Dateien auf der Festplatte sind bereits mit dem FEK verschlüsselt und werden unverändert hochgeladen.) Der Server empfängt Chiffretext, weil außerhalb des Arbeitsspeichers der App nie etwas anderes existiert hat als Chiffretext.

2. Dateinamen werden zu undurchsichtigen IDs

Ein Blob aus Chiffretext ist für einen Angreifer nutzlos, ein Dateiname wie „kuendigungsschreiben-final.pdf“ dagegen nicht. Deshalb sendet Filarr nie Dateinamen.

Wenn sich eine Datei ändert, leitet der Synchronisationsdienst eine Kennung ab, indem er ihren lokalen Pfad hasht: crypto.createHash('sha256').update(localPath).digest('hex').slice(0, 32). Der Kommentar im Code ist ausdrücklich, was die Absicht angeht: „Derive opaque fileId from local path, never expose real file names.“ (Eine undurchsichtige fileId aus dem lokalen Pfad ableiten, nie echte Dateinamen preisgeben.) Ordner werden über ihre UUIDs referenziert, die ebenfalls keine Bedeutung tragen. Auf dem Server liegen Ihre Dateien unter einem Pfad wie users/{userId}/profiles/{profileId}/files/{fileId}/chunk_0.enc, bei dem jedes Segment entweder eine zufällige ID oder ein undurchsichtiger Hash ist.

3. Dateien werden in Blöcke zerlegt

Vor dem Hochladen werden Dateien in Blöcke von 4 MB aufgeteilt (CHUNK_SIZE = 4 * 1024 * 1024). Jeder Block wird als eigenes .enc-Objekt in Cloudflare R2 gespeichert. Die Zerlegung hält einzelne Uploads klein genug, um sie bei einer wackeligen Verbindung günstig zu wiederholen, und sie bedeutet, dass eine große, geänderte Datei keine einzige monolithische Übertragung erzwingt. Die Uploads laufen in kleinen parallelen Paketen (drei gleichzeitig) mit einer dauerhaften Wiederholungswarteschlange dahinter, sodass eine abgebrochene Verbindung fortgesetzt statt neu gestartet wird.

4. Das Manifest: Wie sich Geräte auf die Wirklichkeit einigen

Hier kommt der wirklich interessante Teil, denn hier hat ein Zero-Knowledge-System normalerweise sein Leck. Zum Synchronisieren müssen sich zwei Geräte einigen, welche Dateien existieren, welche sich geändert haben und welche einen Konflikt gewonnen hat. Diese Abstimmung verlangt normalerweise, dass der Server Ihre Dateistruktur versteht. Der Server von Filarr tut das nicht.

Es gibt zwei Manifeste, und der Unterschied zählt:

Das lokale Manifest (sync-manifest.json) liegt auf Ihrer Festplatte und ist nicht verschlüsselt, enthält aber bewusst nichts Sensibles. Es enthält SHA-256-Prüfsummen, Größen in Bytes, Synchronisationsstatus und undurchsichtige Datei-IDs. Keine Dateinamen, keine Inhalte. Das Feld localPath, das eine ID wieder einem echten Pfad zuordnet, existiert nur in dieser lokalen Kopie und wird entfernt, bevor irgendetwas in die Cloud geht.

Das Cloud-Manifest (manifest.enc auf R2) ist die gemeinsame maßgebliche Quelle zwischen den Geräten, und es ist mit Ihrem FEK per AES-256-GCM verschlüsselt (encryptWithFEK). Sein Format auf der Festplatte ist eine kurze Markierung („fek:“), gefolgt von einem 12-Byte-IV und dem Chiffretext mit seinem GCM-Authentifizierungs-Tag. Der Server speichert das als einen weiteren undurchsichtigen Blob. Wenn ein zweites Gerät den Stand der Dinge erfahren will, lädt es diesen Blob herunter und entschlüsselt ihn lokal, weil es den FEK hat. Der Server kann das nie.

Die gesamte Logik des Zusammenführens (welche Datei neuer ist, welche sich auf beiden Seiten geändert hat und daher ein Konflikt ist) läuft auf Ihrem Gerät, auf dem entschlüsselten Manifest, in mergeWithRemote. Die einzige Aufgabe des Servers rund um das Manifest ist die Versionskontrolle.

5. Optimistisches Sperren, damit sich zwei Geräte nicht gegenseitig überschreiben

Jedes Profil hat einen Zähler manifest_version, der in der D1-Datenbank des Workers gespeichert ist. Wenn ein Gerät ein neues Manifest hochladen will, teilt es dem Server mit, welche Version es für aktuell hält. Stimmt die Version des Servers nicht überein, gibt er einen Konflikt 409 zurück, und der Upload wird abgelehnt (if (profileSync.manifest_version !== body.version) return ... 409). Das Gerät holt dann erneut ab, führt erneut zusammen und versucht es im nächsten Durchlauf noch einmal.

Das ist der elegante Trick: Der Server kann „pro Version gewinnt nur ein Schreiber“ allein mit einer Ganzzahl durchsetzen. Er muss den Inhalt des Manifests nie verstehen, um zu verhindern, dass zwei Geräte gegenseitig ihren Zustand beschädigen. Koordination ohne Verständnis.

6. Uploads und Downloads laufen über einen Token-Proxy

Worker können keine klassischen vorsignierten URLs im S3-Stil direkt erzeugen, deshalb verwendet Filarr ein Token-Muster. Das Gerät stellt eine authentifizierte Anfrage nach einem Upload-Platz, der Worker prüft Ihr Speicherkontingent, legt in KV einen kurzlebigen Absichtseintrag ab (Gültigkeit 15 Minuten), dessen Schlüssel ein zufälliges Token ist, und gibt eine Token-URL zurück. Das Gerät sendet den verschlüsselten Block dann per PUT an diese URL, und der Worker streamt ihn in R2 und erhöht Ihren Verbrauchszähler. Das Token ist die Berechtigung für genau diesen einen Vorgang und wird bei Verwendung gelöscht. Die Bytes, die durchlaufen, sind wiederum bereits verschlüsselter Chiffretext.

7. Ihren Schlüssel auf ein zweites Gerät bringen, ohne ihn je im Klartext zu senden

Alles oben setzt voraus, dass beide Geräte den FEK haben. Der einfachste Weg, ihn dorthin zu bringen, ist, sich auf dem neuen Gerät anzumelden: Der Server sendet die unter Ihrem Passwort eingepackte Kopie des FEK, und das Gerät packt sie lokal aus. Der andere Weg kommt ohne Passwort aus: Sie koppeln das neue Gerät mit einem, das bereits entsperrt ist. Wie also bringt die Kopplung den Schlüssel hinüber, ohne dass der Server ihn je sieht?

Die Kopplung verwendet einen flüchtigen ECDH-Schlüsselaustausch auf der Kurve P-256. Der Ablauf, aus pairingService.ts:

Gerät A (das Ihren Tresor bereits hat) erzeugt ein flüchtiges ECDH-Schlüsselpaar und einen zufälligen 6-stelligen Code. Gerät B erzeugt sein eigenes ECDH-Schlüsselpaar. Jedes Gerät veröffentlicht seinen öffentlichen Schlüssel auf dem Server, holt den des anderen und leitet unabhängig dasselbe gemeinsame 256-Bit-Geheimnis ab. Der Schlüssel, der den FEK einpackt, wird aus diesem gemeinsamen Geheimnis und aus einem 32-Byte-Geheimnis abgeleitet, das Gerät A in den QR-Code legt und nie an den Server sendet; im manuellen Modus, ohne QR-Code, zeigen beide Bildschirme sechs aus dem Austausch abgeleitete Prüfziffern, und Sie bestätigen, dass sie übereinstimmen, bevor irgendetwas eingepackt wird. Gerät A packt den FEK dann mit diesem Schlüssel per AES-GCM ein und lädt den eingepackten Schlüssel hoch. Gerät B lädt ihn herunter, packt ihn aus und speichert ihn lokal, neu eingepackt unter seinem eigenen Passwort.

Der FEK geht genau einmal über die Leitung, und nur in einer Form, die das gemeinsame Geheimnis zum Öffnen braucht. Der Kommentar nennt die Garantie: „The FEK never leaves a device in cleartext.“ (Der FEK verlässt ein Gerät nie im Klartext.) Der Server reicht öffentliche Schlüssel und einen eingepackten Blob weiter. Er hat nie das gemeinsame Geheimnis, also hat er nie den FEK.

Die Kopplungssitzung ist gehärtet: Der 6-stellige Code läuft nach 5 Minuten ab, und der Server begrenzt das Abrufen öffentlicher Schlüssel auf 3 Versuche, bevor er die Sitzung vollständig ungültig macht, was einen Brute-Force-Angriff auf den Code abstumpft.

8. Wo der FEK tatsächlich liegt

Auf jedem Gerät wird der FEK eingepackt gespeichert. Er ist durch einen KEK (Key Encryption Key) verschlüsselt, der per PBKDF2-SHA512 mit 600.000 Iterationen aus Ihrem Passwort abgeleitet wird (weit über den 210.000, die die OWASP für PBKDF2-SHA512 empfiehlt), und zusätzlich über safeStorage von Electron im Schlüsselbund des Betriebssystems zwischengespeichert. Ihr Passwort leitet den KEK ab, der KEK packt den FEK aus, und der FEK entschlüsselt Ihre Dateien. Der Server behält eine Kopie des eingepackten FEK, damit sich ein neues Gerät anmelden kann, aber nie den FEK im Klartext.

Designentscheidungen und ihre Kompromisse

Einmal an der Tresorgrenze verschlüsseln, nicht an der Synchronisationsgrenze. Wenn Dateien von Anfang an als Chiffretext auf der Festplatte liegen, wird die Synchronisation zu einer dummen Leitung, und die Zero-Knowledge-Eigenschaft ergibt sich von selbst. Der Kompromiss: Der Server kann Ihnen buchstäblich bei nichts helfen, was den Inhalt betrifft – keine Suche auf dem Server, keine Vorschaubilder, keine Webvorschau. Das ist ein echter Funktionsverlust, und es ist der ehrliche Preis der Garantie.

Zusammenführen auf dem Client statt auf dem Server. Das Zusammenführen auf dem Gerät hält den Server unwissend, bedeutet aber, dass die Konfliktlösung von den Uhren der Geräte abhängt und davon, dass die Manifeste in der richtigen Reihenfolge abgeholt werden. Der Algorithmus stützt sich auf die Zeitstempel updatedAt und syncedAt, und wenn sich seit der letzten Synchronisation beide Seiten geändert haben, wählt er nicht stillschweigend einen Gewinner: Er verzweigt und schreibt eine Kopie _conflict_{timestamp}, damit nichts verloren geht. Sicherer, aber es kann Ihnen Duplikate hinterlassen, die Sie von Hand abgleichen müssen.

Ein Token-Proxy statt direkt vorsignierter R2-URLs. Die Bytes über den Worker zu leiten, fügt gegenüber einer echten vorsignierten URL direkt zum Speicher einen Zwischenschritt und etwas Latenz hinzu. Im Gegenzug bleiben Kontingentprüfung und Zugriffskontrolle zentral und einfach, und da die Nutzlast bereits verschlüsselt ist, sieht der zusätzliche Zwischenschritt nichts.

Blöcke von 4 MB. Kleine Blöcke machen Wiederholungen günstig und Parallelität einfach, um den Preis von mehr Objekten und mehr Hin- und Rückwegen bei großen Dateien. Für einen Arbeitsbereich aus Notizen und Dokumenten ist das die richtige Gewichtung.

Bedrohungsmodell: Was das schützt und was nicht

Was ein Angreifer bekommt, der die Daten des Servers kopiert (oder sie per behördlicher Anfrage vom Anbieter übermittelt bekommt): einen Haufen undurchsichtiger .enc-Blobs, ein verschlüsseltes Manifest, das er nicht öffnen kann, undurchsichtige Datei-IDs, einen Versionszähler und die eingepackte Kopie Ihres FEK. Ohne Ihr Passwort oder Ihre Wiederherstellungsphrase kann er Ihre Dateien, Ihre Notizen, Ihre Dateinamen und Ihre Ordnerstruktur nicht lesen. Ein Angreifer, der den Server kontrolliert, während Sie ihn nutzen, kann Ihr Passwort nicht aus der Anmeldung einer aktuellen App abgreifen: Seit dem 16. Oktober 2026 sendet die Anmeldung einen aus Ihrem Passwort abgeleiteten Schlüssel, nicht das Passwort, und dieser Schlüssel kann den FEK nicht auspacken. Während einer Übergangszeit von etwa zwei Monaten senden allerdings ein Konto, das sich noch nicht erneut angemeldet hat, oder eine ältere App-Version noch das Passwort selbst (über HTTPS), und ein veränderter Server könnte es abfangen und diese Kopie auspacken.

Was derselbe Angreifer weiterhin beobachten kann (seien wir ehrlich): Metadaten. Konkret die Zahl Ihrer Dateien, die Größe jedes Blobs, die Zahl der Blöcke, Ihren gesamten Speicherverbrauch und den Zeitpunkt Ihrer Synchronisationen. Dateigrößen und Änderungshäufigkeit können Muster verraten. Das ist die klassische Grenze jedes verschlüsselten Speichers, der echte Objektgrößen speichert, und Filarr füllt nicht auf und bündelt nicht, um sie zu verbergen. Wenn Ihr Bedrohungsmodell einen Gegner umfasst, der Datenverkehr und Größen analysiert, sollten Sie wissen, dass diese Schicht nicht dafür gebaut ist, das zu vereiteln.

Das Zeitfenster der Kopplung verdient einen eigenen Vorbehalt. Während der Kopplung reicht der Server beide öffentlichen Schlüssel weiter, ein böswilliger Server könnte also einen Man-in-the-Middle-Angriff auf den ECDH-Austausch versuchen, indem er eigene öffentliche Schlüssel unterschiebt. In der ersten Version des Protokolls funktionierte dieser Angriff: Der 6-stellige Code, der als Salt für den Einpackschlüssel diente, ist auch dem Server bekannt. Die aktuelle Version schließt die Lücke: Der Einpackschlüssel hängt zusätzlich vom Geheimnis im QR-Code ab, das keine Serverroute je empfängt, Gerät A legt sich auf seinen öffentlichen Schlüssel fest, bevor es den von B sieht, und im manuellen Modus verraten die sechs Prüfziffern auf beiden Bildschirmen einen untergeschobenen Schlüssel. Es lohnt sich, das zu benennen, statt es wegzureden.

Bekannte Grenzen

• Metadaten werden nicht verborgen. Blobgrößen, Dateianzahl und Synchronisationszeitpunkte sind für den Server sichtbar. Inhalte und Namen nicht.
• Zero-Knowledge schneidet in beide Richtungen. Weil der Server Ihren Schlüssel nur eingepackt hält, gibt es kein „Passwort vergessen“-Zurücksetzen, das Ihre Daten wiederherstellt. Verlieren Sie Ihr Passwort und Ihre Wiederherstellungsphrase aus 24 Wörtern, ist der Chiffretext nicht wiederherstellbar. Das ist der Preis dafür, dass der Server Sie nicht lesen kann.
• Keine Serverfunktionen für Ihre Inhalte. Suche, Vorschauen und Webzugriff auf Dateiinhalte können konstruktionsbedingt nicht auf dem Server existieren.
• Der Abschied von der Passwortanmeldung ist noch nicht abgeschlossen. Seit dem 16. Oktober 2026 meldet sich eine aktuelle App mit einem abgeleiteten Schlüssel an. Etwa zwei Monate lang senden ein Konto, das sich noch nicht erneut angemeldet hat, oder eine ältere App-Version noch das Passwort (abgeglichen mit einem bcrypt-Hash, nicht gespeichert), das ein kompromittierter Server abfangen könnte, wie oben beschrieben.
• Alte Manifeste. Ältere Manifeste, die mit einem gerätelokalen Schlüssel verschlüsselt sind, werden automatisch erkannt und migriert; das geschieht transparent, erinnert aber daran, dass sich das Format weiterentwickelt hat.

Ein Hinweis zur Lizenz für technisch Neugierige: Der Desktop-Client von Filarr ist unter der BSL 1.1 veröffentlicht („source available“), die Art, wie er Ihre Dateien auf der Festplatte verschlüsselt, ist also einsehbar. Der in diesem Artikel beschriebene Code ist es nicht: sync.ts, syncService.ts und pairingService.ts gehören zu den Cloud-Modulen, die nicht veröffentlicht sind. Die Zitate oben stammen aus diesem privaten Code.

Technische FAQ

F: Wird der verschlüsselte Inhalt auf dem Server je entschlüsselt, und sei es nur kurz? Nein. Dateien liegen bereits als AES-256-GCM-Chiffretext auf der Festplatte, bevor die Synchronisation läuft, und werden Byte für Byte in dieser Form hochgeladen. Der Worker streamt Blobs in R2, ohne je einen Schlüssel zu halten. Nirgendwo auf dem Server gibt es einen Entschlüsselungsschritt.

F: Wie stimmt ein zweites Gerät die Synchronisation ab, wenn der Server das Manifest nicht lesen kann? Das Cloud-Manifest ist selbst mit Ihrem FEK verschlüsselt. Jedes Gerät lädt es herunter, entschlüsselt es lokal und führt das gesamte Zusammenführen auf dem Gerät durch. Der Server setzt nur einen ganzzahligen Versionszähler durch (optimistisches Sperren), um zu verhindern, dass sich zwei Geräte gegenseitig überschreiben, und das kann er, ohne den Inhalt zu verstehen.

F: Wie gelangt der Verschlüsselungsschlüssel auf mein neues Gerät, ohne den Server im Klartext zu berühren? Entweder durch Anmelden, wobei die unter Ihrem Passwort eingepackte Kopie des FEK heruntergeladen wird, oder über einen flüchtigen ECDH-Austausch auf der Kurve P-256. Im zweiten Fall leiten beide Geräte ein gemeinsames Geheimnis ab, der FEK wird mit einem daraus abgeleiteten Schlüssel per AES-GCM eingepackt, und nur der eingepackte Blob wird weitergereicht. Der Server erfährt den Einpackschlüssel nie, also erfährt er nie den FEK. Der Kopplungscode läuft nach 5 Minuten ab und ist auf 3 Versuche begrenzt.

F: Kann Filarr meine Dateien bei einer behördlichen Anfrage lesen? Nicht aus dem, was es speichert. Filarr hält Ihren Schlüssel nur eingepackt, unter Ihrem Passwort und Ihrer Wiederherstellungsphrase. Der Server speichert undurchsichtige Blobs und ein verschlüsseltes Manifest, das er nicht öffnen kann, es gibt also nichts Lesbares zu übermitteln. Die Grenze ist die oben genannte: Während der Übergangszeit könnte ein Server, der so verändert wurde, dass er das Passwort eines Kontos abfängt, das es noch sendet, anschließend den Schlüssel dieses Kontos auspacken. Die Kehrseite: Filarr kann Ihre Daten auch nicht wiederherstellen, wenn Sie Passwort und Wiederherstellungsphrase verlieren.

F: Kann ich meinen eigenen Speicher statt dem von Filarr verwenden? Ja. Die Synchronisation unterstützt BYOS (Bring Your Own Storage) mit jedem S3-kompatiblen Bucket, die verschlüsselten Blobs landen also in einem Speicher, den Sie kontrollieren, während dieselben Zero-Knowledge-Eigenschaften gelten.

F: Welche Metadaten kann der Server trotzdem über mich ableiten? Die Zahl der Dateien, die Größe der einzelnen Blobs, die Zahl der Blöcke, den gesamten belegten Speicher und die Zeitstempel der Synchronisation. Dateinamen, Ordnernamen oder Inhalte kann er nicht ableiten. Wenn Ihnen das Verbergen von Größen und Zeitpunkten wichtig ist: Diese Schicht füllt sie nicht auf und verschleiert sie nicht.

Wenn Sie einen Teil davon selbst prüfen möchten: Der Code des Desktop-Clients ist öffentlich (BSL 1.1) und zeigt, wie Ihre Dateien auf der Festplatte verschlüsselt werden. Die drei hier zitierten Dateien – infra/cloudflare-worker/src/sync.ts für die Serverseite, electron/sync/syncService.ts für die Steuerung auf dem Gerät und electron/pairingService.ts für den Schlüsselaustausch – gehören zu den privaten Cloud-Modulen, nicht zum öffentlichen Repository.