Concryptor

Un motore di crittografia AEAD multi-thread costruito in Rust. Cripta e decripta file con una produttività di gigabyte al secondo utilizzando una pipeline io_uring a triplo buffer, l'elaborazione parallela dei chunk tramite Rayon e cifrari ottimizzati in assembly tramite ring.

⚠️ AVVISO: SOFTWARE SPERIMENTALE ⚠️

Questo progetto è estremamente recente e attualmente NON è raccomandato per uso in produzione o per dati critici. Sebbene i primitivi crittografici (AES-256-GCM, ChaCha20-Poly1305 tramite ring) e il formato siano solidi, il codice non è stato sottoposto a audit di sicurezza formali o a test estensivi nel mondo reale. Utilizzo a proprio rischio. Per proteggere dati sensibili, considera l'uso di strumenti collaudati come GnuPG, age o OpenSSL fino a quando questo progetto non maturerà.

Caratteristiche

• Supporto di due cifrari: AES-256-GCM (AES-NI hardware) e ChaCha20-Poly1305 tramite ring (ottimizzato in assembly)
• Crittografia parallela: elaborazione multi-thread dei chunk tramite Rayon su tutti i core della CPU
• Pipeline io_uring a triplo buffer: sovrappone l'I/O del kernel e la crittografia lato CPU utilizzando tre pool di buffer rotanti — mentre le scritture di un lotto sono in volo, il lotto successivo viene crittografato da Rayon e le letture del terzo lotto sono in volo. Nessun overhead syscall per chunk, nessuna limitazione di mmap (nessun SIGBUS, nessun esaurimento dello spazio di indirizzamento virtuale)
• Derivazione della chiave Argon2id: stiramento standard password-chiave (default 256 MiB di memoria, 3 iterazioni, configurabile con --memory)
• Parametri KDF auto-descrittivi: costo memoria, iterazioni e parallelismo sono memorizzati nell'intestazione del file crittografato, in modo che la decifratura utilizzi esattamente i parametri scelti al momento della crittografia. I file legacy (sentinel con tutti zeri) vengono gestiti in modo trasparente con i vecchi default di 64 MiB
• Nonce indicizzati per chunk: derivazione nonce XOR stile TLS 1.3 previene attacchi di riordinamento dei chunk
• AAD autenticato dall'intestazione: l'intera intestazione allineata a 4 KiB è inclusa nell'AAD di ogni chunk, autenticando tutti i campi dell'intestazione (core, parametri KDF e byte riservati) e prevenendo attacchi di troncamento, manipolazione dei campi dell'intestazione e smuggling nei byte riservati
• Chunk finale stile STREAM: un flag di chunk finale nell'AAD previene attacchi di troncamento e append (ispirato alla costruzione STREAM)
• Casualità fresca per file: salt crittografico di 16 byte e base nonce di 12 byte generati casualmente per ogni crittografia, memorizzati nell'intestazione
• Crittografia in-place: seal_in_place_separate_tag / open_in_place tramite ring minimizza l'allocazione nel ciclo caldo
• Zeroizzazione della password: chiavi e password vengono cancellate in modo sicuro dalla memoria dopo l'uso
• O_DIRECT + formato allineato ai settori: intestazione e slot dei chunk allineati a 4 KiB abilitano l'I/O O_DIRECT, bypassando la cache della pagina del kernel per letture/scritture a velocità DMA su NVMe. I pool di buffer utilizzano std::alloc con allineamento a 4096 byte
• Crittografia di directory: crittografa intere directory come un unico archivio crittografato. Il packing basato su tar preserva nomi file, permessi, timestamp e struttura delle directory all'interno del testo cifrato. L'estrazione valida contro attacchi di path traversal e symlink escape
• Formato file auto-descrittivo: l'intestazione memorizza cifrario, dimensione chunk, dimensione file originale, salt, base nonce e parametri KDF Argon2id

Prestazioni

Benchmark eseguiti con cargo bench (Criterion, 10 campioni per misurazione). La derivazione della chiave è esclusa: i numeri riflettono solo la produttività crittografica pura.

Hardware:

• CPU: AMD Ryzen 5 5600X (6c/12t a 3.7 GHz base)
• RAM: 2x 8 GiB DDR4-2666 (doppio canale, 16 GiB totali)
• OS: Linux

Nota sull'I/O: Criterion scrive file temporanei in /tmp, che su questo sistema è tmpfs (supportato da RAM). Con O_DIRECT, il kernel non può utilizzare DMA asincrono reale su tmpfs, quindi questi numeri riflettono la produttività del cifrario + overhead di io_uring senza il vantaggio del DMA bypass. Su un vero NVMe Gen4, O_DIRECT elimina il doppio buffering della cache di pagina e abilita DMA direttamente nei pool di buffer allineati, il che dovrebbe produrre una produttività significativamente più alta.

Dimensione file	AES-256-GCM Cripta	ChaCha20 Cripta	AES-256-GCM Decripta	ChaCha20 Decripta
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

Sweep della dimensione chunk (AES-256-GCM, file da 64 MiB):

Dimensione chunk	Produttività
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

Caratteristiche delle prestazioni

Il motore utilizza ring (AES-NI / NEON / ARMv8-CE ottimizzati in assembly) per le operazioni di cifratura e una pipeline io_uring a triplo buffer per l'I/O. Tre pool di buffer preallocati ruotano attraverso la pipeline: mentre le scritture del pool A vengono completate nel kernel, il pool B viene crittografato da Rayon sulla CPU e le letture del pool C vengono inviate al kernel. Questo sovrappone la latenza dell'I/O con il calcolo crittografico.

Perché AES-256-GCM è più veloce di ChaCha20-Poly1305 su file piccoli: Il backend AES-GCM di ring sfrutta le istruzioni hardware AES-NI + CLMUL disponibili su x86-64, dandogli un vantaggio hardware rispetto a ChaCha20 (che è un cifrario software). A dimensioni maggiori, entrambi i cifrari convergono a circa 1.0 GiB/s, indicando che il collo di bottiglia si sposta dalla produttività del cifrario all'overhead di invio dell'I/O.

Perché la produttività di picco è a 1-16 MiB, non a 256 MiB: I file piccoli (1-16 MiB) hanno pochi chunk, quindi il parallelismo di Rayon è efficiente e il working set si adatta alla cache. A 64-256 MiB, la pipeline io_uring è completamente attiva (tre lotti in volo), ma l'overhead per SQE e completamento CQE scala con il numero di chunk. Il design a triplo buffer garantisce che I/O e crittografia si sovrappongano, nascondendo parzialmente questo costo.

Perché circa 1.0 GiB/s e non 10+ GiB/s: L'AES-NI moderno può spingere 2-4 GiB/s per core. Con 12 thread, la produttività grezza del cifrario potrebbe superare 10 GiB/s. Tre fattori spiegano il divario: