frogsnot/concryptorEine Gigabyte-pro-Sekunde, mehrthreadige Dateiverschlüsselungs-Engine. Erzielt extreme Durchsatzraten durch eine sperrfreie, dreifach gepufferte io_uring-Pipeline, paralleles Rayon-Chunking und hardwarebeschleunigte AEADs (AES-256-GCM / ChaCha20).
Eine multi-threaded AEAD-Verschlüsselungs-Engine, entwickelt in Rust. Verschlüsselt und entschlüsselt Dateien mit Gigabyte-pro-Sekunde-Durchsatz mittels einer dreifach gepufferten io_uring-Pipeline, paralleler Chunk-Verarbeitung über Rayon und assembleroptimierten Chiffren via ring.
⚠️ HINWEIS: EXPERIMENTELLE SOFTWARE ⚠️
Dieses Projekt ist extrem neu und wird derzeit NICHT für den produktiven oder sicherheitskritischen Einsatz empfohlen. Obwohl die kryptografischen Primitive (AES-256-GCM, ChaCha20-Poly1305 via ring) und das Formatdesign solide sind, wurde die Codebasis keinen formellen Sicherheitsaudits oder umfangreichen Tests unter realen Bedingungen unterzogen. Nutzung auf eigene Gefahr. Für den Schutz sensibler Daten sollten Sie auf bewährte Werkzeuge wie GnuPG, age oder OpenSSL zurückgreifen, bis dieses Projekt ausgereift ist.
ring (assembleroptimiert)--memory)seal_in_place_separate_tag / open_in_place via ring minimiert Allokationen in der heißen SchleifeO_DIRECT-I/O, das den Kernel-Page-Cache umgeht und DMA-schnelle Lese-/Schreibvorgänge auf NVMe ermöglicht. Pufferpools verwenden std::alloc mit 4096-Byte-AusrichtungGemessen mit cargo bench (Criterion, 10 Samples pro Messung). Schlüsselableitung ausgeschlossen – Zahlen beziehen sich nur auf reinen Krypto-Durchsatz.
Hardware:
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.
| Dateigröße | AES-256-GCM Verschl. | ChaCha20 Verschl. | AES-256-GCM Entschl. | ChaCha20 Entschl. |
|---|---|---|---|---|
| 64 KiB | 244 MiB/s | 233 MiB/s | 233 MiB/s | 234 MiB/s |
| 1 MiB | 1,08 GiB/s | 882 MiB/s | 1010 MiB/s | 876 MiB/s |
| 16 MiB | 1,10 GiB/s | 923 MiB/s | 1,06 GiB/s | 988 MiB/s |
| 64 MiB | 984 MiB/s | 935 MiB/s | 988 MiB/s | 973 MiB/s |
| 256 MiB | 1,00 GiB/s | 1015 MiB/s | 1,01 GiB/s | 1,02 GiB/s |
Chunk-Größen-Sweep (AES-256-GCM, 64 MiB Datei):
| Chunk-Größe | Durchsatz |
|---|---|
| 64 KiB | 1,01 GiB/s |
| 256 KiB | 1,05 GiB/s |
| 1 MiB | 1,07 GiB/s |
| 4 MiB | 988 MiB/s |
| 8 MiB | 988 MiB/s |
| 16 MiB | 1,00 GiB/s |
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: