Re: [PATCH 06/11] crypto: check that LUKS PBKDF2 iterations count is non-zero

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Sep 06, 2022 at 10:26:35AM +0100, Richard W.M. Jones wrote:
> On Tue, Sep 06, 2022 at 09:41:42AM +0100, Daniel P. Berrangé wrote:
> > Both the master key and key slot passphrases are run through the PBKDF2
> > algorithm. The iterations count is expected to be generally very large
> > (many 10's or 100's of 1000s). It is hard to define a low level cutoff,
> > but we can certainly say that iterations count should be non-zero. A
> > zero count likely indicates an initialization mistake so reject it.
> > 
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> >  crypto/block-luks.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/crypto/block-luks.c b/crypto/block-luks.c
> > index e6ee8506b2..254490c256 100644
> > --- a/crypto/block-luks.c
> > +++ b/crypto/block-luks.c
> > @@ -579,6 +579,11 @@ qcrypto_block_luks_check_header(const QCryptoBlockLUKS *luks, Error **errp)
> >          return -1;
> >      }
> >  
> > +    if (luks->header.master_key_iterations == 0) {
> > +        error_setg(errp, "LUKS key iteration count is zero");
> > +        return -1;
> > +    }
> > +
> >      /* Check all keyslots for corruption  */
> >      for (i = 0 ; i < QCRYPTO_BLOCK_LUKS_NUM_KEY_SLOTS ; i++) {
> >  
> > @@ -602,6 +607,12 @@ qcrypto_block_luks_check_header(const QCryptoBlockLUKS *luks, Error **errp)
> >              return -1;
> >          }
> >  
> > +        if (slot1->active == QCRYPTO_BLOCK_LUKS_KEY_SLOT_ENABLED &&
> > +            slot1->iterations == 0) {
> > +            error_setg(errp, "Keyslot %zu iteration count is zero", i);
> > +            return -1;
> > +        }
> > +
> >          if (start1 < DIV_ROUND_UP(QCRYPTO_BLOCK_LUKS_KEY_SLOT_OFFSET,
> >                                    QCRYPTO_BLOCK_LUKS_SECTOR_SIZE)) {
> >              error_setg(errp,
> 
> Equivalent checks were missing in nbdkit - I've added them.
> 
> I wonder if there's a problem that a very large number here would
> cause long delays opening the device.  In general it's not very clear
> to me if the aim is to prevent malicious LUKS input, or if we're just
> trying to sanity check the device hasn't been corrupted or improperly
> prepared.  The test above is the latter, I think.

Yes, we're checking for corruption.

A large value of iterations will indeed make it slow to open
the device, but that is entirely the point of the iterations
parameter. It must be picked to be large enough to intentionally
make opening slow, in order to prevent brute force checking
many passwords. It is hard to claim that any specific value
is "too large", because the volume might have been created on
a machine whose CPU is way faster than the current machine,
and thus chose big iterations.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|