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)? 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.) ... > Last thing I don't understand: > Why - despite of using e.g. MORUS - does it still give me aes-xts- > plain64 in the keyslot?: I think described it somewhere, but apparently not in manual: We cannot use AEAD mode for keyslots (no problem, because it is authenticated through the digest already). In this case it fallbacks to default algorithm (aes-xts). There will be options to change encryption per-keyslot (format allows it), but again it is not yet implemented (but it still have to be a length-preserving mode, not AEAD). Milan p.s. I wish we have more time to fix these issues much quicker. It is not my ignorance :) _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
