Hi, On 15/10/2018 17:11, Christoph Anton Mitterer wrote: >> 2) Use new native AEAD algorithms with 128bit nonces (in kernel 4.18 >> and later) >> (aegis128,aegis256,aegis128l,morus640,morus1280), for example >> >> "--cipher aegis128-random --key-size 128 --integrity aead" or >> "--cipher aegis256-random --key-size 256 --integrity aead" or > < "--cipher morus640-random --key-size 128 --integrity aead" ... > > 1) Should these work by now with the current cryptsetup? Or will one > require 2.1? These should work with 2.0.4 (most of it even with older releases). You just need kernel with modules enabled. > 2a) AFAIU, AEGIS will always have either key-sizes of 128 or 256 bit, > right? > I'm also assuming that larger key size will give a better security > margin,right? > But what's the 128L? It just another variant with internal state size of 1024 bits. This is table from Ondra's master thesis that focused on these dm-crypt AEAD extensions (https://is.muni.cz/th/qvh3t/) AEGIS-128L AEGIS-128 AEGIS-256 Input block size 256 bits 128 bits 128 bits Nonce size 128 bits 128 bits 256 bits Key size 128 bits 128 bits 256 bits Tag size 128 bits 128 bits 128 bits State size 1024 bits 640 bits 768 bits > 2b) And MORUS will have either 640 bit for the internal state with > "only" 128 bit keys... OR... the 1280 bit internal state with either > 128 or 256 bit keys, right? Yes, but see the link above, it is described there as well. > Again, I'm assuming that larger internal state and larger key size will > give a better security margin, right? It depends. It needs some time people really analyze these in detail. Larger internal state does not unconditionally imply better properties. > > 3) Is there any comparison (in terms of security) between AEGIS and > MORUS? I hope there will be more analysis as CAESAR crypto competition is nearing its end. My main intention for dm-crypt is just to show that we need to use AEAD (authenticated encryption) in future, and the best algorithm we had now is CAESAR candidates (and recently some SIV variants but someone need to implement them in kernel). I am not a theoretic crypto analyst but an engineer that tries to use that in real world. There is some risk in it, but someone should at least try :-) Seriously, it can happen that something will be broken in future or something better will appear. I would like to see much more active discussions between academic world and practitioners and more innovations here. (And innovation means also some fails. :) m. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
