Hey there. Maybe someone can help me a bit with the following. First, what I want to do are basically two things: a) The usual (full) disc encryption. b) (Ab)using cryptsetup for file(!) encryption/integrity protection as an addition to e.g. OpenPGP. The problem with the later is IMO simply that despite of some years of effort now, there seem to be only little progress in getting new algorithms implemented or even just standardised, for both, the actual symmetric algos but also things like PBKDF. The idea here is to create a LUKS2 volume with just the right payload size that said file fits in. If the file itself (e.g. a backup archive) is also mountable (e.g. via fuse) one can first map the LUKS2 volume and then the inner archive, just like a filesystem. One could even stack that and put a LUKS2 volume inside another one, maybe using different algos. Since all these would be mostly long-term backup archives, it doesn't really matter if things are terribly slow. 1) My understanding was that LUKS2 is already considered stable, but AEAD(in dm-crypt) still isn't, right? Is there any expectation on when this changes? Are there any notable issues left with AEAD-support (especially such that are security relevant)? And for the use-case (a)... wouldn't one run into terrible performance problems when one has the integrity data after each block and thus the block alignment is distorted? 2) Which (AEAD / integrity protection) alogs are secure? Documentations seem to mostly lack that information (or even the actual cipher strings). There are some infos in the 2.0.0 release notes but it's not really clear to me how current these are. I vaguely remember: - GCM (e.g. as with aes-gcm-random) is *unsafe* because of the too small nonce Has that changed (i.e. is there one available with largerer nonce? - The previously recommended MORUS has been broken. What about: - ChaCha20+Poly1305 ? I've recorded in my own note that DJB stated for Poly1305(-AES): “Do not generate or accept messages longer than a gigabyte. If you need to send large amounts of data, you are undoubtedly breaking the data into small packets anyway; security requires a separate authenticator for every packet.” => Does this affect us (cause clearly LUKS volumes will be > 1GB)? Are the following safe (or are there any even better)? - --cipher aegis128-random --key-size 128 --integrity aead - --cipher aegis256-random --key-size 256 --integrity aead - --cipher aes-xts-plain64 --key-size 512 --integrity hmac-sha256 or maybe: - --cipher serpent-xts-plain64 --key-size 512 --integrity hmac-sha512 - --cipher aes-xts-plain64 --key-size 512 --integrity hmac-sha512 (512 instead of 256) Especially is AEGIS recommended? I mean MORUS was as well, and now it's broken. Not sure whether AEGIS256 is even in the kernel, seems I only have a module for AEGIS128 Or do e.g. the AEAD ones above also suffer from too small nonces (as e.g. https://gitlab.com/cryptsetup/cryptsetup/-/issues/637) implies)? And can I combine basically every HMAC (e.g. based on SHA256 or SHA512) with any cipher (e.g. AES or serpent)? What about HMAC with SHA3? My understanding was generally: - with a non-AEAD algorithm, plain64 shall always be used as IV mode (that is when XTS is used - obviously not with CBC) - with an AEAD algorithm, random shall always be used as IV mode - also it should make no sense to try to combine XTS with an AEAD Right? I think the keyslot algos were automatically aligned with the volume algos, so when I select serpent-xts-plain64, it should also use serpent for the keyslots, right? 3) Are there any issues with XTS? I've read through https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/ which generally criticises XTS quite a bit. But I mean apart from AEAD we have nothing better, or do we? It especially also recommends against using XTS with non-diskencryption (i.e. just my use case (b)), but I thought using integrity protection (with HMAC) would protect me from these issues? 4) When using integrity protection (either through AEAD or HMAC), how far does that go? I mean I'd expect that an attacker cannot re-shuffle an blocks (and obviously cannot craft any new ones either)... but I guess there is no protection (on the dm-crypt level) against replay attacks? 5) Only for my use-case (b) above, that is write-once read-many encrypted files, is it safe to use these: --integrity-no-journal => Since I fill the LUKS volume anyway just once with data, I shouldn't need a journal? --integrity-no-wipe => I'd expect I don't need the wipe since I anyway initialise the whole volume when I fill it. Or are there any security concerns with the above? Since in this use case I would have only one keyslot, and the header itself also never changes after written the first time, I obviously want the whole LUKS header to be as small as possible. Can I simply do: --offset 0 and it would still be as large as necessary? 6) OpenPGP encrypted key files AFAIU, even when I use a keyfile, it's content would still be run through the selected PBKDF to produce the actual key used to encrypt the VK, right? With cryptsetup having some nice PBKDFs, shouldn't one generally recommend against using OpenPGP encrypted keys? It's S2K algo runs pretty fast, even at the maximum configurable iterations. So there doesn't seem to be much sense in having e.g. a 512 Byte random file used as --key-file which is then fed through Argon2, when the key- file itself has much weaker protection. 7) Should one align --sector-size with the underlying storage device’s actual block size? I vaguely remember that XTS had some security restriction, that it's only safe with some 2^20 or so Bytes (or was it AES blocks?). Even if it would be just bytes, 4KiB would be still in the safe range though, I guess. Would a larger sector size have any effect on the security of integrity protection? Thanks a lot, Chris. _______________________________________________ dm-crypt mailing list -- dm-crypt@xxxxxxxx To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
