IT'S THE FOUNDATION.

Deine Geheimnisse verdienen mehr als einen sicheren Speicherort.

Ein Passwortmanager schützt weit mehr als Passwörter.

Er verwaltet digitale Identitäten, geschäftliche Zugangsdaten, Bankverbindungen, vertrauliche Dokumente, private kryptografische Schlüssel und Informationen, deren Verlust oder Offenlegung schwerwiegende Folgen haben kann.

Solche Informationen benötigen mehr als einen starken Verschlüsselungsalgorithmus.

Sie benötigen eine Sicherheitsarchitektur, die den gesamten Lebenszyklus dieser Daten berücksichtigt.

Vom ersten Speichern über die tägliche Nutzung bis zur Änderung, Synchronisation, Wiederherstellung und Löschung.

Denn Sicherheitsprobleme entstehen nicht ausschließlich durch Angreifer.

Sie entstehen auch durch unerwartete Fehler.

Ein Datenträger kann während eines Schreibvorgangs voll werden. Eine Anwendung kann abstürzen. Ein Computer kann bei einem Stromausfall plötzlich ausgeschaltet werden. Zwei Geräte können denselben Datensatz gleichzeitig verändern. Ein Cloudserver kann unvollständige oder veraltete Informationen ausliefern.

VORQYN behandelt diese Situationen nicht als unwahrscheinliche Ausnahmen.

Sie sind Bestandteil des Sicherheitsmodells.

Die Architektur kombiniert bewährte Kryptografie, unabhängiges Schlüsselmaterial, eine mehrstufige Schlüsselhierarchie, einzeln verschlüsselte Datensätze und ein authentifiziertes, transaktionsorientiertes Speichersystem.

Das Ergebnis ist ein Passwortmanager, bei dem nicht nur die Inhalte verschlüsselt sind, sondern auch ihre Speicherung, Änderung, Synchronisation und Wiederherstellung nach definierten Sicherheitsregeln erfolgt.

Eine durchgängige Sicherheitsarchitektur

Verschlüsselung schützt Inhalte.

Schlüsselmanagement kontrolliert den Zugriff.

Authentifizierte Commits schützen die Datenkonsistenz.

Objektbasierte Speicherung ermöglicht effiziente Änderungen.

Kryptografische Prüfungen erkennen Manipulationen.

Kontrollierte Recovery-Verfahren behandeln unterbrochene Schreibvorgänge.

Und der Benutzer behält die Kontrolle darüber, wo sein Tresor gespeichert wird und welche Geräte oder Personen Zugriff erhalten.

VORQYN

Your Keys. Your Rules.

Die Sicherheitsarchitektur von VORQYN unterscheidet sechs eigenständige Ziele.

Diese Unterscheidung ist wichtig, weil nicht jeder Schutzmechanismus sämtliche Risiken gleichermaßen abdeckt.

2.1 Confidentiality – Vertraulichkeit

Vertrauliche Tresorinhalte werden kryptografisch geschützt.

Ein Angreifer, der ausschließlich eine verschlüsselte Tresorkopie besitzt, erhält dadurch nicht automatisch Zugriff auf die enthaltenen Passwörter, Dokumente oder privaten Schlüssel.

Die Entschlüsselung benötigt das passende Schlüsselmaterial und einen gültigen kryptografischen Kontext.

2.2 Integrity – Integrität

VORQYN prüft, ob gespeicherte Daten seit ihrer authentifizierten Verschlüsselung unzulässig verändert wurden.

Manipulationen am Ciphertext, an authentifizierten Metadaten oder an kryptografisch gebundenen Objektidentitäten führen zu einer fehlgeschlagenen Prüfung.

Ungültige Daten werden nicht einfach als gültiger Klartext bereitgestellt.

2.3 Consistency – Konsistenz

Ein gültiger Tresorzustand besteht aus zusammengehörigen und vollständig verfügbaren Objekten.

Ein Commit darf nicht auf unvollständige oder ungültige aktive Datensatzrevisionen verweisen.

Die Konsistenzprüfung berücksichtigt deshalb die Beziehung zwischen Commit, Records, Blobs und Indexinformationen.

2.4 Recoverability – Wiederherstellbarkeit

Nach einem unterbrochenen Schreibvorgang ermittelt VORQYN anhand seiner authentifizierten Commit-Historie den eindeutig gültigen Zustand.

Eine beschädigte lokale Head-Datei bedeutet nicht automatisch, dass der eigentliche Tresorzustand verloren ist.

Wiederherstellung setzt jedoch voraus, dass die erforderlichen authentischen Daten und Schlüssel tatsächlich verfügbar sind.

2.5 Availability – Verfügbarkeit

VORQYN arbeitet lokal und offline.

Die Benutzung eines vorhandenen lokalen Tresors benötigt keine permanente Internetverbindung.

Ein Ausfall eines Cloudanbieters oder eines Herstellerservers verhindert nicht grundsätzlich den Zugriff auf bereits lokal verfügbare und berechtigt entsperrbare Daten.

2.6 User Sovereignty – Kontrolle des Benutzers

Der Benutzer entscheidet über Speicherort, Synchronisationsziele und Freigaben.

Die lokale Entschlüsselung hängt nicht von einer aktiven Lizenzprüfung oder einer permanent erreichbaren Herstellerinfrastruktur ab.

Warum diese Unterscheidung wichtig ist

Integrität bedeutet nicht Aktualität.

Eine vollständig authentische Tresorkopie kann veraltet sein.

Konsistenz bedeutet nicht absolute Verfügbarkeit.

Ein gültiger Datenbestand kann bei vollständiger Zerstörung sämtlicher Kopien verloren gehen.

Verschlüsselung bedeutet nicht absolute Endgerätesicherheit.

Ein bereits kompromittiertes Gerät kann unter Umständen während der legitimen Verwendung Geheimnisse abgreifen.

VORQYN beschreibt diese Grenzen ausdrücklich, statt unterschiedliche Sicherheitsversprechen miteinander zu vermischen.

Sicherheit durch klar getrennte Verantwortlichkeiten

VORQYN verwendet eine mehrschichtige Architektur.

Benutzeroberfläche, Kryptografie, Dateisystemzugriff und Synchronisation erfüllen unterschiedliche Aufgaben.

3.1 Warum der Sicherheitskern in Rust implementiert ist

Rust bietet ein Ownership- und Speichersicherheitsmodell, das zahlreiche klassische Speicherfehler bereits auf Sprachebene verhindert.

Dazu gehören insbesondere bestimmte Use-after-free-Fehler, ungültige Speicherreferenzen und unkontrollierte konkurrierende Speicherzugriffe.

Die sicherheitskritischen Operationen werden im gemeinsamen Rust-Core zentralisiert.

Die Flutter-Oberfläche implementiert keine eigenständige parallele Tresorverschlüsselung.

Dadurch reduziert sich die Anzahl der Komponenten, in denen kryptografische Entscheidungen getroffen werden.

Rust allein macht Software jedoch nicht automatisch sicher.

Logikfehler, fehlerhafte Fremdschnittstellen, unsichere Abhängigkeiten, Betriebssystemprobleme und kompromittierte Endgeräte bleiben relevante Risiken.

3.2 Definierte Schnittstelle zwischen Flutter und Rust

Flutter kommuniziert mit dem Rust-Core über versionierte Schnittstellen.

Datenformate, Puffergrößen und Operationen besitzen definierte Grenzen.

Der Core überprüft beispielsweise:

• Unterstützte Schnittstellenversionen.
• Gültige Datentypen.
• Zulässige Eingabelängen.
• Konsistente Objektidentitäten.
• Erlaubte Operationen.
• Den aktuellen Tresor- und Sitzungszustand.

Die Oberfläche kann nicht allein durch das Anzeigen eines Bestätigungsdialogs eine kryptografische Autorisierung ersetzen.

3.3 Die Klartextgrenze

VORQYN verarbeitet vertrauliche Inhalte grundsätzlich innerhalb der autorisierten Clientumgebung.

Für bestimmte Funktionen müssen entschlüsselte Inhalte jedoch vorübergehend an die Oberfläche oder eine Zielanwendung übergeben werden.

Beispiele sind das Anzeigen eines Passworts, das Kopieren in die Zwischenablage oder Autofill.

Diese Übergaben sind ausdrücklich Teil des Bedrohungsmodells.

Ein kompromittierter Browser oder eine bösartige Anwendung kann solche legitim übergebenen Inhalte möglicherweise lesen.

3.4 Der Cloudanbieter ist kein Entschlüsselungsdienst

VORQYN trennt die kryptografische Tresorverwaltung vom Speicheranbieter.

Ein Cloudserver erhält verschlüsselte Objekte und die dafür erforderlichen äußeren Transportinformationen.

Für das Speichern oder Weiterleiten dieser Daten benötigt er keine Masterpasswörter, Record-DEKs oder Vault-Entschlüsselungsschlüssel.

Ein kompromittierter Provider kann allerdings Daten löschen, zurückhalten oder alte gültige Versionen präsentieren.

Deshalb prüft der Client Integrität, Konsistenz und – soweit vertrauenswürdige Referenzen vorhanden sind – Aktualität selbst.

VORQYN entwickelt keine eigenen Verschlüsselungsalgorithmen.

Der Rust-Core kombiniert etablierte Verfahren mit versionierten, überprüfbaren Protokollen.

4.1 Argon2id – Speicherharte Passwortableitung

Ein menschlich gewähltes Masterpasswort besitzt üblicherweise weniger Entropie als ein zufällig generierter 256-Bit-Schlüssel.

VORQYN verwendet das Passwort daher nicht unmittelbar als Verschlüsselungsschlüssel.

Stattdessen verarbeitet Argon2id die Eingabe mit einem zufälligen Salt und einem versionierten Sicherheitsprofil.

Ein definiertes KDF-Profil verwendet:

Die konkreten Salt-, Kodierungs- und Formatparameter werden im kryptografischen Protokollvertrag festgelegt.

Warum speicherhart?

Bei einem Offline-Angriff kann ein Angreifer versuchen, viele Passwortkandidaten zu berechnen.

Ein speicherhartes Verfahren erhöht die Ressourcen, die für solche Versuche erforderlich sind.

Neben Rechenleistung wird eine erhebliche Menge Arbeitsspeicher benötigt.

Das erschwert die wirtschaftliche und technische Skalierung massenhaft parallelisierter Angriffe.

Allerdings macht auch Argon2id ein schwaches Masterpasswort nicht automatisch stark.

Bei fehlendem Arbeitsspeicher wechselt VORQYN nicht stillschweigend auf ein schwächeres KDF-Profil.

Eine fehlgeschlagene Schlüsselableitung führt zu einem kontrollierten Fehler.

4.2 HKDF-SHA-256 – Kryptografische Zwecktrennung

HKDF verwendet HMAC als Grundlage einer kontrollierten Schlüsselableitung.

VORQYN nutzt HKDF-SHA-256 zur Trennung verschiedener kryptografischer Aufgaben.

Ein Schlüssel zum Schutz eines Root-Manifests besitzt eine andere Aufgabe als ein Schlüssel zur Commit-Authentifizierung oder zum Verpacken eines Record-DEKs.

Dafür verwendet die Architektur eindeutig kodierte Zweckkontexte.

Beispiele:

VORQYN/root-manifest-key/v1

VORQYN/commit-key/v1

VORQYN/record/v1

VORQYN/blob-chunk/v1

Diese sogenannte Domain Separation verhindert, dass verschiedene Protokollaufgaben versehentlich dieselbe Schlüsselableitung verwenden.

HKDF erzeugt dabei keine zusätzliche Entropie aus schwachem Material.

Die Sicherheit hängt von geeignetem Ausgangsmaterial, korrekter Kodierung und eindeutig getrennten Kontexten ab.

4.3 XChaCha20-Poly1305 – Vertraulichkeit und Integrität

XChaCha20-Poly1305 ist ein AEAD-Verfahren.

AEAD steht für Authenticated Encryption with Associated Data.

Es verbindet die Verschlüsselung vertraulicher Daten mit einer kryptografischen Authentifizierungsprüfung.

Die 192-Bit-Nonce ermöglicht die robuste Verwendung zufällig generierter Nonces innerhalb der vorgesehenen kryptografischen Nutzungsgrenzen.

Jeder Entschlüsselungsvorgang prüft die Authentizität des Ciphertexts und der zugehörigen authentifizierten Kontextinformationen.

Wird eine relevante Information manipuliert, schlägt die Prüfung fehl.

Der Core gibt dann keinen vermeintlich gültigen Klartext aus.

Warum nicht nur verschlüsseln?

Eine reine Verschlüsselung ohne geeignete Authentifizierung schützt nicht automatisch vor manipulierbaren verschlüsselten Daten.

Ein Passwortmanager muss jedoch erkennen, wenn Datensätze, Schlüsselkontexte oder Referenzen verändert wurden.

Deshalb ist die authentifizierte Verschlüsselung ein zentraler Bestandteil des VORQYN-Speicherformats.

4.4 Kryptografisch sichere Zufallszahlen

VORQYN erzeugt zufälliges Schlüsselmaterial über die kryptografisch sichere Zufallsquelle des jeweiligen Betriebssystems.

Dazu gehören:

• Secret Factors.
• Zufällige Root- und Vault-Schlüssel.
• Record-DEKs.
• Blob-Schlüssel.
• Salts.
• Nonces.
• Zufällige Objekt- und Revisionsidentifikatoren.

Unsichere Pseudozufallsverfahren werden nicht zur Erzeugung kryptografischer Geheimnisse verwendet.

Zwei unabhängige Schlüsselquellen

VORQYN kombiniert ein vom Benutzer gewähltes Masterpasswort mit einem unabhängig erzeugten kryptografischen Secret Factor.

Der Secret Factor besteht aus 256 Bit Zufallsmaterial.

Er wird weder aus dem Masterpasswort noch aus einem Benutzernamen, einer E-Mail-Adresse oder einer Gerätekennung berechnet.

5.1 Erzeugung des Secret Factors

Der Rust-Core erzeugt 32 zufällige Bytes über die Betriebssystem-CSPRNG.

Eine dateibasierte Verwahrung verwendet das versionierte Format VQYFACT1.

Das Format wird beim Einlesen strikt validiert.

Falsche Dateigrößen, unbekannte Versionen und fehlerhafte Header werden abgelehnt.

5.2 Der Entsperrvorgang

Das Masterpasswort wird zunächst mit Argon2id verarbeitet.

Anschließend kombiniert ein zweckgebundener HKDF-Prozess das abgeleitete Passwortschlüsselmaterial mit dem unabhängigen Secret Factor.

Daraus entsteht der Unlock Key.

Vereinfacht:

MASTER PASSWORD                SECRET FACTOR
       |                         |
       v                         |
    Argon2id                     |
       |                         |
       +------------+------------+
                    |
                    v
               HKDF-SHA-256
                    |
                    v
                UNLOCK KEY
                    |
                    v
               KEY ENVELOPE
                    |
                    v
                   LPRK

Die exakte Reihenfolge, Salt-Behandlung und Kodierung der einzelnen Ableitungsschritte gehören zum versionierten kryptografischen Formatvertrag.

5.3 Warum der Secret Factor wichtig ist

Ein Angreifer, der lediglich verschlüsselte Tresordaten stiehlt, besitzt nicht automatisch den unabhängigen Secret Factor.

Ein Angriff auf das Masterpasswort allein reicht unter diesen Voraussetzungen nicht aus, um den vorgesehenen Unlock Key zu rekonstruieren.

Der Factor verbessert damit insbesondere die Sicherheit gegen isolierten Tresordiebstahl.

5.4 Was der Secret Factor nicht schützt

Die Schutzwirkung hängt wesentlich von seiner Aufbewahrung ab.

Befindet sich der Faktor lokal unter denselben Benutzerrechten wie der Tresor, kann Malware mit Zugriff auf diesen Benutzerkontext möglicherweise beide Bestandteile erhalten.

Der Factor ist deshalb nicht automatisch ein vollwertiger zweiter Authentifizierungsfaktor gegenüber sämtlichen lokalen Angriffen.

VORQYN bezeichnet ihn als unabhängiges kryptografisches Schlüsselmaterial zur Verstärkung des Entsperrverfahrens.

5.5 Externe Aufbewahrung – Sicherheit gegen Wiederherstellbarkeit abwägen

Der Factor kann unabhängig vom Tresor aufbewahrt werden.

Beispiele sind ein getrennt verwahrtes USB-Speichermedium, ein zweites Gerät oder eine dafür geeignete Offline-Recovery-Darstellung.

Eine solche Trennung kann den Schutz gegenüber dem gleichzeitigen Diebstahl von Tresor und Schlüsselmaterial erhöhen.

Sie bringt jedoch einen wesentlichen Zielkonflikt mit sich.

Physisch getrennt aufbewahrt

Die Wahrscheinlichkeit eines gemeinsamen Diebstahls mit der Tresordatei kann sinken.

Dafür steigt die Bedeutung einer sorgfältigen Sicherung und Wiederherstellung.

Dauerhaft angeschlossen

Der Factor steht bequem zur Verfügung.

Malware mit den entsprechenden Benutzerrechten kann jedoch möglicherweise auf das angeschlossene Medium zugreifen.

Factor verloren

Existiert weder eine gültige Sicherung noch ein zuvor eingerichteter alternativer Entsperrweg, kann der Tresor trotz bekanntem Masterpasswort unzugänglich werden.

Vertraulichkeit und Wiederherstellbarkeit sind zwei eigenständige Sicherheitsanforderungen.

5.6 Die Grenze der Dateitrennung

Zwei getrennte Dateien stellen nicht automatisch zwei unabhängig geschützte Geheimnisse dar.

Beispielsweise können ein Tresorordner und die separat gespeicherte Factor-Datei beide innerhalb desselben synchronisierten Benutzerverzeichnisses liegen.

Ein Angreifer mit Zugriff auf dessen vollständigen Inhalt könnte dadurch beide Bestandteile erhalten.

VORQYN berücksichtigt deshalb nicht nur die logische Trennung, sondern auch die tatsächliche Verwahrung.

5.7 Keine Hersteller-Hintertür

Der Hersteller besitzt keinen universellen Schlüssel, mit dem verlorene Masterpasswörter oder Secret Factors einfach umgangen werden können.

Die Wiederherstellung benötigt vorhandenes gültiges Schlüsselmaterial oder einen zuvor eingerichteten autorisierten Recovery-Weg.

Kein universeller Schlüssel für sämtliche Daten

VORQYN trennt die Entsperrung eines Tresors von der Verschlüsselung seiner Inhalte.

Die Schlüsselhierarchie besitzt mehrere Ebenen.

6.1 Unlock Key

Der Unlock Key entsteht aus dem Masterpasswort und dem unabhängigen Secret Factor.

Er dient zum Öffnen des vorgesehenen lokalen Schlüsselumschlags.

Er ist kein universeller direkter Verschlüsselungsschlüssel für alle Passwörter und Anhänge.

6.2 Local Profile Root Key – LPRK

Der Local Profile Root Key wird unabhängig mit einer kryptografisch sicheren Zufallsquelle erzeugt.

Er ist nicht lediglich eine deterministische Ableitung des Masterpassworts.

Der LPRK wird in einem authentifizierten Key-Envelope geschützt.

Dadurch sind der Entsperrvorgang und die langfristige Tresordatenverschlüsselung voneinander getrennt.

Vorteil bei einer Masterpasswortänderung

Wird das Masterpasswort geändert, können die dafür erforderlichen Schlüsselumschläge neu erstellt werden.

Unveränderte Datensatzschlüssel müssen deshalb nicht zwangsläufig durch eine vollständige Neuverschlüsselung des gesamten Tresors ersetzt werden.

6.3 Vault Epoch Key – VEK

Jeder Tresor verwendet einen eigenen Vault-Schlüsselkontext.

Ein Vault Epoch Key gehört zu einer definierten kryptografischen Schlüsselgeneration.

Diese Epoch-Struktur unterstützt kontrollierte Schlüsselrotationen und trennt unterschiedliche Generationen von Schlüsselmaterial.

6.4 Data Encryption Keys – DEKs

Jede Recordrevision erhält einen eigenen zufällig erzeugten 256-Bit-DEK.

Der DEK schützt den verschlüsselten Inhalt dieser Revision.

Der Schlüssel wird innerhalb des vorgesehenen Vault-Kontexts kryptografisch verpackt.

Dadurch wird der DEK nicht als ungeschützter Dateibestandteil abgelegt.

6.5 Collection Keys

Gemeinsam genutzte Datenbereiche besitzen getrennte Schlüsselkontexte.

Berechtigte Benutzer oder Geräte erhalten die für ihre Collections erforderlichen Schlüsselumschläge.

Ein global an sämtliche Benutzer verteilter Entschlüsselungsschlüssel würde diese Trennung unterlaufen.

Deshalb basiert die Vertraulichkeit gemeinsamer Datenbereiche auf tatsächlicher Schlüsselisolation, nicht allein auf einer Rollenbezeichnung.

6.6 Gerätegebundene Schlüsselumschläge

Autorisierte Geräte erhalten eigene, authentifizierte Zugänge zu den für sie bestimmten Schlüsselmaterialien.

Dadurch bleibt die lokale Geräteentsperrung von der gemeinsam nutzbaren Datenverschlüsselung getrennt.

6.7 Die vollständige Hierarchie

MASTER PASSWORD + SECRET FACTOR
               |
               v
            ARGON2ID
               |
               v
           HKDF-SHA-256
               |
               v
            UNLOCK KEY
               |
               v
           KEY ENVELOPE
               |
               v
               LPRK
               |
               v
          VAULT EPOCH KEY
               |
         +-----+----------------+
         |                      |
         v                      v
   RECORD KEY DOMAIN      COLLECTION KEYS
         |                      |
         v                      v
   WRAPPED RECORD DEKs     SHARED RECORDS
         |
         v
   ENCRYPTED REVISIONS

Die Grafik zeigt die logische Beziehung. Die konkrete Ableitung und das kryptografische Wrapping jeder Schlüsselstufe richten sich nach dem jeweiligen versionierten Protokollvertrag.

Jeder verschlüsselte Datensatz besitzt eine eindeutige Identität.

Ein Ciphertext darf nicht beliebig zwischen Datensätzen, Revisionen oder Tresoren ausgetauscht werden können.

VORQYN verwendet deshalb Authenticated Associated Data, kurz AAD.

AAD bindet sicherheitsrelevante Kontextinformationen an die authentifizierte Verschlüsselung.

Dazu zählen:

7.1 Beispiel: Objektvertauschung

Ein Angreifer kopiert eine gültige verschlüsselte Revision aus Tresor A in einen anderen Tresor.

Der Ciphertext selbst wurde nicht verändert.

Trotzdem stimmen die erforderlichen Kontextinformationen nicht mit dem erwarteten Ziel überein.

Die Authentifizierungsprüfung schlägt fehl.

7.2 Warum die Kodierung entscheidend ist

AAD-Felder müssen eindeutig und reproduzierbar kodiert werden.

Eine unklare Verkettung verschiedener Werte kann zu Mehrdeutigkeiten führen.

Die VORQYN-Formatverträge definieren deshalb die konkrete Feldkodierung, Versionierung und Reihenfolge.

7.3 AAD ist nicht automatisch geheim

AAD dient der Authentifizierung.

Es verschlüsselt seine eigenen Inhalte nicht automatisch.

Sensible Kontextinformationen werden deshalb zusätzlich in entsprechend geschützten Datenstrukturen abgelegt.

Für den Benutzer gibt es einen klaren Tresor.

Intern verwendet VORQYN eine objektbasierte Speicherstruktur.

Ein Tresor kann unterschiedliche Datentypen enthalten:

• Logins und Passwörter.
• Sichere Notizen.
• Identitäten.
• Brieftaschen und Zahlungsdaten.
• Softwarelizenzen.
• Abonnements und Verträge.
• SSH-Schlüssel.
• Zertifikate.
• Verschlüsselte Anhänge und Dokumente.

Diese unterschiedlichen Eintragstypen werden in einem gemeinsamen logischen Tresormodell verwaltet.

8.1 Das Datenlayout

vault/
|
+-- meta/
|     vault.meta
|
+-- commits/
|     <commit-id>.cmt
|
+-- records/
|     <object-id>/
|         <revision-id>.rec
|
+-- blobs/
|     <ciphertext-hash>.chunk
|
+-- heads/
      local.head

Die Speicherstruktur dient der internen Verwaltung.

Der Benutzer muss einzelne Dateien, Commitobjekte und Chunks nicht manuell verwalten.

8.2 Vault-Metadaten

Der Metadatenbereich enthält die erforderlichen versionierten Tresorinformationen und Schlüsselumschläge.

Sensible Inhalte wie Tresornamen und entsprechende Rootinformationen sind authentifiziert verschlüsselt.

8.3 Records

Ein Record enthält eine unabhängig verschlüsselte Datensatzrevision.

Er besitzt eine eindeutige Objekt- und Revisionsidentität.

8.4 Commits

Ein Commit beschreibt einen authentifizierten Tresorzustand.

Er referenziert die gültigen Datensatzrevisionen und erforderlichen Blobobjekte.

8.5 Blobs

Große Dateien werden als unabhängig verschlüsselte Chunks gespeichert.

Diese sind getrennt von kleinen Login- und Metadatenänderungen verwaltbar.

8.6 Heads

Head-Pointer beschleunigen den Zugriff auf bekannte Commitzustände.

Sie sind jedoch nicht die alleinige Quelle der kryptografischen Wahrheit.

Eine Änderung erzeugt eine neue Version. Sie überschreibt nicht den bisherigen verschlüsselten Record.

Jede Recordrevision ist nach ihrer Veröffentlichung unveränderlich.

Ein Passwortwechsel erzeugt daher eine neue verschlüsselte Revision.

Beispiel

Revision 1: Passwort A
Revision 2: Passwort B
Revision 3: Passwort C

Jede Revision besitzt:

• Eine eigene Revision-ID.
• Einen frischen zufälligen DEK.
• Einen eigenen authentifizierten Ciphertext.
• Einen eindeutig gebundenen Vault- und Objektkontext.

Der aktuelle Commit referenziert die jeweils gültige Revision.

Ältere Revisionen bleiben entsprechend den Aufbewahrungs- und Recoveryregeln verfügbar.

9.1 Warum nicht einfach dieselbe Datei überschreiben?

Bei einem In-place-Update kann ein Absturz genau während der Ersetzung kritische Daten beschädigen.

Immutable Records reduzieren dieses Risiko, indem ein neuer Datenstand separat erzeugt wird.

Der bisherige veröffentlichte Record bleibt dabei unverändert.

9.2 Warum ist das auch für die Synchronisation wichtig?

Nur die neue Revision muss als neues Datenobjekt übertragen werden.

Unveränderte Records müssen nicht erneut verschlüsselt oder hochgeladen werden.

Jede Änderung besitzt einen nachvollziehbaren Zustand.

VORQYN verwaltet seine Tresorhistorie über eigenständige Commitobjekte.

Ein Commit enthält unter anderem:

• Eine eindeutige Commit-ID.
• Die Vault-ID.
• Die Schlüsselgeneration.
• Eine Generation beziehungsweise Versionsinformation.
• Parent-Commit-Referenzen.
• Authentifizierte Recordreferenzen.
• Notwendige Blob- und Indexinformationen.

10.1 Commit-IDs

Jeder Commit besitzt eine eindeutige Identität.

Die authentifizierte Commit-ID wird mit dem Dateinamen und dem erwarteten Kontext abgeglichen.

Dadurch wird verhindert, dass Commitobjekte unbemerkt unter einer falschen Identität interpretiert werden.

10.2 Parent-Beziehungen

Ein Commit referenziert seinen Vorgänger.

Ein lokaler Einzel-Writer erzeugt typischerweise eine lineare Historie.

Bei mehreren schreibenden Geräten können parallele Commitzweige entstehen.

10.3 Unveränderliche Commits

Veröffentlichte Commits werden nicht in-place verändert.

Eine neue Änderung erzeugt ein neues Commitobjekt.

10.4 Mehrere gültige Spitzen

Wenn zwei authentische Commitzweige existieren, darf die Anwendung nicht willkürlich einen davon verwerfen.

VORQYN erhält die relevanten Zweige für die Konfliktbehandlung.

10.5 Keine Sicherheitsentscheidung allein anhand der Uhrzeit

Zeitstempel können manipuliert oder durch falsch eingestellte Systemuhren beeinflusst werden.

Deshalb wird ein Commit nicht allein deshalb als gültiger aktueller Zustand betrachtet, weil er das neueste Datum trägt.

Was passiert, wenn ein Benutzer ein Passwort speichert?

Ein Speichervorgang besteht aus mehreren definierten Phasen.

Phase 1 – Eingabevalidierung

Der Rust-Core prüft:

• Aktive Tresorsitzung.
• Berechtigung für die Operation.
• Gültiges Datenschema.
• Zulässige Datenlängen.
• Korrekte Objektidentität.
• Erwartete Vorgängerrevision.

Phase 2 – Neue Revision

Der Core erzeugt einen neuen zufälligen DEK und eine neue Revision-ID.

Phase 3 – Verschlüsselung

Die neue Recordrevision wird mit XChaCha20-Poly1305 verschlüsselt.

AAD bindet die verschlüsselten Inhalte an den vorgesehenen Kontext.

Phase 4 – Temporäres Schreiben

Der verschlüsselte Record wird als neues temporäres Objekt geschrieben.

Der bisherige veröffentlichte Record bleibt unverändert.

Phase 5 – Synchronisation der Dateidaten

Die notwendigen Schreib- und Flush-Operationen werden ausgeführt und überprüft.

Phase 6 – Veröffentlichung des Records

Das vollständige neue Objekt wird über eine geeignete No-Replace-Operation veröffentlicht.

Ein vorhandenes immutable Objekt wird nicht stillschweigend überschrieben.

Phase 7 – Commit-Erzeugung

Ein neuer Commit referenziert die neue Recordrevision und den bisherigen Commitzustand.

Phase 8 – Commit-Veröffentlichung

Der Commit wird als neues immutable Objekt veröffentlicht.

Phase 9 – Head-Aktualisierung

Der lokale Head-Pointer wird aktualisiert.

Der Head ist ein rekonstruierbarer Beschleuniger.

Der veröffentlichte authentische Commit bildet die wesentliche Grundlage für den neuen Datenstand.

11.1 Warum diese Reihenfolge?

Ein neuer Commit wird erst veröffentlicht, nachdem die benötigten Datenobjekte bereitstehen.

Dadurch reduziert VORQYN das Risiko, dass eine reguläre Änderung einen Zustand referenziert, dessen erforderliche Nutzdaten noch nicht vollständig erzeugt wurden.

Was passiert, wenn der Computer während des Speicherns ausgeschaltet wird?

Ein Stromausfall kann jederzeit auftreten.

VORQYN unterscheidet deshalb konkrete Fehlerzeitpunkte.

12.1 Commitgraph-Recovery

Beim Öffnen überprüft VORQYN die relevanten Commitobjekte.

Die Prüfungen umfassen:

• Authentifizierung.
• Erwartete Vault-ID.
• Commit-Identität.
• Parent-Referenzen.
• Generationen.
• Record- und Blobverfügbarkeit.
• Revisionskonsistenz.
• Format- und Ressourcengrenzen.

12.2 Eindeutiger gültiger Zustand

Existiert genau ein eindeutig gültiger und vollständig verfügbarer Commit-Tip, kann der lokale Head daraus rekonstruiert werden.

12.3 Mehrdeutiger Zustand

Bei mehreren widersprüchlichen authentischen Zweigen wählt VORQYN keinen willkürlichen Gewinner.

Insbesondere entscheidet nicht allein die höchste Generation oder der neueste Zeitstempel.

12.4 Kein stiller Rückfall auf ältere Daten

Ein beschädigter aktueller Datensatz führt nicht automatisch dazu, dass die Anwendung kommentarlos irgendeine ältere Revision lädt.

Ein solcher Fallback könnte Datenverlust oder Manipulation verdecken.

VORQYN bevorzugt einen nachvollziehbaren Fehlerzustand gegenüber einer unbemerkten inkonsistenten Wiederherstellung.

Ein Schreibvorgang darf nicht von der Hoffnung auf genügend freien Speicher abhängen.

Freier Speicherplatz kann zwischen einer Vorprüfung und dem tatsächlichen Schreiben verschwinden.

Deshalb überprüft VORQYN die Ergebnisse der Dateioperationen selbst.

13.1 Fehler beim Record-Schreiben

Kann eine neue Recorddatei nicht vollständig geschrieben werden, wird kein regulärer Commit veröffentlicht, der diese unvollständigen Daten benötigt.

13.2 Fehler beim Blob-Schreiben

Große Anhänge bestehen aus Chunks.

Schlägt ein Chunk-Schreibvorgang fehl, wird der Anhang nicht als vollständig gespeichert bestätigt.

Bereits erzeugte, aber nicht referenzierte verschlüsselte Objekte werden gesondert behandelt.

13.3 Fehler während eines Flush

Ein fehlgeschlagener Flush ist ein Persistenzfehler.

VORQYN behauptet dann nicht, die betreffende Operation sei zuverlässig dauerhaft gespeichert.

13.4 Unklarer Commit-Veröffentlichungsstatus

Manchmal lässt sich nach einem Dateisystemfehler nicht eindeutig sagen, ob die Veröffentlichung bereits erfolgt ist.

In diesem Fall verhindert der Core weitere Änderungen aus der möglicherweise veralteten Sitzung.

Der tatsächliche Commitzustand wird erneut authentifiziert geprüft.

13.5 Fehler beim Head-Update

Ein Head-Updatefehler macht einen bereits gültig veröffentlichten Commit nicht rückwirkend ungültig.

13.6 Fehler während der Tresorerstellung

Das Anlegen eines Tresorverzeichnisses, einer separaten Factor-Datei und verschlüsselter Initialisierungsdaten ist nicht automatisch eine einzige atomare Dateisystemtransaktion.

Ein Abbruch kann teilweise erzeugte Artefakte hinterlassen.

VORQYN behandelt diese nicht als vollständig angelegten Tresor und löscht sicherheitsrelevante Dateien nicht blind.

Crash-Konsistenz ist nicht gleichbedeutend mit absoluter Datendauerhaftigkeit.

VORQYN verwendet definierte Betriebssystemmechanismen für nicht überschreibende Dateioperationen und erforderliche Persistenzsynchronisation.

Die tatsächlichen Garantien unterscheiden sich jedoch je nach Plattform, Dateisystem und Hardware.

14.1 Windows

Die Windows-Speicherschicht berücksichtigt:

• NTFS-Eigenschaften.
• Zugriffsrechte und ACLs.
• Reparse Points und Junctions.
• Symbolische Links.
• Atomare beziehungsweise nicht überschreibende Veröffentlichungen.
• Dateihandles und Pfadauflösung.
• Veränderungen zwischen Prüfung und tatsächlichem Zugriff.

Ein Pfadstring allein stellt nicht automatisch eine zuverlässige Sicherheitsgrenze dar.

Besonders gegenüber einem Angreifer mit denselben Benutzerrechten sind mögliche Rename- und Time-of-check-to-time-of-use-Rennen relevant.

Deshalb gehören handlebasierte Validierung und die Bindung sicherheitskritischer Operationen an geprüfte Dateisystemobjekte zur Plattformhärtung.

14.2 Linux und macOS

Die Plattformadapter verwenden entsprechende Datei-, Rechte- und Synchronisationsmechanismen.

Dabei werden die tatsächlichen Eigenschaften des jeweiligen Dateisystems berücksichtigt.

Windows-Tests gelten nicht automatisch als Nachweis für Linux oder macOS.

14.3 Mobile Plattformen

Android und iOS verwenden ihre jeweiligen geschützten App-Speicherbereiche und Plattformmechanismen.

Die gemeinsamen kryptografischen Regeln verbleiben im Rust-Core.

14.4 Grenzen von Flush und Hardware

Auch ein erfolgreich gemeldeter Flush kann nicht garantieren, dass jede defekte Hardware ihre Zusagen tatsächlich einhält.

Relevante Risiken sind:

• Defekte SSD-Controller.
• Fehlerhafte Firmware.
• Problematische Schreibcaches.
• Dateisystemkorruption.
• Hardwaredefekte.
• Unzuverlässige Remote-Dateisysteme.

Backups bleiben deshalb erforderlich.

Große Dateien werden unabhängig und speicherbegrenzt verarbeitet.

VORQYN zerlegt große Anhänge in verschlüsselte Chunks.

Ein definiertes Chunk-Profil verwendet beispielsweise eine Nutzgröße von bis zu 4 MiB pro Chunk.

15.1 Eigener Schlüssel pro Chunk

Jeder Chunk verwendet einen eigenen kryptografischen Kontext und entsprechendes unabhängiges Schlüsselmaterial.

Die Authentifizierung bindet ihn unter anderem an:

• Vault.
• Blob-ID.
• Revision.
• Sequenznummer.
• Erwartete Länge.

15.2 SHA-256 über verschlüsselte Daten

VORQYN adressiert Chunks anhand eines Hashes ihres Ciphertexts.

Der Hash dient zur Identifikation und Prüfung des verschlüsselten Objekts.

Er ist kein offen gespeicherter Klartext-Hash des ursprünglichen Dokuments.

15.3 Keine konvergente Verschlüsselung

VORQYN leitet die Chunkschlüssel nicht aus dem Klartextinhalt ab.

Identische Dateien führen dadurch nicht automatisch zu identischen verschlüsselten Chunks.

Dies vermeidet bestimmte Gleichheits- und Inhaltsvermutungslecks, die bei globaler Klartext-Deduplizierung auftreten können.

15.4 Integrität einer vollständigen Datei

Die authentifizierten Referenzen definieren Reihenfolge, Zuordnung und erwartete Länge der Chunks.

Fehlende, manipulierte oder vertauschte Chunks werden erkannt.

15.5 Effiziente Änderungen

Unveränderte Chunks bleiben unverändert.

Bei einer Änderung werden nur die tatsächlich betroffenen Chunks und die notwendigen Referenzen erneuert.

Das konkrete Ausmaß hängt vom verwendeten Chunking-Verfahren ab.

Eine Byte-Einfügung am Anfang einer Datei kann bei festen Chunkgrenzen mehrere nachfolgende Chunks betreffen.

VORQYN verspricht deshalb nicht, dass jede beliebige Änderung automatisch exakt einen Chunk betrifft.

Eine kleine Änderung ist keine 100-GB-Änderung.

Ein großer Tresor kann tausende Logins und umfangreiche verschlüsselte Anhänge enthalten.

Seine Gesamtgröße kann 100 GB oder mehr erreichen.

Ein Benutzer ändert das Passwort eines einzigen Logins.

VORQYN erzeugt dafür einen neuen verschlüsselten Record und die notwendigen Commit- und Indexinformationen.

Die übrigen unveränderten Records und Blob-Chunks müssen nicht neu verschlüsselt werden.

16.1 Warum das wichtig ist

Bei einer naiv implementierten monolithischen Tresorarchitektur kann eine kleine Änderung dazu führen, dass große Datenbereiche neu geschrieben oder übertragen werden müssen.

VORQYN verwendet unabhängig adressierbare Objekte, damit die Aktualisierungseinheit erheblich kleiner sein kann als der gesamte Tresor.

16.2 Technische Einordnung

Nicht jede monolithische Lösung benötigt bei jeder Änderung einen vollständigen Download.

Geeignete Delta- oder Block-Synchronisationsverfahren können ebenfalls effizient arbeiten.

Die VORQYN-Architektur verwendet einen objektbasierten Ansatz, weil Records, Commits, Indexobjekte und große Anhänge damit unabhängig verwaltet und kryptografisch geprüft werden können.

16.3 Tatsächliche Übertragungsmenge

Bei einer kleinen Recordänderung werden grundsätzlich benötigt:

• Die neue verschlüsselte Recordrevision.
• Ein neuer Commit.
• Geänderte notwendige Indexinformationen.

Die tatsächlich übertragenen Bytes hängen vom Datenformat, der Indexgröße und dem Transportverfahren ab.

Die Gesamtgröße des Tresors bestimmt nicht automatisch den Umfang einer einzelnen Synchronisation.

Auch die Verwaltungsdaten müssen skalieren.

Eine objektbasierte Speicherung allein garantiert noch keinen konstant kleinen Metadatenaufwand.

Ein vollständiges Commit-Manifest kann mit zunehmender Anzahl verwalteter Objekte wachsen.

VORQYN verwendet deshalb versionierte Indexformate.

17.1 Kompakte Indizes

Kleine und mittlere Tresore können ihre aktuellen Recordreferenzen in einer kompakten authentifizierten Referenzstruktur verwalten.

17.2 Hierarchische Indizes

Bei sehr großen Datenbeständen unterstützen versionierte hierarchische Indexstrukturen die Aufteilung in unabhängig aktualisierbare Bereiche.

Ein Root-Index verweist auf authentifizierte Teilindizes.

Diese referenzieren die jeweils zugehörigen Records und Blobs.

17.3 Kryptografische Integrität

Die Referenzkette vom Root bis zum einzelnen Objekt muss authentisch überprüfbar bleiben.

17.4 Vorteile

Eine kleine Änderung muss nicht zwangsläufig die gesamte Referenztabelle aller Einträge erneut übertragen.

17.5 Versionierung und Migration

Neue Indexversionen werden über definierte Format- und Migrationsverträge eingeführt.

Das Speicherformat ist für kontrollierte Weiterentwicklung ausgelegt.

Dies bedeutet nicht, dass jede beliebige zukünftige Erweiterung ohne Formatänderung möglich ist.

17.6 Messbare Skalierung

Die technische Leistungsprüfung berücksichtigt:

• Größe der Commit-Metadaten.
• Anzahl und Größe der Records.
• Anzahl der Chunks.
• Indexgrößen.
• Synchronisierte Bytes.
• Dauer der Commitprüfung.
• Recovery-Zeiten.
• Ressourcenbedarf bei langen Historien.
• Aufwand der Remote-Commit-Discovery.

Die Cloud transportiert Ciphertext. Die Schlüssel bleiben beim Benutzer.

VORQYN synchronisiert verschlüsselte Records, Blobs, Commits und Indexobjekte.

Der Storage-Provider benötigt dazu keine Entschlüsselungsschlüssel.

18.1 Lokale Änderung

Ein Client erstellt lokal eine neue authentifiziert verschlüsselte Revision.

18.2 Neue Objekte bestimmen

Die Synchronisationsschicht ermittelt, welche Objekte am Synchronisationsziel fehlen.

18.3 Upload

Neue Records und Chunks werden übertragen.

Unveränderte Objekte werden nicht unnötig erneut hochgeladen.

18.4 Commit-Veröffentlichung

Ein Commit wird am Ziel erst veröffentlicht, nachdem die von ihm benötigten neuen Datenobjekte bereitstehen.

18.5 Commit-Discovery

Andere Geräte entdecken unbekannte Commits.

18.6 Download

Sie laden die notwendigen fehlenden verschlüsselten Objekte.

18.7 Lokale Prüfung

Der Client überprüft Ciphertext-Hashes, AEAD-Authentifizierung, Identitäten und Commitreferenzen.

18.8 Historienabgleich

Gemeinsame Vorfahren und divergierende Commits werden ermittelt.

18.9 Konfliktbehandlung

Eindeutige Änderungen können übernommen werden.

Widersprüchliche Revisionen bleiben erhalten, bis sie kontrolliert zusammengeführt werden.

18.10 Offlinebetrieb

Lokale Änderungen benötigen keine sofortige Netzwerkverbindung.

Sie werden später synchronisiert.

Eine fehlgeschlagene Netzwerkoperation nimmt einen bereits lokal erfolgreich veröffentlichten Commit nicht automatisch zurück.

Der Transport ist austauschbar. Die Kryptografie bleibt unabhängig.

VORQYN verwendet getrennte Transportadapter.

19.1 SFTP

SFTP verwendet eine SSH-gesicherte Verbindung.

Die Serveridentität wird über den vorgesehenen Host-Key-Vertrag geprüft.

19.2 WebDAV

WebDAV verwendet HTTPS und eine korrekte TLS-Zertifikatsprüfung.

19.3 S3-kompatible Speicher

Objektspeicher werden anhand ihrer tatsächlichen Objekt- und Conditional-Write-Eigenschaften angebunden.

19.4 Unterschiedliche Garantien

Nicht jeder Anbieter unterstützt identische Operationen.

Relevant sind insbesondere:

• Atomare Veröffentlichung.
• Nicht überschreibende Objektanlage.
• Conditional Writes.
• Rename-Verhalten.
• Vollständige Verzeichnisauflistungen.
• Pagination.
• Sichtbarkeit neuer Objekte.
• Idempotente Wiederholungen.

VORQYN behauptet keine serverseitigen Garantien, die ein konkretes Backend nicht bereitstellt.

19.5 Unvollständige Uploads

Ein unvollständiger Upload darf nicht als gültiges vollständig veröffentlichtes Objekt interpretiert werden.

Die Veröffentlichung und Prüfung erfolgen entsprechend dem Transportvertrag.

19.6 Unvollständige Listings

Ein fehlerhaftes oder unvollständiges Verzeichnislisting gilt nicht als Beweis, dass keine weiteren Commits existieren.

Vollständige Commit-Discovery ist eine eigenständige Synchronisationsanforderung.

Zwei Geräte. Zwei Änderungen. Kein stiller Datenverlust.

Zwei Geräte können denselben Eintrag unabhängig bearbeiten.

Beispielsweise wird ein Passwort auf einem Notebook geändert, während das Smartphone offline ist.

Später erzeugt das Smartphone eine andere Änderung auf Grundlage derselben älteren Revision.

20.1 Parallele Commits

Die Änderungen besitzen unterschiedliche authentische Commitzweige.

20.2 Kein blindes Last-Writer-Wins

VORQYN wählt nicht automatisch die Revision mit dem neuesten Zeitstempel.

Ein späterer Zeitstempel beweist nicht, dass der betreffende Datensatz fachlich korrekt ist.

20.3 Konfliktansicht

Die relevanten Revisionen bleiben erhalten.

Bei einem Widerspruch erhält der Benutzer eine nachvollziehbare Konfliktentscheidung.

20.4 Merge-Commit

Eine Zusammenführung kann über einen Commit mit mehreren Parent-Referenzen dokumentiert werden.

20.5 Grenzen der Konflikterkennung

Konflikte lassen sich nur dann vollständig erkennen, wenn die relevanten Commitzweige tatsächlich bekannt werden.

Ein bösartiger Server kann versuchen, authentische Commits zurückzuhalten.

Kryptografische Integrität allein erzwingt keine vollständige Offenlegung sämtlicher Remoteänderungen.

Authentisch bedeutet nicht automatisch aktuell.

Eine vollständig gültige verschlüsselte Tresorkopie kann veraltet sein.

21.1 Der Angriff

Ein Benutzer ändert sein Passwort.

Die Änderung wird korrekt verschlüsselt und authentifiziert gespeichert.

Ein Angreifer ersetzt anschließend den gesamten Tresor durch eine ältere, zuvor kopierte Version.

Diese ältere Version besitzt weiterhin gültige Authentifizierungstags.

21.2 Warum AEAD nicht genügt

Die AEAD-Prüfung bestätigt die Authentizität eines Datenobjekts innerhalb seines kryptografischen Kontextes.

Sie bestätigt nicht automatisch, dass es sich um den zuletzt akzeptierten Zustand handelt.

21.3 Unabhängige Aktualitätsanker

VORQYN verwendet für weitergehende Rollback-Prüfungen unabhängig geschützte Referenzen auf zuvor vertrauenswürdig bestätigte Commitzustände.

Ein älterer Datenstand kann mit einem solchen Anker verglichen werden.

21.4 Fundamentale Grenze

Wird der Aktualitätsanker gemeinsam mit allen Tresorkopien kompromittiert oder zurückgesetzt, kann auch ein älterer vollständig authentischer Zustand unter Umständen nicht als veraltet erkannt werden.

Ein vollständiger Rollback ist ohne unabhängigen vertrauenswürdigen Aktualitätsanker grundsätzlich nicht zuverlässig erkennbar.

Zugriff wird nicht nur durch Rollen, sondern durch Schlüssel kontrolliert.

VORQYN trennt Verwaltungsrechte, Leserechte und kryptografische Schlüsselberechtigungen.

22.1 Rollenmodell

Das Berechtigungsmodell unterscheidet unter anderem:

• Owner.
• Vault Admin.
• Editor.
• Viewer.

Diese Rollen definieren die erlaubten Aktionen.

22.2 Kryptografische Collection-Isolation

Unterschiedliche Collections verwenden eigene Schlüsselkontexte.

Ein Benutzer erhält nur die zur Entschlüsselung seiner berechtigten Datenbereiche notwendigen Schlüsselumschläge.

22.3 Geräteidentitäten

Autorisierte Geräte besitzen eigene kryptografische Identitäten.

22.4 Commit-Signaturen

Bei mehreren autorisierten Schreibern werden Commitveröffentlichungen zusätzlich gerätebezogen digital signiert.

Die Prüfung umfasst sowohl die Signaturgültigkeit als auch die Berechtigung des Writers.

Eine mathematisch gültige Signatur allein beweist keine ausreichende Schreibberechtigung.

22.5 Berechtigungsepochen

Autorisierungen sind an definierte Berechtigungs- und Schlüsselzustände gebunden.

22.6 Benutzerwiderruf

Beim Entfernen eines Benutzers werden die erforderlichen Berechtigungen und Schlüsselgenerationen aktualisiert.

Neue Daten können unter entsprechend erneuerten Schlüsseln geschützt werden.

Bereits bekannte Klartexte oder zuvor kopierte Schlüssel lassen sich nicht rückwirkend ungeschehen machen.

VORQYN unterscheidet verschiedene Arten kryptografischer Änderungen.

23.1 Masterpasswortwechsel

Das lokale Entsperrmaterial und die benötigten Schlüsselumschläge werden aktualisiert.

Nicht jeder Nutzdatenrecord muss deshalb neu verschlüsselt werden.

23.2 Secret-Factor-Rotation

Ein neuer unabhängiger Faktor wird erzeugt und über einen kontrollierten Schlüsselumschlagwechsel eingebunden.

Die erforderliche Wiederherstellbarkeit wird berücksichtigt.

23.3 Vault-Epoch-Rotation

Der Tresor verwendet neues Epoch-Schlüsselmaterial.

23.4 Rotation nach Kompromittierung

Wurde ein eigentlicher Datenschlüssel kompromittiert, genügt bloßes Re-Wrapping unter Umständen nicht.

Die betroffenen Inhalte benötigen je nach Vorfall neue unabhängige Datenschlüssel und eine entsprechende Neuverschlüsselung.

Bereits offengelegte Klartexte bleiben bekannt.

Eine Sicherung ist nur dann vollständig, wenn sie wiederherstellbar ist.

Ein Backup bezieht sich auf einen definierten authentischen Commitzustand.

24.1 Erforderliche Bestandteile

Ein vollständiges Backup berücksichtigt:

• Tresormetadaten.
• Schlüsselumschläge.
• Benötigte Commitobjekte.
• Referenzierte Records.
• Referenzierte Blob-Chunks.
• Die erforderlichen Wiederherstellungsinformationen.

Der Secret Factor besitzt einen eigenen Schutz- und Sicherungsvertrag.

24.2 Backupkonsistenz

Ein Backup gilt nicht als vollständig, wenn ein referenzierter Record oder Chunk fehlt.

24.3 Wiederherstellungsprüfung

Beim Restore prüft der Core Formatversionen, Entsperrberechtigung, Commitbeziehungen, Objektintegrität und Vollständigkeit.

24.4 Geräteverlust

Der Verlust eines Geräts führt nicht zwangsläufig zum Verlust des Tresors, sofern alle erforderlichen Daten und Wiederherstellungsschlüssel noch vorhanden sind.

24.5 Grenzen

Ohne notwendiges Schlüsselmaterial oder gültige Datenkopien kann eine Wiederherstellung unmöglich sein.

Der Hersteller besitzt keinen universellen Entschlüsselungsschlüssel.

Sichtbar gelöscht bedeutet nicht automatisch physisch vernichtet.

VORQYN verwendet versionierte Datensätze.

Ältere verschlüsselte Revisionen können weiterhin für Recovery und Synchronisation benötigt werden.

25.1 Tombstones

Löschungen werden über authentifizierte verschlüsselte Löschmarker abgebildet.

Dadurch erkennen andere Geräte, dass ein Record gelöscht wurde.

25.2 Offlinegeräte

Ein lange offline betriebenes Gerät darf einen bereits gelöschten Datensatz nicht unbemerkt wieder einführen.

25.3 Garbage Collection

Die Bereinigung berücksichtigt:

• Commitbeziehungen.
• Bekannte Gerätestände.
• Aufbewahrungsregeln.
• Backups.
• Konflikte.
• Wiederherstellungsanforderungen.

25.4 Physische Löschung

VORQYN verspricht keine universell garantierte physische Entfernung früherer Daten aus SSD-Blöcken, Snapshots, Cloudkopien oder externen Backups.

Private kryptografische Schlüssel benötigen besondere Sicherheitsregeln.

26.1 Öffentliche Informationen

Öffentliche Schlüssel und nicht geheime Metadaten besitzen andere Schutzanforderungen als private Schlüsselmaterialien.

26.2 Privater Export

Der Export privaten SSH- oder vergleichbaren Schlüsselmaterials ist eine besonders sensible Operation.

26.3 Rust-seitige Reauthentifizierung

Ein einfacher Bestätigungsdialog ersetzt keine erneute kryptografische Autorisierung.

VORQYN prüft die notwendige Berechtigung innerhalb des Sicherheitskerns.

26.4 Fail-Closed

Kann die erforderliche Reauthentifizierung nicht erfolgreich erfolgen, bleibt der private Export gesperrt.

26.5 Kontrollierte Übergabe

Autorisierte Exportoperationen werden an das konkret angeforderte Schlüsselmaterial und die freigegebene Aktion gebunden.

Auch im Arbeitsspeicher gelten Sicherheitsgrenzen.

VORQYN verarbeitet entschlüsselte Daten nur für die jeweilige autorisierte Funktion.

27.1 Sitzungsverwaltung

Der Core verwaltet den aktuellen Tresorzustand und die erforderlichen Sitzungsschlüssel.

27.2 Tresorsperre

Beim Sperren werden die kontrollierten geheimen Sitzungszustände verworfen.

Weitere geschützte Operationen benötigen eine neue gültige Autorisierung.

27.3 Zeroization

Rust verwendet geeignete Verfahren zur bestmöglichen Bereinigung temporärer Geheimnispuffer.

27.4 Technische Grenzen

Klartextkopien können außerhalb kontrollierter Rust-Puffer entstehen.

Beispiele:

• Flutter- und Dart-Speicher.
• Betriebssystempuffer.
• Zwischenablage.
• Eingabemethoden.
• Pagefile oder Swap.
• Crashdumps.
• Andere beteiligte Anwendungen.

Eine vollständige physische Entfernung aller Kopien wird nicht garantiert.

27.5 Kompromittierte Endgeräte

Ein Angreifer mit Kontrolle über den laufenden Benutzerprozess kann möglicherweise Eingaben oder legitimerweise entschlüsselte Daten abgreifen.

VORQYN verspricht keinen absoluten Schutz gegen ein vollständig kompromittiertes Gerät.

Die Schlüssel gehören zum berechtigten Client, nicht zum Speicheranbieter.

Die Speicherung und Synchronisation verschlüsselter Daten benötigt keine Herausgabe der eigentlichen Tresor-Entschlüsselungsschlüssel an den Storage-Provider.

28.1 Geschützte Inhalte

Dazu gehören insbesondere:

• Passwörter.
• Benutzernamen.
• Sichere Notizen.
• Private Schlüssel.
• Identitätsdaten.
• Vertragsinformationen.
• Vertrauliche Dokumente.
• Sensible interne Referenzinformationen.

28.2 Sichtbare Metadaten

Nicht sämtliche technischen Metadaten sind automatisch verborgen.

Je nach Speicher- und Transportmodell bleiben beispielsweise beobachtbar:

• Anzahl und Größen verschlüsselter Objekte.
• Übertragungszeitpunkte.
• Übertragungsvolumen.
• Zufällige Objektkennungen.
• Ciphertext-Hashes.
• Bestimmte äußere Formatfelder.
• IP-Adressen und Netzwerkverbindungen.

28.3 Offline-First

Die lokale Tresornutzung benötigt kein verpflichtendes Cloudkonto.

28.4 Keine verpflichtende Nutzungsüberwachung

Die Architektur setzt keine verpflichtende Verhaltens- oder Nutzungstelemetrie voraus.

28.5 Website-Icons

Automatische Website-Icons sind eine optionale Komfortfunktion.

Externe Iconabrufe können Netzwerkmetadaten offenlegen, beispielsweise die IP-Adresse und die angefragte Domain gegenüber dem jeweiligen Zielserver.

Der Benutzer wird transparent über solche Abrufe informiert und kann sie deaktivieren.

Der Iconcache wird im vorgesehenen geschützten Tresorkontext verwaltet.

Auch die Abhängigkeiten gehören zur Sicherheitsprüfung.

Der Rust-Core verwendet etablierte Bibliotheken für die benötigten kryptografischen Operationen.

Die Sicherheitsbetrachtung umfasst:

• Direkt verwendete Bibliotheken.
• Transitive Abhängigkeiten.
• Optionale Crates.
• Aktivierte und deaktivierte Featurepfade.
• Buildkonfigurationen.
• Tatsächlich ausgelieferte Binärdateien.

29.1 Sicherheitsadvisories

Eine bekannte Advisory wird anhand des konkreten Abhängigkeits- und Featuregraphen bewertet.

Eine optionale, deaktivierte Bibliothek ist nicht automatisch über den ausgelieferten Programmcode ausnutzbar.

Ihre bekannte Sicherheitsmeldung bleibt dennoch dokumentations- und prüfrelevant.

29.2 Yanked Dependencies

Eine zurückgezogene Bibliotheksversion wird gesondert bewertet.

Eine Yanked-Warnung ist nicht automatisch gleichbedeutend mit einer bestätigten ausnutzbaren Sicherheitslücke.

29.3 Debug und Release

Experimentelle Debug-Schnittstellen werden von den ausgelieferten Release-Funktionen getrennt.

Die Prüfung erfolgt anhand des tatsächlichen Release-Artefakts und seiner exportierten Schnittstellen.

29.4 Nachvollziehbarkeit

Abhängigkeitsversionen, Buildparameter, Prüfsummen und Testergebnisse werden dem jeweiligen überprüften Softwarestand zugeordnet.

VORQYN betrachtet unterschiedliche Angreifer und Fehlerklassen.

Sicherheitsbehauptungen müssen überprüfbar sein.

VORQYN trennt Architekturentscheidungen von ihrem tatsächlichen Implementierungs- und Prüfnachweis.

Für professionelle Security-Audits werden die relevanten Verträge dokumentiert.

31.1 Kryptografie

• Algorithmen und Parameter.
• Schlüsselhierarchie.
• KDF-Profile.
• Salt- und Nonce-Behandlung.
• HKDF-Kontexte.
• DEK-Wrapping.
• AAD-Kodierung.
• Schlüsselrotation.
• Reauthentifizierung.

31.2 Speicherformat

• Recordformat.
• Commitformat.
• Meta- und Envelopeformat.
• Blob-Chunks.
• Versionskennungen.
• Größenlimits.
• Fehlermeldungen.
• Verhalten bei unbekannten Formaten.

31.3 Dateisystem und Recovery

• Atomare Veröffentlichungsoperationen.
• No-Replace-Garantien.
• Flush-Verhalten.
• Disk-Full-Fehler.
• Crash-Injection.
• Commitgraph-Recovery.
• Umgang mit mehrdeutigen Zuständen.

31.4 Synchronisation

• Remote-Commit-Discovery.
• Upload- und Downloadreihenfolge.
• Idempotenz.
• Konflikterkennung.
• Multi-Writer-Signaturen.
• Schlüsselberechtigungen.
• Rollback-Grenzen.

31.5 Laufzeitsicherheit

• Flutter-/Rust-FFI.
• Sitzungsverwaltung.
• Klartextlebensdauer.
• Speicherbereinigung.
• Exportberechtigungen.
• Plattformintegration.

31.6 Die fünf Nachweisstufen

Unit-Tests prüfen definierte Sicherheitsinvarianten; unabhängige Reviews betrachten zusätzlich Implementierung und Angriffsflächen.

Architekturdiagramme dokumentieren die Sicherheitsannahmen; Codeprüfungen verfolgen sie bis in die Implementierung.

Prüfungen beziehen sich auf definierte Softwarestände und die zugehörigen Buildparameter.

Seriöse Sicherheit kennt Grenzen.

Keine absolute Sicherheit bei kompromittierten Endgeräten

Wer einen laufenden berechtigten Prozess vollständig kontrolliert, kann unter Umständen dessen legitime Klartextverarbeitung ausnutzen.

Keine garantierte Rollback-Erkennung ohne unabhängigen Aktualitätsanker

Eine ältere authentische Tresorkopie kann ohne weitere vertrauenswürdige Referenz nicht in jedem Angriffsmodell als veraltet erkannt werden.

Keine garantierte Wiederherstellung ohne erforderliche Schlüssel

Der Verlust sämtlicher gültiger Schlüsselmaterialien kann den Zugriff unwiederbringlich verhindern.

Keine universelle physische Löschung

Ältere Ciphertexts können in SSD-Blöcken, Snapshots, Cloudkopien oder Backups verbleiben.

Keine absolute Hardware-Dauerhaftigkeit

Defekte Controller und Dateisysteme können auch sorgfältige Persistenzverfahren beeinträchtigen.

Keine vollständige Geheimhaltung technischer Metadaten

Ende-zu-Ende-Verschlüsselung verbirgt nicht jede Dateigröße, jeden Übertragungszeitpunkt oder sämtliche Netzwerkmetadaten.

Prüfnachweise und ihre Aussagekraft

Automatisierte Tests, Plattformvalidierung und unabhängige Reviews untersuchen unterschiedliche Sicherheitsaspekte.

Kann jemand meine Passwörter entschlüsseln, wenn er die Tresordateien stiehlt?

Nicht allein aufgrund des Besitzes verschlüsselter Dateien.

Die Entschlüsselung benötigt das passende Schlüsselmaterial.

Warum verwendet VORQYN einen Secret Factor?

Er stellt unabhängiges kryptografisches Schlüsselmaterial bereit und stärkt insbesondere den Schutz gegen isolierten Tresordiebstahl.

Ist das echte Zwei-Faktor-Authentifizierung?

Ein lokal gespeicherter Secret Factor ist nicht automatisch mit einer unabhängigen Multi-Faktor-Authentifizierung gegenüber sämtlichen lokalen Angriffen gleichzusetzen.

Kann ich VORQYN offline verwenden?

Ja. Die lokale Tresornutzung benötigt keine permanente Internetverbindung.

Muss ich einen VORQYN-Cloudserver verwenden?

Nein. Die Tresorverschlüsselung ist vom Speicheranbieter getrennt.

Wird bei jeder Passwortänderung mein gesamter Tresor synchronisiert?

Nein. Neue verschlüsselte Records und die benötigten Commit- und Indexobjekte werden unabhängig vom unveränderten Datenbestand übertragen.

Was passiert bei einem Stromausfall während des Speicherns?

VORQYN prüft beim Wiederöffnen die authentifizierten Commitbeziehungen und die Vollständigkeit der referenzierten Objekte.

Kann ein beschädigter Head-Pointer meinen Tresor zerstören?

Der Head-Pointer ist nicht die alleinige Autorität.

Ein eindeutiger gültiger Commitzustand kann aus der authentifizierten Historie rekonstruiert werden.

Was passiert bei gleichzeitigen Änderungen auf mehreren Geräten?

Konkurrierende Revisionen können als parallele Commitzweige erhalten bleiben und kontrolliert zusammengeführt werden.

Kann ein Cloudanbieter meine Inhalte entschlüsseln?

Der reine Storage-Provider erhält für die Speicherung und Synchronisation keine notwendigen Tresor-Entschlüsselungsschlüssel.

Was passiert, wenn ich meinen Secret Factor verliere?

Ohne gültige Sicherung oder alternativen zuvor eingerichteten Recovery-Weg kann der Tresor unzugänglich werden.

Sind gelöschte Daten sofort physisch verschwunden?

Nicht zwingend. Frühere verschlüsselte Revisionen und Backups können weiterhin existieren.

Ist VORQYN gegen jede Malware geschützt?

Nein. Ein vollständig kompromittiertes Endgerät liegt außerhalb der Garantien, die lokale Verschlüsselung allein leisten kann.

Ist ein kryptografisch gültiger Tresor automatisch aktuell?

Nein. Ein vollständiger Rollback auf einen älteren authentischen Zustand benötigt für seine zuverlässige Erkennung unabhängige Aktualitätsinformationen.

Security by Architecture. Not by Promise.

VORQYN schützt vertrauliche Daten nicht durch einen einzigen Mechanismus.

Die Sicherheitsarchitektur kombiniert unabhängige Schutzschichten.

Argon2id erschwert Passwortangriffe.

Der Secret Factor verstärkt die notwendige Schlüsselbasis.

HKDF-SHA-256 trennt kryptografische Zwecke.

XChaCha20-Poly1305 schützt vertrauliche Daten und erkennt Manipulationen.

Individuelle DEKs isolieren einzelne Datensatzrevisionen.

AAD bindet jeden Datensatz an den richtigen Kontext.

Immutable Records verhindern unnötige In-place-Überschreibungen.

Authentifizierte Commits machen Datenzustände nachvollziehbar.

Crash-Recovery behandelt unterbrochene Schreibvorgänge kontrolliert.

Objektbasierte Synchronisation überträgt die notwendigen Änderungen statt unnötig kompletter Datenbestände.

Getrennte Schlüsselbereiche ermöglichen kryptografisch begrenzte Freigaben.

Dokumentierte Sicherheitsgrenzen verhindern irreführende absolute Versprechen.

Die entscheidende Frage ist nicht nur, ob ein Passwort verschlüsselt gespeichert wird.

Sie lautet:

Ist sein vollständiger Lebenszyklus abgesichert – von der Eingabe über die Speicherung und Synchronisation bis zur Wiederherstellung und Löschung?

Genau diesen Lebenszyklus betrachtet VORQYN.

VORQYN

YOUR KEYS. YOUR RULES.

Deine Daten. Deine Schlüssel. Deine Entscheidung.