Re: some questions on dm-crypt/cryptsetup and LUKS2+integrity

Hey.

Better late than never... (I shall hope) ^^


On Tue, 2018-11-20 at 18:54 +0100, Milan Broz wrote:
> On 20/11/2018 18:07, Christoph Anton Mitterer wrote:
> > You've also noted that it seems to store bogus key-sizes?
> > Like when I did:
> > > cryptsetup --batch-mode --verbose --use-random --hash sha512 --
> > > pbkdf argon2id --cipher morus640-random --key-size 1024 --
> > > integrity aead --type luks2 luksFormat /dev/loop0 key
> > it gave:
> > > Keyslots:
> > >  0: luks2
> > >        Key:        1024 bits
> > but AFAIU, MORUS640 should always have 128, while for MORUS1280
> > it's
> > 256, right?
> 
> But if fails in the end, right (in the worst case on activation)?

Either I haven't checked this back then, or I just forgot the outcome.
But with cryptsetup 2.0.6 it fails as it should:
# cryptsetup --batch-mode --verbose --use-random --hash sha512 --pbkdf argon2id --cipher morus640-random --key-size 1024 --integrity aead --type luks2 luksFormat /dev/loop0 key
Cipher morus640-random (key size 1024 bits) is not available.
Command failed with code -1 (wrong or missing parameters).
# echo $?
1


> Actually it is the same problem - once we can check AEAD modes
> availability,
> it can fail early (key is just one attribute to check).
> For now it creates valid  LUKS2 with stored 1024bit key (it works,
> because it
> fallbacks to non-AEAD encryption for keyslot, see below) and just
> fails
> later. Yes, it is user unfriendly, I know...
> (Perhaps hardcoded values to check would be better here for now.)

I think in any case, if such a failure (invalid parameters) occurs an
unusable LUKS header should be created (in format, and unusable key
slots when adding keys, etc), maybe as a safety simply zeroing the
header (respectively the keyslots).

If cryptsetup (even though bailing out with an error) produces a
working (but because of fallback defaults possibly weaker) volume,... a
user may end up using it accidentally.


> I wish we have more time to fix these issues much quicker.
> It is not my ignorance :)

No worries… your efforts are greatly appreciated :-)



One further thing that came up on my questions list, with
LUKS2+integrity:

Is there a formula to calculate for a given size of the "opened" LUKS
device (i.e. the usable size as shown e.g. by blockdev --getsize64),
the required size for the underlying device?

Obviously it won't just be <desired data size>+<size of metadata area>,
as one has the integrity information in addition (which varies of
course with the size).


Thanks,
Chris.

_______________________________________________
dm-crypt mailing list
[email protected]
https://www.saout.de/mailman/listinfo/dm-crypt