Re: [dm-crypt] LUKS FAQ separate for LUKS1/LUKS2, or combined? Was: cryptsetup Yubikey challenge-response support

[Milan Broz <gmazyland@gmail.com>]

On 12/04/2020 15:00, Michael Kjörling wrote:
> On 12 Apr 2020 00:23 +0200, from arno@wagner.name (Arno Wagner):
>> @everybody: What are the preferences: Separate LUKS 2 FAQ or 
>> section in the existing FAQ? 
> 
> LUKS is LUKS. Most of the concepts are similar. Most of the problems
> LUKS (1 and 2) solve are similar.> 
> Yes, some _answers_ might well be different for LUKS 1 or LUKS 2. But
> the _questions_ should be mostly the same, and _why_ to do one thing
> or another should be similar. The only obvious exception to that which
> I can think of is where something is _possible_ in LUKS 2, but simply
> not possible in LUKS 1, _and_ that would be worthy of inclusion in a
> FAQ in the first place.

Yes, and in fact we designed LUKS2 to be compatible as possible
and it is described in LUKS2 doc, referenced from FAQ already).

So, there should be only one FAQ.
(And for upstream, I am not going to support any doc split in
released archive. That would be confusing to users. They should
not care about version, unless they use some new feature.)

What we need to do is to use only one FAQ copy (currently there is text
version in main repo and primary version in wiki git), the wiki version
is already in markdown format, so perhaps I can move it to the
main git repo and this allows easy contributions through merge requests.
(The same problem applies for README, it is confusing to have two versions.)

(Unfortunately Gitlab does not allow to open merge request to wiki pages,
so to be open to direct contributions, keeping it in main repo is simpler.)

> There's already parts in the FAQ that discuss dm-crypt, RAM,
> passphrases, erasing data, and so on; so there's ample precedent that
> the FAQ already covers more than LUKS (1) proper.

And some of these need update too, for example use of kernel keyring
makes all scripts that use key in mapping table obsolete.
(This is a dm-crypt feature, not LUKS2 one.)
 
> Therefore, in the name of consistency and ease of reading, I would
> suggest to keep it all in one document, _but_ clearly mark the parts
> that only apply to one or the other. (This could be whole Q/A tuples,
> or just a portion such as an example command line.) Also perhaps add
> something near the top for how to tell based on an existing container,
> ideally irrespective of how the distribution does things, whether a
> LUKS container is LUKS 1 or LUKS 2.

I do not think is so big problem.

LUKS2 format allows many optional features (authenticated encryption,
reencryption, token metadata store), but these should be in separate
chapter anyway.

The basic functionality is exactly the same as LUKS1, just it allows more
flexibility (more keyslot, other PBKDF etc).

Also, if you anyone think there missing anything in LUKS2 doc, please
be exact and report it.
GRUB2 just implemented LUKS2 support using that doc, so I think
it works as implementation doc.
(And the cryptography is exactly the same as in LUKS1, except Argon2 PBKDF.)

Milan