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 dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
