Cómo cifrar discos con LUKS2 en Linux en 2026

El disco robado de mi laptop de 2017 sigue en mi cajón. En aquel entonces no tenía cifrado, y la lección me costó cambiar el patrón de claves SSH, GPG y tokens de autenticación de todos mis servicios. Si te roban la laptop o se te pierde un disco del servidor, lo único que te separa de que alguien lea tus datos es el cifrado del disco. En Linux el estándar desde hace casi dos décadas es LUKS, y desde 2020 la versión 2 (LUKS2) es la que viene por defecto.

LUKS2 trae lo que importa: Argon2id como KDF por defecto (más resistente que PBKDF2 contra GPUs), soporte para tokens TPM2 para desbloqueo automático en hardware moderno, headers redundantes para recuperación ante corrupción parcial, y un formato de slot extensible. Esta guía cubre la instalación desde cero, la configuración post-install, el setup de TPM2 para no escribir la passphrase en cada boot, la rotación de claves y la recuperación del header cuando algo va mal.

---

Meta description: LUKS2 es el estándar para cifrado de disco en Linux. Esta guía 2026 cubre Argon2id, cryptsetup, desbloqueo automático con TPM2, recuperación de headers y troubleshooting que sí pasa en producción.

---

Si te roban la laptop o se te pierde un disco del servidor, lo único que te separa de que alguien lea tus datos es el cifrado del disco. En Linux el estándar desde hace casi dos décadas es LUKS (Linux Unified Key Setup), y desde 2020 la versión 2 (LUKS2) es la que viene por defecto en cryptsetup, los installers de Debian, Ubuntu, Fedora y Arch. Es lo que usa tu distro cuando te pide “cifrar el disco” durante la instalación.

Esta guía es 2026, cubre la versión actual de cryptsetup (2.7+), el cambio de KDF a Argon2id (la razón por la que tu laptop arranca más lento desde 2022), el desbloqueo automático vía TPM2 sin tener que tipear la passphrase en cada boot, y los problemas reales que vas a encontrar al cifrar un disco que ya tiene datos.

TL;DR — qué es LUKS2 y cuándo lo necesitas

Caso	¿LUKS2 o alternativa?
Laptop con datos sensibles que se puede extraviar	LUKS2 (cifrado full-disk con passphrase)
Servidor con datos personales o de clientes	LUKS2 (con TPM2 + passphrase como fallback)
Disco de backup offline que se guarda en otra ubicación	LUKS2 en contenedor LUKS, o VeraCrypt si necesitas portabilidad Windows/macOS
Unidad USB que compartes entre Linux, macOS y Windows	VeraCrypt (LUKS no es legible fuera de Linux sin instalar cryptsetup)
Disco de un hypervisor (Proxmox, oVirt)	LUKS2 a nivel del guest, NO del host (rompe thin provisioning y snapshots)
NAS con muchos discos y replicación	LUKS2 solo si cifrado en reposo es requisito legal/compliance; performance cae 5-15%

Lo que LUKS2 hace bien: cifrado transparente a nivel bloque (lee/escribe sectores como si fuera un disco normal una vez abierto el volumen), soporte para múltiples keys/passphrases, metadata a prueba de corrupción parcial, integración nativa con kernel Linux vía dm-crypt, y desde la versión 2 soporte para Argon2id y tokens que permiten desbloquear con TPM2, FIDO2 o keyfile.

Lo que LUKS2 NO hace: no te protege contra un atacante que tiene tu sesión iniciada (si la laptop está desbloqueada, el disco está abierto). No te protege contra malware con privilegios de root en el sistema corriendo. No te protege de ti mismo si borrás el header LUKS y no tienes backup. Para esas capas, mira Hardening SSH y auditd para detectar cambios sospechosos como complemento.

Cómo funciona LUKS2 por dentro

LUKS2 es una capa de metadata + un mapeador de dispositivos (dm-crypt) que cifra cada sector antes de escribirlo al disco. La cadena es:

1. Header LUKS2 (16 MB al inicio del disco): guarda los slots de keys, los parámetros de cifrado (algoritmo, modo, KDF), y un JSON con la metadata del volumen. Sin este header, los datos son ruido irrecuperable aunque tengas la passphrase.
2. Master Key (generada con cryptsetup luksFormat): la clave AES-256 (o lo que elijas) que realmente cifra los datos. Vive solo en memoria RAM mientras el volumen está abierto.
3. Key Slot (hasta 8 por defecto): cada slot cifra la master key con una passphrase distinta, con un KDF (Key Derivation Function) que vuelve lento el brute-force. LUKS1 usaba PBKDF2; LUKS2 por defecto usa Argon2id, mucho más resistente a GPUs y ASICs.
4. dm-crypt mapea el dispositivo bloque cifrado a /dev/mapper/nombre y de ahí a un filesystem normal (ext4, btrfs, xfs, etc).

Cuando tipeás la passphrase en boot, cryptsetup la pasa por Argon2id (caro en CPU, del lado del atacante), descifra la master key del slot correspondiente, se la pasa al kernel, y dm-crypt la usa sector por sector con AES-NI por hardware (prácticamente cero overhead en CPUs modernas).

Requisitos y decisiones antes de empezar

Antes de tocar un disco, definí tres cosas:

1. Cifrado de disco completo vs contenedor LUKS

• Full-disk (cifra la partición raíz + particiones): lo que hace el instalador de Ubuntu cuando marcás “Encrypt the disk”. Necesita passphrase en cada boot. La partición /boot queda sin cifrar (necesita el kernel y el initramfs sin descifrar).
• Contenedor (un archivo o partición que solo se abre cuando la necesitas): más flexible, pero requiere montaje manual o vía /etc/crypttab. Útil para discos secundarios, backups, o datos que no quieres siempre montados.

Para laptops con un solo SSD: full-disk es lo correcto. Para servidores y workstations con varios discos: combinación de ambos.

2. Algoritmo de cifrado

cryptsetup luksFormat por defecto en 2026 usa AES-256-XTS (XEX-based Tweaked codebook mode with ciphertext Stealing). Es la elección correcta para el 99% de los casos. Si tu CPU no tiene AES-NI (CPUs muy viejas pre-2010), puedes cambiar a serpent o twofish, pero el rendimiento cae 5-10x. No hay razón para no usar AES-XTS a menos que trabajes en un entorno con requisitos de cifrado específicos.

Para verificar que tu CPU tiene AES-NI:

grep -o 'aes' /proc/cpuinfo | sort -u
# Si imprime "aes", tu CPU tiene las instrucciones de hardware.

Si quieres ser explícito al formatear:

sudo cryptsetup luksFormat 
  --cipher aes-xts-plain64 
  --key-size 512 
  --pbkdf argon2id 
  --pbkdf-memory 1048576 
  --pbkdf-parallel 4 
  --pbkdf-time 2000 
  /dev/sdX

--key-size 512 para XTS significa AES-256 (XTS usa dos keys de 256, total 512). --pbkdf-memory 1048576 reserva 1 GB de RAM por intento de passphrase (Argon2id); subilo si tienes RAM de sobra y quieres más seguridad contra fuerza bruta, bajalo si el dispositivo tiene poca RAM (un Raspberry Pi con 1 GB va a sufrir).

3. KDF: Argon2id (default en LUKS2) vs PBKDF2

Argon2id es el ganador del Password Hashing Competition (2015) y es resistente tanto a ataques de GPU como de ASIC. PBKDF2 (que era el default en LUKS1) es mucho más rápido de romper. No hay razón para seguir usando PBKDF2 en 2026, salvo que necesites compatibilidad con LUKS1 (no deberías).

verifica la versión de tu cryptsetup:

cryptsetup --version
# cryptsetup 2.7.5 (2026-04-15)
# Si es < 2.4, actualizá antes de formatear nada importante.

Preparación del disco (particionado)

Asumamos que el disco es /dev/sdb (ajustá según tu hardware). verifica primero qué hay ahí — lsblk y blkid te dicen si el disco tiene tabla de particiones, filesystem, o ya tiene un LUKS previo:

lsblk -f /dev/sdb
sudo blkid /dev/sdb*
# Si ya tiene un LUKS header, NO formatees sin hacer backup primero.

Si es un disco nuevo, creá una partición con fdisk o parted. Para un disco completo de datos (sin boot), puedes saltar la tabla y usar el disco raw:

sudo fdisk /dev/sdb
# g   # crear GPT nueva
# n   # nueva partición
# 1   # número 1
#     # default primer sector
#     # default último sector (todo el disco)
# w   # escribir

El particionado es necesario en general para que el kernel y fdisk distingan el disco limpio. Si quieres usar el disco raw (sin tabla de particiones), cryptsetup lo soporta con --type luks2 apuntando a /dev/sdb directamente.

Crear el volumen LUKS2

Asumamos /dev/sdb1 como la partición destino. Asegurate tres veces de que es el dispositivo correcto — el siguiente comando borra todo lo que haya ahí.

sudo cryptsetup luksFormat /dev/sdb1

cryptsetup te va a pedir confirmación tipeando YES (en mayúsculas) y después la passphrase. La passphrase tiene que ser fuerte pero recordable. Una técnica común: una frase de 5-7 palabras no relacionadas (“Caballo-Cristal-Lámpara-Verde-Número-Río-Martes”) que tiene ~60-80 bits de entropía y la puedes tipear en 5 segundos.

verifica que se creó bien:

sudo cryptsetup luksDump /dev/sdb1
# Te muestra: version 2, cipher aes-xts-plain64, MK bits 512, slots con keys, etc.

Si quieres ver los parámetros Argon2id explícitamente:

sudo cryptsetup luksDump --dump-json /dev/sdb1 | jq '.tokens,.keyslots,.segments'

Abrir el volumen y crear el filesystem

Una vez cifrado, el dispositivo sigue siendo /dev/sdb1 desde el punto de vista del kernel, pero está “cerrado” — no se puede leer ni escribir. Para abrirlo:

sudo cryptsetup open /dev/sdb1 mi-disco-secreto
# Te pide la passphrase

Esto crea /dev/mapper/mi-disco-secreto que es la vista “descifrada” del volumen. Ahora le ponés un filesystem:

sudo mkfs.ext4 -L "secreto" /dev/mapper/mi-disco-secreto

Y lo montás:

sudo mkdir -p /mnt/secreto
sudo mount /dev/mapper/mi-disco-secreto /mnt/secreto

Para verificar que está todo bien:

df -h /mnt/secreto
lsblk -f /dev/sdb
# NAME                          FSTYPE      LABEL
# sdb1                          crypto_LUKS
# └─mi-disco-secreto            ext4        secreto

Desbloqueo automático en boot con /etc/crypttab

Para que el sistema abra el volumen automáticamente en cada arranque (sin tipear la passphrase dos veces si ya la tipeaste para /), agregás una entrada en /etc/crypttab:

sudo tee -a /etc/crypttab <<'EOF'
mi-disco-secreto  /dev/sdb1  none  luks,discard
EOF

El campo none indica que la passphrase se va a pedir interactivamente (bien para laptops). Si quieres que se desbloquee con un keyfile guardado en el rootfs cifrado (útil para servidores donde tipear passphrase no es opción), generas el keyfile y apuntás ahí:

sudo dd if=/dev/urandom of=/etc/luks-keys/sdb1.key bs=512 count=4
sudo chmod 0400 /etc/luks-keys/sdb1.key
sudo cryptsetup luksAddKey /dev/sdb1 /etc/luks-keys/sdb1.key
# Te pide la passphrase existente para validar
sudo tee -a /etc/crypttab <<'EOF'
mi-disco-secreto  /dev/sdb1  /etc/luks-keys/sdb1.key  luks
EOF

Y agregás el mount point en /etc/fstab:

sudo tee -a /etc/fstab <<'EOF'
/dev/mapper/mi-disco-secreto  /mnt/secreto  ext4  defaults,noatime  0 2
EOF

La opción discard en crypttab pasa los comandos TRIM del SSD al dispositivo físico, importante para mantener el rendimiento y la vida útil del SSD. Sin esto, el SSD no sabe qué bloques se “borraron” cuando borrás archivos en el volumen cifrado.

Regenerá el initramfs para que cryptsetup esté disponible en el early boot:

sudo update-initramfs -u -k all    # Debian/Ubuntu
sudo dracut -f                     # Fedora/RHEL

Desbloqueo con TPM2 (sin tipear passphrase en cada boot)

Desde 2022, systemd-cryptenroll permite registrar la clave de cifrado en el TPM2 de la máquina. En laptops con chip TPM2 (cualquier PC corporativo desde 2018, ThinkPad/Dell/Lenovo/HP modernos), esto significa que el disco se desbloquea automáticamente al boot sin tipear nada. La passphrase queda como fallback si el TPM falla.

verifica que tienes TPM2:

ls /dev/tpm*
# /dev/tpm0  /dev/tpmrm0
# Si no aparece nada, tu CPU/placa no tiene TPM2 o está desactivado en BIOS.

Enrollá el TPM2 como token de desbloqueo:

sudo systemd-cryptenroll --tpm2-device=auto /dev/sdb1
# Esto genera una key aleatoria, la sella con el PCR7 del TPM2 (estado de Secure Boot),
# y la agrega como un nuevo key slot en el header LUKS.

Para que crypttab use el TPM2 automáticamente:

sudo tee -a /etc/crypttab <<'EOF'
mi-disco-secreto  /dev/sdb1  none  luks,tpm2-device=auto,discard
EOF
sudo update-initramfs -u -k all

Ahora reiniciá. Si tu BIOS tiene Secure Boot activo, el disco debería abrir sin pedir nada. Si no tienes Secure Boot, el TPM igualmente puede usarse pero el nivel de seguridad es menor (un atacante con acceso físico podría “politically reset” el PCR y registrar su propia key — con Secure Boot activo esto requiere romper la chain of trust primero).

El comando para verificar que la TPM2 está enrolada correctamente:

sudo systemd-cryptenroll /dev/sdb1
# Muestra los tokens activos: tpm2 + tu passphrase como fallback.

Backup y recuperación del header LUKS

Esto es lo que más gente se salta y luego se arrepiente. Si se corrompe el header LUKS, los datos son irrecuperables aunque tengas la passphrase correcta — la passphrase descifra la master key del header, sin header no hay master key.

Backup inmediato después de formatear:

sudo cryptsetup luksHeaderBackup /dev/sdb1 --header-backup-file /root/luks-header-sdb1.bin
sudo chmod 0400 /root/luks-header-sdb1.bin

Guardá ese archivo en al menos dos lugares fuera del disco que acabás de cifrar: USB aparte, NAS, cloud cifrado (B2, S3 con SSE-KMS), lo que sea. El header cabe en 16 MB así que es barato guardarlo.

Para restaurar si el header se corrompe:

sudo cryptsetup luksHeaderRestore /dev/sdb1 --header-backup-file /root/luks-header-sdb1.bin

Si NO tienes backup del header y la passphrase tampoco funciona, los datos están perdidos. No hay backdoor en LUKS, no hay “modo recuperación de fábrica”, no hay forma de derivar la master key sin el header. Esto es una feature, no un bug — es exactamente lo que hace al cifrado útil.

Migrar un disco que ya tiene datos a LUKS2

Esto es lo más delicado. No lo hagas en caliente. El flow seguro es:

1. Backup completo del disco (con rsync, dd, restic, lo que uses). El cifrado de un disco existente es una operación de reescritura total, y si algo sale mal (corte de luz, kernel panic), el disco queda con datos parcialmente cifrados que ya no puedes leer.

1. Cifrá un disco nuevo o una partición vacía. Restaurá los datos desde el backup.

1. Si no puedes agregar un disco nuevo (caso típico: laptop con un solo SSD):

– Reducí el filesystem existente con resize2fs para dejar 5-10% libre al final. – Reducí la partición con parted o fdisk. – Creá una partición nueva con el espacio liberado, cifrala con LUKS2. – Copiá los datos del filesystem viejo al nuevo. – Cambiá /etc/fstab para apuntar al volumen nuevo. – verifica que todo arranque desde el volumen nuevo antes de borrar el viejo.

El método “in-place encryption” existe (cryptsetup-reencrypt) pero es riesgoso: si se interrumpe, los datos son irrecuperables. No lo uses en producción sin backup externo previo.

Troubleshooting: lo que realmente pasa

Después de cifrar varios discos y ayudar a otros con esto, estos son los problemas que vas a hitear. Anotalos porque la documentación oficial no siempre los cubre bien.

“Command failed: Cannot initialize device-mapper”

Típico cuando intentas abrir un volumen y otro proceso ya tiene el mapper abierto, o cuando dm-crypt no está cargado en el kernel. Verificación:

sudo dmsetup targets | grep crypt
# Si no aparece "crypt", el módulo dm_crypt no está cargado. sudo modprobe dm_crypt.
sudo ls /dev/mapper/
# Si ves el nombre del volumen listado, ya está abierto por otro proceso.

Si ya está abierto: sudo cryptsetup close mi-disco-secreto y después open de nuevo.

“No key available with this passphrase”

La passphrase está mal, o el key slot está corrupto. verifica:

sudo cryptsetup luksDump /dev/sdb1 | grep -A 2 "Key Slot"
# Te dice qué slots están activos (ENABLED) y cuáles están vacíos (DISABLED).

Si tienes backup del header, restaurá primero. Si no, prueba las otras passphrases que hayas podido configurar (recuerda que LUKS2 soporta hasta 8 keys por volumen). Si ninguna funciona, los datos son irrecuperables — esto es el “feature” del cifrado.

La partición se ve como “unknown” en lsblk o fdisk

Normal — el kernel no sabe qué hacer con un LUKS header hasta que cryptsetup lo abra. Si fdisk te muestra “unknown” en el tipo, es porque el header LUKS2 no tiene un partition type ID estándar (LUKS usa MBR type 0x83 o GPT type “Linux filesystem” — depende del formateador que usaste).

Para verificar el header manualmente:

sudo hexdump -C /dev/sdb1 | head -1
# Debería empezar con los bytes hex 4c 55 4b 53 ba be  (ASCII "LUKS" + 0xba 0xbe)

Si no muestra esos bytes al inicio, el header está corrupto o no es LUKS.

El sistema no arranca después de cifrar /

El initramfs no tiene cryptsetup o el hook de cryptsetup no detectó tu partición. Regenerá el initramfs manualmente:

# Booteá desde un live USB, montá el volumen cifrado y el rootfs
sudo cryptsetup open /dev/sda2 root-cifrado
sudo mount /dev/mapper/root-cifrado /mnt
sudo mount /dev/sda1 /mnt/boot    # partición /boot sin cifrar
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt
sudo update-initramfs -u -k all
exit
sudo reboot

“device-mapper: reload ioctl on X failed: Invalid argument”

Tu kernel y tu versión de cryptsetup están desincronizadas, o el header tiene parámetros que tu kernel no soporta (típico con Luks2 en kernels muy viejos < 4.x). Actualizá cryptsetup y reiniciá.

Cifrado de partición raíz (rootfs)

Si quieres cifrar la partición raíz completa (el caso típico de “encrypt the disk” en el installer de Ubuntu), el flow es distinto porque necesitas que cryptsetup corra ANTES de que el rootfs se monte.

En Debian/Ubuntu moderno, el instalador lo hace solo si eliges “Use entire disk” + “Encrypt”. Si quieres hacerlo a mano en un sistema ya instalado, el camino es:

1. Backup completo del sistema (lo que puedas permitirte perder).
2. Boot desde live USB.
3. Crear partición LUKS2 sobre la partición raíz actual.
4. Copiar todo el contenido del rootfs viejo al nuevo.
5. Actualizar /etc/fstab con el UUID del nuevo rootfs cifrado y regenerar el initramfs (los hooks de initramfs-tools detectan automáticamente las entradas en /etc/crypttab).
6. Configurar /etc/crypttab con key-file none (pide passphrase en boot) y agregar el parámetro de kernel rd.luks.uuid=<UUID> (o luks.uuid= en systemd-boot) para que systemd-cryptsetup abra la partición raíz en early boot.

Es complejo y arriesgado si no tienes experiencia. Mi recomendación: si necesitas cifrar el rootfs, hazlo en una instalación nueva, marcando “Encrypt the disk” en el instalador. El camino manual es solo para sysadmins que saben lo que están haciendo y tienen backup.

LUKS2 vs VeraCrypt vs BitLocker

Feature	LUKS2	VeraCrypt	BitLocker
Plataforma	Linux nativo	Multiplataforma (Linux/macOS/Windows)	Solo Windows
Algoritmos	AES, Serpent, Twofish (configurable)	AES, Serpent, Twofish, cascadas	AES-128/256 (XTS)
KDF	Argon2id (default)	PBKDF2 (RIPEMD160/SHA512)	No expuesto
Hidden volumes	No	Sí (plausible deniability)	No
Integración con kernel	Nativa vía dm-crypt	FUSE / dm-crypt	No en Linux
Token TPM2	Sí (systemd-cryptenroll)	No	Sí (nativo Windows)
Licencia	GPLv2	Apache 2.0 + VeraCrypt additions	Propietaria

Si tus discos solo se tocan desde Linux: LUKS2. Si los movés entre Linux, macOS y Windows regularmente (USB portable, discos de backup): VeraCrypt. Si tienes un Windows-only y el disco nunca sale de ahí: BitLocker (pero no lo vas a montar desde Linux sin dislocker).

Performance: lo que perdés y lo que no

Con AES-NI por hardware (cualquier CPU moderna, 2010+), el overhead de cifrado/descifrado en uso real es menos del 2% para cargas típicas (web server, base de datos, file server). Los números que vas a ver en benchmarks sintéticos (5-15% más lento que disco sin cifrar) se deben al overhead de AES-NI propiamente dicho, que es prácticamente gratis en operaciones reales.

Donde sí vas a notar diferencia:

• Discos HDD muy viejos sin DMA por hardware: el cifrado compite con el I/O del disco.
• Discos SSD muy baratos sin DRAM cache: la latencia del SSD ya es alta, sumale cifrado y se nota.
• Cargas 100% random write con qdepth=1 (algunos workloads de base de datos): la diferencia es ~5-8%.

En SSDs NVMe modernos con AES-NI, vas a estar saturando el ancho de banda del disco antes que la CPU. El cifrado es gratis.

Checklist antes de cerrar este post

Si llegaste hasta acá y quieres implementar LUKS2 en tu setup:

• [ ] Decidí si necesitas full-disk o contenedor (o ambos).
• [ ] Verifiqué que mi CPU tiene AES-NI (grep aes /proc/cpuinfo).
• [ ] Hice backup del contenido actual del disco antes de tocar nada.
• [ ] Tengo cryptsetup 2.4+ instalado (cryptsetup --version).
• [ ] Después de formatear, hice backup del header LUKS y lo guardé fuera del disco cifrado.
• [ ] Configuré /etc/crypttab y /etc/fstab con los UUIDs correctos (no /dev/sdX que pueden cambiar entre boots).
• [ ] Regeneré el initramfs.
• [ ] Probé reiniciar y que el volumen se abra correctamente.
• [ ] Si es laptop, consideré enrollar TPM2 para no tipear passphrase en cada boot.
• [ ] Documenté dónde está el backup del header (sin esa nota, el backup es inútil cuando lo necesites en 2 años).

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux