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

[Milan Broz <gmazyland@gmail.com>]

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.