From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephan Mueller Date: Wed, 09 Jan 2019 06:27:28 +0000 Subject: Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler Message-Id: <3239276.QO2kezntxR@tauon.chronox.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit List-Id: References: <20190103143227.9138-1-jlee@suse.com> <1565399.7ulKdI1fm5@tauon.chronox.de> In-Reply-To: To: Andy Lutomirski Cc: Herbert Xu , "Lee, Chun-Yi" , "Rafael J . Wysocki" , Pavel Machek , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, keyrings@vger.kernel.org, "Rafael J. Wysocki" , Chen Yu , Oliver Neukum , Ryan Chen , David Howells , Giovanni Gherdovich , Randy Dunlap , Jann Horn , Andy Lutomirski Am Mittwoch, 9. Januar 2019, 00:54:22 CET schrieb Andy Lutomirski: Hi Andy, > > I think that, if the crypto API is going to grow a KDF facility, it should > be done right. Have a key type or flag or whatever that says “this key may > *only* be used to derive keys using such-and-such algorithm”, and have a > helper to derive a key. That helper should take some useful parameters and > mix them in: > > - What type of key is being derived? ECDSA signing key? HMAC key? AES > key? > > - Can user code access the derived key? > > - What is the key’s purpose? “Encrypt and authenticate a hibernation image” > would be a purpose. > > - Number of bytes. > > All of these parameters should be mixed in to the key derivation. > > Also, an AE key, even for AES+HMAC, should be just one derived key. If you > need 512 bits, ask for a 512-bit key, not two 256-bit keys. I concur with your requirements. However, is the kernel crypto API the right place to enforce such policies? To me, the kernel crypto API is a tinker-toy set of ciphers. The real policy enforcer would or should be the keyring facility. Thus, may I propose to: - implement the cryptographic primitive of the KDF in the kernel crypto API - implement the policy system how to use the KDF in the keyring facility Ciao Stephan From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephan Mueller Subject: Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler Date: Wed, 09 Jan 2019 07:27:28 +0100 Message-ID: <3239276.QO2kezntxR@tauon.chronox.de> References: <20190103143227.9138-1-jlee@suse.com> <1565399.7ulKdI1fm5@tauon.chronox.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Andy Lutomirski Cc: Herbert Xu , "Lee, Chun-Yi" , "Rafael J . Wysocki" , Pavel Machek , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, keyrings@vger.kernel.org, "Rafael J. Wysocki" , Chen Yu , Oliver Neukum , Ryan Chen , David Howells , Giovanni Gherdovich , Randy Dunlap , Jann Horn , Andy Lutomirski List-Id: linux-pm@vger.kernel.org Am Mittwoch, 9. Januar 2019, 00:54:22 CET schrieb Andy Lutomirski: Hi Andy, >=20 > I think that, if the crypto API is going to grow a KDF facility, it should > be done right. Have a key type or flag or whatever that says =E2=80=9Cthi= s key may > *only* be used to derive keys using such-and-such algorithm=E2=80=9D, and= have a > helper to derive a key. That helper should take some useful parameters a= nd > mix them in: >=20 > - What type of key is being derived? ECDSA signing key? HMAC key? AES > key? >=20 > - Can user code access the derived key? >=20 > - What is the key=E2=80=99s purpose? =E2=80=9CEncrypt and authenticate a= hibernation image=E2=80=9D > would be a purpose. >=20 > - Number of bytes. >=20 > All of these parameters should be mixed in to the key derivation. >=20 > Also, an AE key, even for AES+HMAC, should be just one derived key. If y= ou > need 512 bits, ask for a 512-bit key, not two 256-bit keys. I concur with your requirements. However, is the kernel crypto API the righ= t=20 place to enforce such policies? To me, the kernel crypto API is a tinker-to= y=20 set of ciphers. The real policy enforcer would or should be the keyring facility. Thus, may= I=20 propose to: =2D implement the cryptographic primitive of the KDF in the kernel crypto A= PI =2D implement the policy system how to use the KDF in the keyring facility Ciao Stephan