Concryptor

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.

Características

• Soporte de doble cifrado: AES-256-GCM (AES-NI en hardware) y ChaCha20-Poly1305 mediante ring (optimizado en ensamblador)
• Cifrado paralelo: Procesamiento de fragmentos multi-hilo basado en Rayon en todos los núcleos de la CPU
• Pipeline de io_uring con triple búfer: Superpone las E/S del kernel y las operaciones criptográficas de la CPU utilizando tres grupos de búferes rotativos — mientras las escrituras de un lote están en curso en el kernel, el siguiente lote está siendo cifrado por Rayon en la CPU, y las lecturas del tercer lote se están enviando al kernel. Sin sobrecarga de syscall por fragmento, sin limitaciones de mmap (sin SIGBUS, sin agotamiento del espacio de direcciones virtual)
• Derivación de clave Argon2id: Estiramiento de contraseña de estándar industrial (por defecto 256 MiB de memoria, 3 iteraciones, configurable mediante --memory)
• Parámetros KDF autodescriptivos: El costo de memoria, las iteraciones y el paralelismo se almacenan en la cabecera del archivo cifrado, por lo que el descifrado utiliza exactamente los parámetros elegidos en el momento del cifrado. Los archivos heredados (valor centinela todo ceros) se manejan de forma transparente con los valores predeterminados antiguos de 64 MiB
• Nonces indexados por fragmento: La derivación de nonce mediante XOR al estilo TLS 1.3 previene ataques de reordenación de fragmentos
• AAD autenticado por cabecera: La cabecera completa alineada a 4 KiB se incluye en el AAD de cada fragmento, autenticando todos los campos de la cabecera (núcleo, parámetros KDF y bytes reservados) y previniendo ataques de truncamiento, manipulación de campos de cabecera y contrabando en bytes reservados
• Fragmento final al estilo STREAM: Un indicador de fragmento final en el AAD previene ataques de truncamiento y extensión (inspirado en la construcción STREAM)
• Aleatoriedad fresca por archivo: Se generan una sal criptográficamente aleatoria de 16 bytes y un nonce base de 12 bytes para cada cifrado, almacenados en la cabecera
• Cifrado in situ: seal_in_place_separate_tag / open_in_place mediante ring minimiza las asignaciones en el bucle principal
• Zeroización de contraseñas: Las claves y contraseñas se borran de forma segura de la memoria después de su uso
• O_DIRECT + formato alineado por sectores: Cabecera y ranuras de fragmentos alineadas a 4 KiB permiten E/S con O_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 bytes
• Cifrado de directorios: Cifre directorios completos como un único archivo cifrado. El empaquetado en tar conserva nombres de archivo, permisos, marcas de tiempo y estructura de directorios dentro del texto cifrado. La extracción valida contra ataques de path traversal y de escape de enlaces simbólicos
• Formato de archivo autodescriptivo: La cabecera almacena el cifrado, tamaño de fragmento, tamaño original del archivo, sal, nonce base y parámetros KDF de Argon2id

Rendimiento

Benchmark 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:

• CPU: AMD Ryzen 5 5600X (6c/12t @ 3.7 GHz base)
• RAM: 2x 8 GiB DDR4-2666 (doble canal, 16 GiB en total)
• SO: Linux

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.

Barrido de tamaños de fragmento (AES-256-GCM, archivo de 64 MiB):

Características de rendimiento

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:

1. Sobrecarga por SQE de io_uring: Cada fragmento requiere un SQE de lectura y un SQE de escritura. Con 256 fragmentos para un archivo de 256 MiB, eso son 512 SQEs enviados y 512 CQEs recolectados. Si bien io_uring evita el costo de transición de kernel por syscall de pread/pwrite, aún tiene sobrecarga de búfer circular y barrera de memoria por SQE.
2. Profundidad del pipeline: Con PIPELINE_DEPTH=3, solo tres lotes rotan a través del pipeline en un momento dado. La superposición en estado estacionario verdadera requiere al menos tres lotes; los archivos que caben en uno o dos lotes no se benefician del pipeline.
3. Efectos de jerarquía de caché: El 5600X tiene 512 KiB de L2 por núcleo y 32 MiB de L3 compartida. El fragmento predeterminado de 4 MiB excede L2, y un lote de ~21 fragmentos (84 MiB de conjunto de trabajo activo) excede con creces L3. Los tamaños de fragmento más pequeños (64-256 KiB) muestran mejor rendimiento en el barrido porque una mayor parte del conjunto de trabajo permanece en caché.

Ciclo de vida y seguridad de los búferes: Los grupos de búferes se asignan una vez mediante std::alloc::alloc_zeroed con Layout::from_size_align(size, 4096) antes de que se cree el anillo io_uring, y se reutilizan en todas las iteraciones del pipeline sin reasignación. Cada fragmento cifrado se rellena con ceros hasta la alineación de sector antes de la escritura con O_DIRECT. El anillo se elimina explícitamente antes que los grupos de búferes, asegurando que el kernel nunca haga referencia a memoria liberada (sin UAF).

Instalación

git clone https://github.com/frogsnot/concryptor.git
cd concryptor
cargo build --release

El binario estará en target/release/concryptor.

Uso

Cifrar

# AES-256-GCM (predeterminado), salida a myfile.dat.enc
concryptor encrypt myfile.dat

# ChaCha20-Poly1305, ruta de salida personalizada
concryptor encrypt myfile.dat --cipher chacha -o encrypted.enc

# Tamaño de fragmento personalizado (en MiB)
concryptor encrypt largefile.iso --chunk-size 8

# KDF más fuerte (costo de memoria de 512 MiB)
concryptor encrypt secrets.tar --memory 512

# No interactivo (omite la solicitud de contraseña)
concryptor encrypt myfile.dat -p "password"

Nota de seguridad: --password / -p pasa la contraseña como argumento de CLI, que es visible en la salida de ps y en el historial del shell. Para uso interactivo, omítalo para obtener la solicitud oculta segura. Para scripts, prefiera limpiar el historial después o usar un envoltorio que lea desde un descriptor de archivo.

Cifrar un directorio

# Cifrar un directorio (detección automática, produce mydir.tar.enc)
concryptor encrypt mydir/

# Con cifrado y salida personalizados
concryptor encrypt mydir/ --cipher chacha -o secrets.enc

El cifrado de directorios crea un archivo tar temporal (.concryptor-*.tar, permisos 0600, nombre generado por CSPRNG), lo cifra y luego elimina automáticamente el archivo temporal. Los nombres de archivo, la estructura de directorios, los permisos y las marcas de tiempo están todos dentro de la carga útil cifrada.

Descifrar

# Elimina automáticamente la extensión .enc
concryptor decrypt myfile.dat.enc

# Ruta de salida personalizada
concryptor decrypt encrypted.enc -o restored.dat

# No interactivo
concryptor decrypt myfile.dat.enc -p "password"

Descifrar y extraer un directorio

# Descifrar y extraer en un solo paso (elimina automáticamente .tar.enc -> nombre de directorio)
concryptor decrypt mydir.tar.enc --extract

# Bandera corta, directorio de salida personalizado
concryptor decrypt mydir.tar.enc -x -o restored_dir/

Sin --extract, descifrar un archivo de directorio produce el archivo .tar intermedio, que puede inspeccionar o extraer manualmente.

Ayuda

concryptor --help
concryptor encrypt --help
concryptor decrypt --help

Formato de archivo

Todos los valores están en little-endian. La cabecera ocupa un sector completo de 4 KiB; cada ranura de fragmento cifrado se rellena hasta el siguiente límite de 4 KiB. Esto asegura que cada desplazamiento y tamaño de E/S esté alineado a sector para O_DIRECT.

Offset  Tamaño  Campo
------  ------  ---------------------
0       10      Bytes mágicos "CONCRYPTOR"
10       1      Versión de formato (4)
11       1      Tipo de cifrado (0 = AES-256-GCM, 1 = ChaCha20-Poly1305)
12       4      Tamaño de fragmento (bytes, LE)
16       8      Tamaño original del archivo (bytes, LE)
24      16      Sal Argon2 (criptográficamente aleatoria, única por archivo)
40      12      Nonce base (criptográficamente aleatorio, único por archivo)
52       4      Argon2 m_cost en KiB (LE, 0 = heredado 64 MiB)
56       4      Argon2 t_cost / iteraciones (LE, 0 = heredado 3)
60       4      Argon2 p_cost / paralelismo (LE, 0 = heredado 4)
64    4032      Reservado (relleno con ceros hasta 4096 bytes)
4096    ...      [Fragmento 0: texto cifrado + etiqueta de 16 bytes + relleno de ceros hasta límite de sector]
                 [Fragmento 1: texto cifrado + etiqueta de 16 bytes + relleno de ceros hasta límite de sector]
                 ...

Para fragmentos de 4 MiB: cada ranura de disco es ceil((4194304 + 16) / 4096) * 4096 = 4198400 bytes (4080 bytes de relleno por fragmento). Los 4032 bytes reservados en la cabecera están disponibles para características futuras (ranuras de clave asimétrica, metadatos, etc.).

La sal y el nonce base se generan frescos a partir de rand::rng() (respaldado por el CSPRNG del SO) en cada cifrado. Reutilizar una contraseña entre archivos es seguro porque diferentes sales producen diferentes claves Argon2id, y diferentes nonces base producen nonces por fragmento diferentes.

Diseño de seguridad

• Derivación de nonce: chunk_nonce = base_nonce XOR chunk_index (estilo TLS 1.3). Intercambiar fragmentos provoca fallo de descifrado porque el nonce en la posición N no coincidirá con el nonce usado para cifrar el fragmento originalmente en la posición M. Nota: La derivación de nonce mediante XOR tiene una debilidad teórica cuando se usa la misma clave en múltiples flujos (distintos nonces base pueden producir espacios de nonce superpuestos). Esto no aplica a Concryptor porque cada cifrado genera una sal aleatoria fresca de 128 bits, produciendo una clave Argon2id única por archivo. La unicidad del nonce solo importa bajo la misma clave, y la probabilidad de reutilización de clave es ~2^-128 por par de archivos.
• AAD autenticado por cabecera: Cada llamada AEAD de fragmento usa AAD = cabecera_completa_alineada (4096) || chunk_index (8 LE) || is_final (1) (4105 bytes en total). El sector completo de cabecera de 4 KiB (campos principales, parámetros KDF y relleno reservado) está vinculado en la etiqueta de autenticación de cada fragmento. Modificar cualquier byte de la cabecera (tipo de cifrado, tamaño de fragmento, tamaño original, sal, nonce, parámetros KDF o relleno reservado) invalida todos los fragmentos. Esto previene ataques de truncamiento donde un adversario edita original_size y elimina fragmentos finales, y también previene el contrabando de datos en la región de relleno reservado. Los archivos heredados v3 se descifran con AAD de 52 bytes para compatibilidad hacia atrás; no es posible una degradación de v4 a v3 porque el byte de versión en sí está dentro del AAD autenticado.
• Indicador de fragmento final al estilo STREAM: El último byte del AAD es 0x01 para el fragmento final y 0x00 para todos los demás. Esto previene dos ataques:
  • Truncamiento: Eliminar el fragmento final y promover un fragmento no final al final falla porque el fragmento no final fue cifrado con pero el descifrado espera .

Pruebas

# Ejecutar el conjunto completo de pruebas (67 pruebas)
cargo test

# Ejecutar benchmarks (informes HTML en target/criterion/)
cargo bench

# Filtrar benchmarks
cargo bench -- "encrypt/AES"
cargo bench -- "chunk_sweep"

El conjunto de pruebas cubre:

• Pruebas de ida y vuelta de serialización/deserialización de cabecera
• Determinismo y sensibilidad de la derivación de clave
• Propiedades de unicidad e identidad del nonce
• Pruebas de ida y vuelta de cifrado/descifrado para ambos cifrados en varios tamaños de archivo (vacío, 1 byte, casos límite, múltiples fragmentos)
• Rechazo de contraseña incorrecta
• Detección de manipulación (texto cifrado alterado, etiquetas corruptas, sal corrupta, archivos truncados)
• Detección de ataque de reordenación de fragmentos
• Detección de falta de coincidencia de tipo de cifrado
• Detección de ataque de truncamiento (original_size modificado + fragmentos eliminados)
• Detección de manipulación de campos de cabecera (chunk_size modificado)
• Detección de manipulación de bytes de cabecera reservados (región de relleno modificada)
• Verificación de cifrado no determinista
• Prueba de estrés con 256 fragmentos pequeños
• Pruebas de ida y vuelta de empaquetado/desempaquetado de archivos de directorio (ambos cifrados)
• Pruebas de ida y vuelta de directorio vacío, directorio profundamente anidado, muchos archivos y contenido binario
• Preservación de enlaces simbólicos para enlaces internos válidos
• Rechazo de enlaces simbólicos que escapan de la raíz de extracción (travesía absoluta y relativa)
• Limpieza automática de archivos temporales al soltar
• Rechazo de contraseña incorrecta para archivos cifrados

Dependencias

Instalar

# Desde crates.io (recomendado)
cargo install concryptor

# Desde el código fuente
git clone https://github.com/FrogSnot/Concryptor
cd Concryptor
cargo build --release
# El binario está en target/release/concryptor

Licencia

Este proyecto está licenciado bajo la GNU Affero General Public License v3.0.