frogsnot/concryptorUn motor de cifrado de archivos de múltiples hilos y gigabytes por segundo. Logra un rendimiento extremo mediante un pipeline io_uring de triple búfer sin bloqueos, fragmentación paralela con Rayon y AEADs acelerados por hardware (AES-256-GCM / ChaCha20).
Un motor de cifrado AEAD multi-hilo escrito en Rust. Cifra y descifra archivos a un rendimiento de gigabytes por segundo utilizando un pipeline de io_uring con triple búfer, procesamiento paralelo de fragmentos mediante Rayon y cifrados optimizados en ensamblador a través de ring.
⚠️ AVISO: SOFTWARE EXPERIMENTAL ⚠️
Este proyecto es extremadamente nuevo y actualmente NO se recomienda para uso en producción o en entornos críticos. Si bien los primitivos criptográficos (AES-256-GCM, ChaCha20-Poly1305 mediante ring) y el diseño del formato son sólidos, el código base no ha pasado por auditorías de seguridad formales ni pruebas exhaustivas en el mundo real. Úselo bajo su propio riesgo. Para proteger datos sensibles, considere usar herramientas probadas como GnuPG, age u OpenSSL hasta que este proyecto madure.
ring (optimizado en ensamblador)--memory)seal_in_place_separate_tag / open_in_place mediante ring minimiza las asignaciones en el bucle principalO_DIRECT, evitando la caché de páginas del kernel para lecturas/escrituras a velocidad DMA en NVMe. Los grupos de búferes usan std::alloc con alineación de 4096 bytesBenchmark con cargo bench (Criterion, 10 muestras por medición). La derivación de clave está excluida: los números reflejan solo el rendimiento criptográfico puro.
Hardware:
Nota sobre E/S: Criterion escribe archivos temporales en /tmp, que en este sistema es tmpfs (respaldado por RAM). Con O_DIRECT, el kernel no puede usar DMA asíncrono real en tmpfs, por lo que estos números reflejan el rendimiento del cifrado + la sobrecarga de io_uring sin el beneficio de evitar DMA. En una unidad NVMe Gen4 real, O_DIRECT elimina el doble buffer de la caché de páginas y permite DMA directamente en los grupos de búferes alineados, lo que debería proporcionar un rendimiento significativamente mayor.
| Tamaño de archivo | Cifrado AES-256-GCM | Cifrado ChaCha20 | Descifrado AES-256-GCM | Descifrado ChaCha20 |
|---|---|---|---|---|
| 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 |
Barrido de tamaños de fragmento (AES-256-GCM, archivo de 64 MiB):
| Tamaño de fragmento | Rendimiento |
|---|---|
| 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 |
El motor utiliza ring (AES-NI / NEON / ARMv8-CE optimizado en ensamblador) para las operaciones de cifrado y un pipeline de io_uring con triple búfer para E/S. Tres grupos de búferes preasignados rotan a través del pipeline: mientras las escrituras del grupo A se completan en el kernel, el grupo B está siendo cifrado por Rayon en la CPU, y las lecturas del grupo C se están enviando al kernel. Esto superpone la latencia de E/S con el cómputo criptográfico.
Por qué AES-256-GCM es más rápido que ChaCha20-Poly1305 en archivos pequeños:
El backend de AES-GCM de ring explota las instrucciones de hardware AES-NI + CLMUL disponibles en x86-64, lo que le otorga una ventaja de hardware sobre ChaCha20 (que es un cifrado por software). En tamaños más grandes, ambos cifrados convergen a ~1.0 GiB/s, lo que indica que el cuello de botella se desplaza del rendimiento del cifrado a la sobrecarga de envío de E/S.
Por qué el rendimiento máximo está en 1-16 MiB, no en 256 MiB: Los archivos pequeños (1-16 MiB) tienen pocos fragmentos, por lo que el paralelismo de Rayon es eficiente y el conjunto de trabajo cabe en la caché. En 64-256 MiB, el pipeline de io_uring está completamente activo (tres lotes en vuelo), pero la sobrecarga de envío por SQE y finalización por CQE escala con el número de fragmentos. El diseño de triple búfer asegura que E/S y cifrado se superpongan, ocultando parcialmente este costo.
Por qué ~1.0 GiB/s y no 10+ GiB/s: El AES-NI moderno puede alcanzar 2-4 GiB/s por núcleo. Con 12 hilos, el rendimiento bruto del cifrado podría exceder 10 GiB/s. Tres factores explican la brecha: