Leistung

Gemessen mit cargo bench (Criterion, 10 Samples pro Messung). Schlüsselableitung ausgeschlossen – Zahlen beziehen sich nur auf reinen Krypto-Durchsatz.

Hardware:

• CPU: AMD Ryzen 5 5600X (6c/12t @ 3,7 GHz Basis)
• RAM: 2x 8 GiB DDR4-2666 (Dual-Channel, 16 GiB gesamt)
• OS: Linux

Hinweis zu I/O: Criterion schreibt temporäre Dateien nach /tmp, was auf diesem System tmpfs (RAM-gestützt) ist. Mit O_DIRECT kann der Kernel kein echtes asynchrones DMA auf tmpfs verwenden, daher spiegeln diese Zahlen den Chiffre-Durchsatz + io_uring-Overhead ohne den DMA-Umgehungsvorteil wider. Auf einem echten Gen4-NVMe-Laufwerk eliminiert O_DIRECT das Page-Cache-Doppelpuffern und ermöglicht DMA direkt in die ausgerichteten Pufferpools, was einen signifikant höheren Durchsatz ergeben sollte.

Chunk-Größen-Sweep (AES-256-GCM, 64 MiB Datei):

Leistungsmerkmale

Die Engine verwendet ring (assembleroptimiertes AES-NI / NEON / ARMv8-CE) für Chiffre-Operationen und eine dreifach gepufferte io_uring-Pipeline für I/O. Drei vorab allozierte Pufferpools rotieren durch die Pipeline: während die Schreibvorgänge von Pool A im Kernel abgeschlossen werden, wird Pool B von Rayon auf der CPU verschlüsselt, und die Lesevorgänge von Pool C werden an den Kernel übergeben. Dies überlappt die I/O-Latenz mit der Krypto-Berechnung.

Warum AES-256-GCM bei kleinen Dateien schneller ist als ChaCha20-Poly1305: Das AES-GCM-Backend von ring nutzt AES-NI + CLMUL-Hardwareanweisungen, die auf x86-64 verfügbar sind, was ihm einen Hardwarevorteil gegenüber ChaCha20 (einer Software-Chiffre) verschafft. Bei größeren Größen konvergieren beide Chiffren auf ~1,0 GiB/s, was darauf hindeutet, dass der Engpass vom Chiffre-Durchsatz zum I/O-Submission-Overhead wechselt.

Warum der Spitzendurchsatz bei 1-16 MiB liegt, nicht bei 256 MiB: Kleine Dateien (1-16 MiB) haben wenige Chunks, daher ist die Rayon-Parallelität effizient und der Working Set passt in den Cache. Bei 64-256 MiB ist die io_uring-Pipeline voll aktiv (drei Batches in der Luft), aber der Overhead pro SQE-Submission und CQE-Completion skaliert mit der Chunk-Anzahl. Das Dreifachpuffer-Design stellt sicher, dass sich I/O und Krypto überlappen und verdeckt diese Kosten teilweise.

Warum nur etwa 1,0 GiB/s und nicht 10+ GiB/s: Moderne AES-NI kann 2-4 GiB/s pro Kern erreichen. Mit 12 Threads könnte der reine Chiffre-Durchsatz 10 GiB/s überschreiten. Drei Faktoren erklären die Lücke:

1. io_uring pro-SQE-Overhead: Jeder Chunk erfordert ein Lese-SQE und ein Schreib-SQE. Bei 256 Chunks für eine 256-MiB-Datei sind das 512 SQEs, die übermittelt, und 512 CQEs, die abgeholt werden. Während io_uring die Kernel-Übergangskosten pro Systemaufruf von pread/pwrite vermeidet, hat es dennoch Ringpuffer- und Speicherbarriere-Overhead pro SQE.
2. Pipeline-Tiefe: Mit PIPELINE_DEPTH=3 rotieren nur drei Batches gleichzeitig durch die Pipeline. Ein echter Einschwing-Overlap erfordert mindestens drei Batches; Dateien, die in ein oder zwei Batches passen, profitieren nicht von der Pipeline.
3. Cache-Hierarchie-Effekte: Der 5600X hat 512 KiB L2 pro Kern und 32 MiB gemeinsamen L3. Der Standard-Chunk von 4 MiB überschreitet den L2, und ein Batch von ~21 Chunks (84 MiB aktiver Arbeitsbereich) übersteigt den L3 bei weitem. Kleinere Chunk-Größen (64-256 KiB) zeigen im Chunk-Sweep einen besseren Durchsatz, da mehr vom Working Set im Cache bleibt.

Puffer-Lebenszyklus und Sicherheit: Pufferpools werden einmalig via std::alloc::alloc_zeroed mit Layout::from_size_align(size, 4096) alloziert, bevor der io_uring-Ring erstellt wird, und werden über alle Pipeline-Iterationen hinweg ohne Neuzuweisung wiederverwendet. Jeder verschlüsselte Chunk wird vor dem O_DIRECT-Schreibvorgang mit Nullen auf Sektorgrenze aufgefüllt. Der Ring wird explizit vor den Pufferpools gelöscht, sodass der Kernel niemals auf den freigegebenen Speicher verweist (kein Use-After-Free).

Installation

Die Binärdatei befindet sich unter target/release/concryptor.

Verwendung

Verschlüsseln

Sicherheitshinweis: --password / -p übergibt das Passwort als CLI-Argument, das in der ps-Ausgabe und der Shell-Historie sichtbar ist. Für interaktive Nutzung weglassen, um die sichere versteckte Eingabeaufforderung zu erhalten. Für Skripte empfehlen wir, die Historie danach zu löschen oder einen Wrapper zu verwenden, der aus einem Dateideskriptor liest.

Verzeichnis verschlüsseln

Die Verzeichnisverschlüsselung erstellt ein temporäres Tar-Archiv (.concryptor-*.tar, Berechtigung 0600, CSPRNG-benannt), verschlüsselt es und löscht die temporäre Datei automatisch. Dateinamen, Verzeichnisstruktur, Berechtigungen und Zeitstempel sind alle im verschlüsselten Payload enthalten.

Entschlüsseln

Verzeichnis entschlüsseln und extrahieren

Ohne --extract erzeugt die Entschlüsselung eines Verzeichnisarchivs die Zwischendatei .tar, die Sie manuell inspizieren oder extrahieren können.

Hilfe

Dateiformat

Alle Werte sind Little-Endian. Der Header belegt einen vollständigen 4-KiB-Sektor; jeder verschlüsselte Chunk-Slot wird auf die nächste 4-KiB-Grenze aufgefüllt. Dadurch sind alle Offsets und I/O-Größen sektorausgerichtet für O_DIRECT.

Bei 4-MiB-Chunks: Jeder Datenträger-Slot ist ceil((4194304 + 16) / 4096) * 4096 = 4198400 Bytes (4080 Bytes Auffüllung pro Chunk). Die 4032 reservierten Bytes im Header stehen für zukünftige Funktionen zur Verfügung (asymmetrische Schlüsselslots, Metadaten usw.).

Der Salz und die Basis-Nonce werden bei jeder Verschlüsselung frisch aus rand::rng() (unterstützt durch den OS-CSPRNG) generiert. Die Wiederverwendung eines Passworts über mehrere Dateien hinweg ist sicher, da unterschiedliche Salze unterschiedliche Argon2id-Schlüssel und unterschiedliche Basis-Noncen unterschiedliche Pro-Chunk-Noncen erzeugen.

Sicherheitsdesign

• Nonce-Ableitung: chunk_nonce = base_nonce XOR chunk_index (TLS 1.3-Art). Das Vertauschen von Chunks führt zu einem Entschlüsselungsfehler, da die Nonce an Position N nicht mit der Nonce übereinstimmt, die zum Verschlüsseln des ursprünglichen Chunks an Position M verwendet wurde. Hinweis: Die XOR-basierte Nonce-Ableitung hat eine theoretische Schwachstelle, wenn der gleiche Schlüssel über mehrere Streams hinweg verwendet wird (unterschiedliche Basis-Noncen können sich überschneidende Nonce-Räume erzeugen). Dies trifft auf Concryptor nicht zu, da jede Verschlüsselung ein frisches 128-Bit-Zufallssalz erzeugt, das einen eindeutigen Argon2id-Schlüssel pro Datei liefert. Nonce-Eindeutigkeit ist nur unter demselben Schlüssel relevant, und die Wahrscheinlichkeit einer Schlüsselwiederverwendung beträgt ~2^-128 pro Dateipaar.
• Header-authentifizierte AAD: Jeder AEAD-Aufruf eines Chunks verwendet AAD = full_aligned_header (4096) || chunk_index (8 LE) || is_final (1) (insgesamt 4105 Bytes). Der gesamte 4-KiB-Header-Sektor (Kernfelder, KDF-Parameter und reservierte Auffüllung) wird in das Authentifizierungstag jedes Chunks eingebunden. Das Ändern irgendeines Header-Bytes (Chiffretyp, Chunk-Größe, Originalgröße, Salz, Nonce, KDF-Parameter oder reservierte Auffüllung) macht alle Chunks ungültig. Dies verhindert Trunkierungsangriffe, bei denen ein Angreifer original_size bearbeitet und nachfolgende Chunks entfernt, und verhindert auch das Schmuggeln von Daten in den reservierten Auffüllungsbereich. Legacy-v3-Dateien werden aus Gründen der Abwärtskompatibilität mit 52-Byte-AAD entschlüsselt; ein Downgrade von v4 auf v3 ist nicht möglich, da das Versionsbyte selbst in der authentifizierten AAD enthalten ist.
• STREAM-artiger letzter-Chunk-Indikator: Das letzte Byte der AAD ist 0x01 für den finalen Chunk und 0x00 für alle anderen. Dies verhindert zwei Angriffe:
  • Trunkierung: Das Entfernen des letzten Chunks und das Befördern eines nicht-finalen Chunks an das Ende schlägt fehl, da der nicht-finale Chunk mit is_final = 0x00 verschlüsselt wurde, die Entschlüsselung aber 0x01 erwartet.
  • Erweiterung: Das Anhängen gefälschter Chunks schlägt fehl, da ein Angreifer ohne den Schlüssel kein gültiges Tag für is_final = 0x01 erzeugen kann.
• Frische Zufälligkeit pro Datei: Ein 16-Byte-Salz und eine 12-Byte-Basis-Nonce werden bei jeder Verschlüsselung aus dem OS-CSPRNG (rand::rng()) bezogen. Zwei Verschlüsselungen derselben Datei mit demselben Passwort erzeugen völlig unterschiedliche Chiffrate. Nonce-Wiederverwendung (die für AES-GCM katastrophal ist) wird durch die Konstruktion vermieden.
• Schlüsselableitung: Argon2id mit konfigurierbaren Speicherkosten (Standard 256 MiB, einstellbar via --memory), 3 Zeititerationen, Parallelität 4. Der Standard 256 MiB ist das 4-fache des OWASP-Minimums und teuer für GPU/FPGA/ASIC-Angreifer. KDF-Parameter werden im Dateiheader (Bytes 52-63) gespeichert, sodass Dateien selbstbeschreibend sind – die Entschlüsselung verwendet immer die korrekten Parameter, unabhängig von den aktuellen Standardwerten. Wenn Bytes 52-63 alle Null sind (Legacy-Dateien vor KDF-Parametern), werden die alten 64 MiB / 3 / 4 Standardwerte angewendet.
• Nullstellung: Verschlüsselungsschlüssel werden unmittelbar nach der Chiffre-Konstruktion nullgestellt. Passwörter werden nach Gebrauch nullgestellt.

Testen

Die Testsuite deckt ab:

• Header-Serialisierungs-/Deserialisierungs-Roundtrips
• Schlüsselableitungs-Determinismus und -Sensitivität
• Nonce-Eindeutigkeit und Identitätseigenschaften
• Verschlüsselungs-/Entschlüsselungs-Roundtrips für beide Chiffren über Dateigrößen (leer, 1 Byte, Grenzfälle, mehrere Chunks)
• Zurückweisung falscher Passwörter
• Manipulationserkennung (umgedrehtes Chiffrat, korrupte Tags, korruptes Salz, abgeschnittene Dateien)
• Erkennung von Chunk-Neuordnungsangriffen
• Erkennung von Chiffretyp-Fehlanpassungen
• Erkennung von Trunkierungsangriffen (modifizierte original_size + entfernte Chunks)
• Erkennung von Headerfeld-Manipulation (modifizierte chunk_size)
• Erkennung von Manipulation reservierter Header-Bytes (modifizierter Auffüllungsbereich)
• Nicht-deterministische Verschlüsselungsüberprüfung
• Stresstest mit 256 kleinen Chunks
• Verzeichnisarchiv-Pack-/Unpack-Roundtrips (beide Chiffren)
• Leeres Verzeichnis, tief verschachteltes Verzeichnis, viele Dateien und binäre Inhalte Roundtrips
• Symlink-Erhaltung für gültige interne Links
• Zurückweisung von Symlinks, die aus dem Extraktionsstammverzeichnis entweichen (absolute und relative Traversal)
• Temporäre Datei-Autobereinigung bei Drop
• Zurückweisung falscher Passwörter für verschlüsselte Archive

Abhängigkeiten

Installieren

Lizenz

Dieses Projekt ist unter der GNU Affero General Public License v3.0 lizenziert.