La función de cifrado de datos en reposo de DuckDB

 (duckdb.org)
1 puntos por GN⁺ 2025-11-22 | 1 comentarios | Compartir por WhatsApp
  • Desde la versión 1.4 de DuckDB se agregó la función de cifrado de datos en reposo (Data-at-Rest Encryption), que permite proteger todo el archivo de base de datos con cifrado estándar basado en AES
  • Los algoritmos compatibles son AES-GCM-256 y AES-CTR-256; entre ellos, GCM incluye una etiqueta de autenticación (tag) para verificar la integridad de los datos
  • El cifrado se aplica a los archivos de base de datos, el WAL (Write-Ahead Log) y los archivos temporales, e incluye una estructura de caché segura para la administración de claves y la protección en memoria
  • Se ofrecen dos implementaciones, OpenSSL y Mbed TLS; al usar OpenSSL, gracias a la aceleración por hardware, casi no hay pérdida de rendimiento
  • Los archivos DuckDB cifrados logran al mismo tiempo seguridad y portabilidad, lo que permite distribuir datos de forma segura incluso en entornos de nube o CDN

Resumen del cifrado

  • Desde DuckDB 1.4 es posible cifrar de forma transparente (Transparent Encryption) todo el archivo de base de datos
    • Al guardar, se usa cifrado AES-GCM-256 o AES-CTR-256
    • AES-GCM calcula una etiqueta para verificar la integridad, mientras que AES-CTR es más rápido pero no tiene función de autenticación
  • AES es un algoritmo de cifrado simétrico, en el que se usa la misma clave para cifrar y descifrar
  • Se usan IV (Initialization Vector) y nonce para garantizar que el mismo texto plano se convierta en textos cifrados distintos
  • Aún no cumple por completo con los requisitos del estándar NIST

Estructura de implementación interna de DuckDB

  • El encabezado principal del archivo de base de datos se mantiene en texto plano y almacena una bandera que indica si está cifrado y los metadatos de cifrado
    • Los metadatos incluyen el identificador de la base de datos (salt), información del algoritmo de cifrado y un canary cifrado
  • Mediante una función de derivación de claves (KDF), la clave ingresada por el usuario se convierte en una clave segura de 32 bytes
    • La clave derivada se guarda en una caché segura y no se intercambia al disco
    • La clave original se elimina de la memoria de inmediato
  • Los bloques de datos se almacenan por defecto en unidades de 256 KB y, al cifrarse, se agregan nonce/IV y tag al encabezado del bloque, ampliándolo a 40 bytes
    • La suma de verificación se almacena cifrada

Cifrado del WAL (Write-Ahead Log)

  • El WAL es un archivo de registro para recuperación de transacciones, y en DuckDB se cifra por entrada
    • A cada entrada se le agregan nonce y tag para protegerla con AES-GCM
    • Una entrada cifrada del WAL se compone en este orden: longitud (texto plano) → nonce → checksum cifrado y datos → tag
  • En las bases de datos donde se especifica una clave de cifrado, el cifrado del WAL se activa automáticamente

Cifrado de archivos temporales

  • Los archivos temporales que se generan en operaciones grandes como ordenamientos, joins y funciones de ventana también se cifran automáticamente
    • Se activa al conectar una base de datos cifrada o al configurar SET temp_file_encryption = true
    • DuckDB genera internamente una clave temporal; si hay un conflicto, no será posible descifrar
  • Los archivos temporales tienen extensiones .tmp o .block, e incluyen información de tamaño en el encabezado
    • La suma de verificación se omite para reducir el costo de cálculo

Cómo usar el cifrado

  • Se admiten tres formas:
    1. Cifrar una base de datos existente
    2. Crear una nueva base de datos cifrada
    3. Volver a cifrar una base de datos ya cifrada
  • Comando de ejemplo: 
    ATTACH 'encrypted.duckdb' AS encrypted (ENCRYPTION_KEY 'asdf');
COPY FROM DATABASE unencrypted TO encrypted;
  • Se puede verificar si una base de datos está cifrada con el comando FROM duckdb_databases();
  • El algoritmo de cifrado predeterminado es AES-GCM, y si hace falta se puede especificar AES-CTR
  • Los datos cifrados tienen alta entropía (Entropy) y se ven como datos aleatorios

Implementación y rendimiento

  • Para minimizar las dependencias externas, DuckDB incluye dos implementaciones de cifrado: Mbed TLS y OpenSSL
    • Mbed TLS tiene menor rendimiento porque la aceleración por hardware está desactivada y, debido al hallazgo de una vulnerabilidad en su generador de números aleatorios, la función de escritura fue deshabilitada (desde 1.4.1)
    • OpenSSL usa aceleración por hardware y un generador de números aleatorios seguro, y cambia automáticamente al cargar la extensión httpfs
  • Resultados de pruebas de rendimiento:
    • Consulta SUMMARIZE sin cifrado: 5.4 segundos
    • Cifrado con Mbed TLS: 6.2 segundos
    • Cifrado con OpenSSL: 5.4 segundos (sin pérdida de rendimiento)
  • En las pruebas TPC-H Power/Throughput también hubo muy poca diferencia de rendimiento al usar cifrado
    • Power@Size: 624,296 → 571,985
    • Throughput@Size: 450,409 → 145,353 (ligera disminución cuando aumenta el I/O de disco)

Conclusión

  • La función de cifrado de datos en reposo de DuckDB permite proteger de forma segura todo el archivo de base de datos
  • Como también se cifran el WAL y los archivos temporales, se reduce el riesgo de filtración de datos incluso en entornos de nube
  • Con una implementación basada en OpenSSL casi no hay pérdida de rendimiento, por lo que puede usarse de forma eficiente en entornos reales
  • Los archivos DuckDB cifrados también son adecuados para la distribución externa, como mediante CDN, y mantienen funciones existentes como el almacenamiento de múltiples tablas
  • El equipo de DuckDB planea mejorar la función en el futuro a partir de los comentarios de los usuarios

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-11-22
Opiniones en Hacker News

  • La sensibilidad de AES-GCM a la reutilización del nonce es una parte complicada de implementar
    La documentación muestra que son conscientes de ello, pero no compartieron cómo lo resuelven
    En el encabezado se incluye un nonce de 16 bytes en vez de 12, y no queda claro qué bytes son aleatorios, lo que resulta confuso. Me pregunto si se me pasó algo

    • La estructura usa una clave estática, genera un nonce aleatorio de 12 bytes y no usa claves por sesión en el búfer temporal

  • Me sigue sorprendiendo lo que logra el equipo de DuckDB
    Antes hice una solución simple para cifrar archivos de DuckDB con OpenSSL, pero la primera consulta tardaba el doble y además usaba mucha memoria
    En cambio, DuckDB aprovecha cifrado por páginas y la aceleración AES del CPU, así que el costo de lectura/escritura es casi nulo

    • Me pregunto por qué no simplemente usar LUKS
      Aprovecha la aceleración a nivel kernel y funciona de forma transparente para las aplicaciones de arriba
      A menos que varias apps necesiten distintos ACL y claves, no hace falta que el cifrado esté dentro de la base de datos
    • Sinceramente, no creo que lo de DuckDB sea tan “sorprendente”
      Comparado con un cifrado simple de archivo completo, claro que se ve mejor, pero esto es una implementación de nivel básico
      Nosotros mismos deberíamos aspirar a este nivel de calidad
    • Al final, es gracias al pipelining
      Comparado con la E/S del almacenamiento, el costo del cifrado es casi gratis

  • Me pregunto si, aparte de MotherDuck, existe algún modelo que opere bien DuckDB en la nube para múltiples usuarios
    Estoy buscando una arquitectura donde varios usuarios puedan acceder al mismo tiempo, como en una base de datos tradicional, y aun así aprovechar las ventajas de DuckDB

    • Si usas DuckDB puro, puedes poner al frente un servidor Arrow Flight o usar la extensión httpserver
      El rendimiento cambia bastante según dónde guardes el archivo .duckdb (S3 vs EFS)
      Pero DuckLake parece una mejor opción multijugador
      Nosotros usamos DuckLake en el producto y, para reducir la pérdida de rendimiento, guardamos las tablas analíticas en almacenamiento rápido como GCP Filestore
      Incluso dentro de un mismo catálogo de DuckLake se pueden mezclar varios tipos de almacenamiento, lo que da flexibilidad
    • Últimamente veo muchas publicaciones sobre “DuckDB dentro de Postgres”, probablemente eso sea lo que estás buscando
    • También vale la pena revisar GizmoSQL

  • DuckDB me ha resultado más útil que las herramientas de IA que he usado hasta ahora
    Me gustan los LLM, pero en eficiencia real de trabajo DuckDB me ayuda mucho más

  • Me da curiosidad cómo manejan la indexación de claves
    Quisiera saber si durante la búsqueda localizan la clave ya cifrada o si van descifrando bloque por bloque

  • Se dice que la “extensión de cifrado de SQLite es un add-on de pago de 2000 dólares”, pero
    SQLiteMultipleCiphers existe gratis desde hace mucho tiempo
    Además, Turso Database trae cifrado por defecto

    • En la práctica, me pregunto cómo usar estas variantes de SQLite en Python o Go compilándolas junto con plugins
      El proceso de enlazado parece complicado según el lenguaje
    • También está SQLCipher
      Es una solución desarrollada desde 2009 y funciona de forma estable