Hey.
I'm using cryptsetup since nearly the beginngin and now I'd like to
sooner or later switch to LUKS2 and integrity protection.
I'd have some questions... maybe you can help :-)
1) Is there any current known bug in LUKS2 / AEAD of cryptsetup/dm-
crypt/dm-integrity?
I read about the limitations of the GCM mode with the small nonces
(more on that below)... but apart from that... even though it's still
experimental... do you think I can use it and be safe (in terms of the
crypto)?
2) I was reading through the release notes and parts of them kinda were
written as if MAC-then-Encrypt would be done wich has all kinds of
security issues as we know from TLS... Is this correct or does it use
Encrypt-Then-MAC?
3) --sector-size
Does this also change the crypto block size? I vaguely think to
remember that some loooooong time ago when XTS was introduced, someone
said it wouldn't be safe to use with block sizes >512?
Or does this just set how many 512bit crypto blocks are written/read at
once to the underlying device?
4) --integrity-no-journal
Manpage says it would be safe to use if journaling is done on a
different layer.
I assume this could be layers above OR below dm-crypt?
So what about e.g ext* filesystems with journaling or btrfs with CoW
enabled... are these safe to use without a dm-integrity journal?
Has the answer to this question been coordinated with the respective
filesystem developers?
5) integritysetup options not provided in cryptsetup
integritysetup has a number of options not provided in cryptsetup,
e.g.:
--journal-size, --interleave-sectors, --journal-watermark, --journal-
commit-time, --tag-size, --journal-*
How does cryptsetup choose these values?
6) v2.0.0-ReleaseNotes.gz side node
These release notes say:
FDE authenticated encryption is not a replacement for filesystem
layer
authenticated encryption. The goal is to provide at least something
because
data integrity protection is often completely ignored in today
systems.
Does the note that FDE AE is not a repleacement for fs lvl AE really
just refer to the "authentication/integrity protection part"?
Or does it also refer to the encrpytion part... cause I've always
assumed block layer disk encryption would be rather saver than just
plain filesystem level encryption (like there is e.g. for ext).
Do I loose anything in terms of encryption security when I use the AE
as well? I mean it's ok if the integrity protection is not perfect,...
but I wouldn't want to loose anything in the encryption security
compared to what we have now.
7) Are we going to see SHA3 anytime soon in dm-crypt/cryptsetup? E.g.
for HMAC in integritry... or for --hash?
8) Something more important for me:
a) Which algos are already safe to use for encryption/integrity?
In the release notes you basically list these three:
* aes-xts-plain64 with hmac-sha256 or hmac-sha512 as the
authentication tag.
* aes-gcm-random (native AEAD mode)
DO NOT USE in production! The GCM mode uses only 96-bit nonce,
* ChaCha20 with Poly1305 authenticator (according to RFC7539)
But in another place it also says that Chacha20-poly1305 is affacted by
the small nonce:
NOTE: Currently available authenticated modes (GCM, Chacha20-
poly1305)
in kernel have too small 96-bit nonces that are problematic with
randomly generated IVs (the collison probability is not negligible).
For the GCM, nonce collision is a fatal problem.
b) So is only aes-xts-plain64 / with hmac-sha* safe to use? Or is even
that safe to use at all?
c) Can I also use serpent-xts-plain64 / hmac-sha512 and will that be
safe?
d) Which key sizes (--key-size) would I need to use?
For aes-xts-plain64 I always used --key-size 512, which I think results
in AES256, right? With 256 bit for AES and the other 256 for XTS?
But for AEAD with HMAC I'd need another key, right? What's --key-size
then? Or is it still 512 and crypsetup selects they auth key based on
the auth-algo?
And how would one need to set it for SERPENT?
e) Is there anything better in the meantime than:
[aes|serpent]-xts-plain64
and
hmac-sha512
?
9) Authenticated encryption do not set encryption for dm-integrity
journal.
Just wondered why this isn't a security problem? Isn't all data written
to the journal... and if this isn't encrypted...?
10) We plan to use AEGIS and MORUS, as CAESAR finalists.
Are these then safer than aes-xts-plain64 / hmac-*?
I stumbled over a paper which shows that these algos fail pretty bad if
a nonce is reused:
https://eprint.iacr.org/2017/1137.pdf
11) The persistent settings stored with --persistent...
Are these encrypted/integrity protected? Otherwise an attack could
trick a user into e.g. using TRIM even though he doesn't because of
security concerns.
Last but not least:
12) Next to normal disk encryption (and in the future integrity
protection) like on a laptop,... I'd like to "abuse" cryptsetup/dm-
crypt for now to encrypt plain files, i.e. very large (~20GiB) dar
files that are backups of all my personal data and which I want to
write to tape.
Since this will be long term archival,... I'd like to
- triple encrypt with different algos (AES, SERPENT, <something else>)
- use a recent password hashing algo (Argon2*)
GPG only supports AES (not SERPENT) and none of the other newer algos
like ChaCha20 is on the horizon... same for password hashing, where
OpenPGP has it's own s2k algo, which is however even with the highest
possible iteration count pretty fast. Same here... nothing on the
horizon that gpg/openpgp will support anything better.
So my idea was basically to do three layers of encryption:
plain data -> dm-crypt/luks2 [serpent-xts-plain64 + hmac-sha256] ->
-> dm-crypt/luks2 [some algo, chacha20+poly if it would be save] -> gpg
[AES256 + signature]
For cryptsetup I'd simply create image files of the right sizes, so
that the previous layer fits in perfectly (i.e. not trailing unused
bytes on the dm-crypt "device").
I'd use Argon2id, which seems the safest.
a) Do you see (apart from the crazy overkill ;-) ) any apparent mistake
or something that could be made better / more secure)?
Since I will get anyway regular files in the end (i.e. an image file
containing dm-crypt/LUKS encrypted other such LUKS container files)...
b) ... I assume I can safely use --integrity-no-journal (either I
finish writing the file or I just start over again, so a crash doesn't
bother me here).
c) ... I assume I can also safely use --integrity-no-wipe, as I will
anyway write the complete dm-crypt/integrity "device" which is just of
the size (in terms of the payload) of the regular file I want to
encrypt.
Thanks a lot,
Chris.
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt
