On Thu, Feb 04, 2016 at 17:29:36 CET, Yves-Alexis Perez wrote: > On mer., 2016-02-03 at 15:17 +0100, Milan Broz wrote: > > Anyway, please give me few weeks, I expect the design discussion will happen here > > (I have a lot of to say why I am trying to do it this way.) > > I just prefer to discuss existing proof-of-concept code that theoretic discussions. > > > > For now, LUKS2 is experiment (partially proof-of-concept of some ideas > > of configurable keyslots, partially as testbed for my university work > > as implementing Argon 2 as PBKDF2 replacement etc). > > I know it's a recurring subject, and maybe it's more dm-crypt2 than LUKS2 or > something, but in that context, is there people working on authenticated > encryption and anti-replay? Maybe my crypto-knowledge deserts me here, but how is that relevant for storage encryption? If somebody can replay old storage blocks, they have already compromised your machine and can do what they want, unless you have an unsecured Network Block Device or iSCSI device. That would already be a problem on a different level. And authenticated encryption seems to not even apply to storage, unless you are thinking about integrity. If so, wrong project, as integrity always requires additional bits and LUKS/DM-cryopt does not have them bu design. Regards Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
