LUKS2 auth.encryption - do not use MORUS cipher
Hi,
TL;DR
Please *do* *not* use any MORUS cipher and stick with only AEGIS128 (aegis128-random in cryptsetup options; do not use aegis128l and aegis256).
One of the reasons to have LUKS2 authenticated encryption marked as the experimental feature was lack of properly analyzed AEAD ciphers.
As part of the research, we implemented some CAESAR [1] crypto competition candidates in kernel (before the final portfolio was announced).
From the implemented variants, only AEGIS128 was selected as a CAESAR winner.
There are ongoing patches [2] that remove all ciphers that are not in the final portfolio from the kernel (and I fully support this decision [3]).
- the MORUS cipher (all variants) have serious problems [4], it is de-facto no longer secure
- other AEGIS variants (AEGIS256, AEGIS128L) are ok, but the consensus seems to be to support only one finalist variant (AEGIS128)
- the only supported (and accelerated) variant is AEGIS128
It means that all LUKS2 devices using these ciphers will be no longer supported once these patches reach upstream kernel.
Unfortunately, we cannot use the new reencryption feature to switch authenticated encryption ciphers yet (this will be partially possible in the future, though).
Thanks,
Milan
[1] https://competitions.cr.yp.to/caesar.html
[2] https://lore.kernel.org/linux-crypto/[email protected]/
[3] https://lore.kernel.org/linux-crypto/[email protected]/
[4] https://eprint.iacr.org/2019/172.pdf
Quoted 3 lines · Milan Broz
- other AEGIS variants (AEGIS256, AEGIS128L) are ok, but the consensus seems to be to support only one finalist variant (AEGIS128)
That's a bit surprising... shouldn't AEGIS256 have a higher security goal, according to the design paper? So why removing it?
Cheers,
Chris.
Quoted 7 lines · Christoph Anton Mitterer
Quoted 3 lines · Milan Broz
- other AEGIS variants (AEGIS256, AEGIS128L) are ok, but the consensus seems to be to support only one finalist variant (AEGIS128)
That's a bit surprising... shouldn't AEGIS256 have a higher security goal, according to the design paper? So why removing it?
Well, see the whole discussion on linux-crypto (or even you can reply there)... Yes, the proposed decision is quite weak at this point
(also note that is not yet in the cryptodev tree, so it is not final decision yet).
IMO the problem is that the winner will get more attraction (both from the implementation side as accelerations, but also some analysis). I think this will not happen with the variants.
I would probably prefer just one AEGIS variant, it is less confusing to the non-technical people.
Also, there is a limited group of people that can actually submit patches for the implementations, it is better to focus on maintaining fewer algorithms (but this is just my opinion).
I just want to send an early warning here :-)
Milan
Quoted 1 line · Milan Broz
Yes, the proposed decision is quite weak at this point
Well removing MORUS is of course absolutely fine...
Quoted 3 lines
IMO the problem is that the winner will get more attraction (both from the implementation side as accelerations, but also some analysis). I think this will not happen with the variants.
Haven't we had in the past some (non-real-world) "attacks" on AES which affects either only AES128 or 256?
It's as you've said in that one mail you've referenced... there's often more analysis on alogs which are actually used(usable) somewhere... which however also means, if implementations focus only on one single algorithm (arguably the two are the same alog, just different sizes) there is no fall back ready if anything should ever been suddenly found in that single algo.
Quoted 2 lines
I would probably prefer just one AEGIS variant, it is less confusing to the non-technical people.
Helping non-technical people is rather by providing good recommendations/defaults in the userland tools.
Quoted 1 line
I just want to send an early warning here :-)
Sure... thx for that :-)
Cheers,
Chris.
Quoted 9 lines · Christoph Anton Mitterer
Quoted 3 lines · Milan Broz
IMO the problem is that the winner will get more attraction (both from the implementation side as accelerations, but also some analysis). I think this will not happen with the variants.
Haven't we had in the past some (non-real-world) "attacks" on AES which affects either only AES128 or 256?
Quoted 7 lines
It's as you've said in that one mail you've referenced... there's often more analysis on alogs which are actually used(usable) somewhere... which however also means, if implementations focus only on one single algorithm (arguably the two are the same alog, just different sizes) there is no fall back ready if anything should ever been suddenly found in that single algo.
AEGIS128, AEGIS256, and AEGIS128L are all different algos, see:
https://lore.kernel.org/linux-crypto/CAEX_ruEDA9ZG+6aA_jTBSq-MM=pOrdxoJA2x0LPF3dkYk76kCQ@mail.gmail.com/
Jordan
Quoted 10 lines · Jordan Glover
Quoted 8 lines · Christoph Anton Mitterer
Quoted 3 lines · Milan Broz
IMO the problem is that the winner will get more attraction (both from the implementation side as accelerations, but also some analysis). I think this will not happen with the variants.
Haven't we had in the past some (non-real-world) "attacks" on AES which affects either only AES128 or 256?
We have seen some key-shortening that was a lot worse for AES-256 due to a worse key-schedule, but they have no real-world impact. If you know something I missed and there is something worse, I would appreciate a pointer.
Real world "absolute security" is somewhere around 80...100 bit of effective key lenght and that is against known-plaintext, i.e. the absolute easiest attack possible.
Regards,
Arno
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier