AEAD, recommended alogs and some more questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux