[dm-devel] dm-crypt IV generation (summary)

[Mike Snitzer]

On Fri, Mar 10 2017 at  8:44am -0500,
Ondrej Mosnacek <omosnace at redhat.com> wrote:

> Hi all,
> 
> I was tasked to post a summary the whole dm-crypt IV generation
> problem and all the suggested solutions along with their drawbacks, so
> here it goes...

Thanks for the summary.
...
 
> 2. Restrict the keycount parameter to allow only reasonable
> combinations and then move IV generators to crypto API.
>     In Loop-AES, the multi-key mode always uses exactly 64 keys and
> there is no reasonable scenario where someone would like to use
> keycount != 1 with other IV mode than LMK. Thus it might be acceptable
> to only work with multiple keys in LMK (and only allow keycount == 64
> for it) and work with just one key in all other modes (and only allow
> keycount == 1 for them). I.e., the cipher format would remain the
> same, just with more restricted values.
> 
>     Note that this would be basically a breaking change (the keycount
> parameter is documented [4], so there may be users somewhere that use
> it in some unusual combination...). Still, such combinations would
> have to be used explicitly, as they are never used with common
> LUKS/Loop-AES/TrueCrypt partitions (something like cryptsetup --type
> plain ... or dmsetup would have to be used directly).
> 
>     Applying this change would allow implementing the IV generators as
> simple crypto algorithms that honor the usual interface (without
> setkey hacks and passing of special structures via IV).
> 
>     ISSUES:
>         a) Backward incompatibility (see above).
>         b) Again need to somehow handle the new 'random' IV generator.

...
> 
> QUESTIONS:
> @Mike/dm-devel: Do you think it would be feasible to apply solution 2
> (thus introducing the small incompatibility)?

Of all the proposals I think 2 is the best.  But I'm not in a position
to _know_ how problematic such an incompatible change would be.  As such
I unfortunately would need to defer to Milan, Herbert and others to say
how risky such a change would be.  If the real-world risk is very
limited then I think it would enable the most effective solution (moving
the IV generators to crypto without carrying excess dm-crypt baggage).

The other part mentioned ("need to somehow handle the new 'random' IV
generator"): Milan or others, do you have ideas for this?  Presummably
that is a prereq to moving forward with restricting keycount.

Mike