lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 10 Aug 2021 11:46:49 -0700
From:   Eric Biggers <>
To:     Jarkko Sakkinen <>
Cc:     Ahmad Fatoum <>,
        "Theodore Y. Ts'o" <>,
        Jaegeuk Kim <>,,
        James Morris <>,
        "Serge E. Hallyn" <>,
        James Bottomley <>,
        Mimi Zohar <>,
        Sumit Garg <>,
        David Howells <>,,,,,,
Subject: Re: [PATCH v2] fscrypt: support trusted keys

On Tue, Aug 10, 2021 at 09:06:36PM +0300, Jarkko Sakkinen wrote:
> > > 
> > > I don't think this is right, or at least it does not follow the pattern
> > > in [*]. I.e. you should rather use trusted key to seal your fscrypt key.
> > 
> > What's the benefit of the extra layer of indirection over just using a "trusted"
> > key directly?  The use case for "encrypted" keys is not at all clear to me.
> Because it is more robust to be able to use small amount of trusted keys,
> which are not entirely software based.
> And since it's also a pattern on existing kernel features utilizing trusted
> keys, the pressure here to explain why break the pattern, should be on the
> side of the one who breaks it.

This is a new feature, so it's on the person proposing the feature to explain
why it's useful.  The purpose of "encrypted" keys is not at all clear, and the
documentation for them is heavily misleading.  E.g.:

    "user space sees, stores, and loads only encrypted blobs"
    (Not necessarily true, as I've explained previously.)

    "Encrypted keys do not depend on a trust source" ...  "The main disadvantage
    of encrypted keys is that if they are not rooted in a trusted key"
    (Not necessarily true, and in fact it seems they're only useful when they
    *do* depend on a trust source.  At least that's the use case that is being
    proposed here, IIUC.)

I do see a possible use for the layer of indirection that "encrypted" keys are,
which is that it would reduce the overhead of having lots of keys be directly
encrypted by the TPM/TEE/CAAM.  Is this the use case?  If so, it needs to be

- Eric

Powered by blists - more mailing lists