En 2022, sur un système GNU/Linux Debian 11 (bullseye) avec la version 2.3.7 de cryptsetup, cryptsetup luksFormat utilise par défaut la version 2 de LUKS (LUKS2), aes-xts-plain64 et une clé de 512 bits pour le chiffrement, SHA-256 pour l'intégrité, et Argon2 pour la dérivation de la clé (merci LUKS2).
Notons que LUKS2 permet, entre autres, d'enregistrer, dans l'entête d'un conteneur chiffré, un libellé et un sous-système. Ils sont lus par les outils de partitionnement comme gparted (pratique pour retrouver ses petits) et par des scripts udev (pour automatiser des actions dès qu'un conteneur est détecté).
Pour créer un conteneur chiffré, j'utilise donc la commande : cryptsetup luksFormat -c aes-xts-plain64 -s 512 --pbkdf argon2id -h sha512 --label <libellé> /dev/sdXY. J'explicite les paramètres par défaut, mais j'utilise SHA-512 au lieu de SHA-256 (par prévoyance, puisque ce conteneur va servir des années durant).
ÉDIT DU 20/06/2023 : je bascule sur argon2id, algo par défaut à partir de la version 2.4 de cryptsetup conformément aux sections 1 et 7.4 du RFC 9106. En prenant beaucoup de recul (il y a peu d'infos techniques concernant l'anarchiste français et aucune criticité immédiate à passer à argon2id), lire également PSA: upgrade your LUKS key derivation function via https://twitter.com/bearstech/status/1648626089877467137. FIN DE L'ÉDIT DU 20/06/2023.
ÉDIT DU 03/07/2023 : les algos argon sont gourmands en RAM, c'est leur but. Un luksOpen échoue sur un système Debian GNU/Linux doté de 1 Go de RAM malgré le peu de services. FIN DE L'ÉDIT DU 03/07/2023.