On Thu, Jan 07, 2021 at 08:49:52AM +0100, Stephan Mueller wrote:

quoted

quoted

-int fscrypt_init_hkdf(struct fscrypt_hkdf *hkdf, const u8 *master_key,
+int fscrypt_init_hkdf(struct fscrypt_hkdf *hkdf, u8 *master_key,
                      unsigned int master_key_size);

It shouldn't be necessary to remove const here.

Unfortunately it is when adding the pointer to struct kvec

quoted

quoted

 
 /*

@@ -323,7 +323,7 @@ int fscrypt_init_hkdf(struct fscrypt_hkdf *hkdf, const

u8 *master_key,
 #define HKDF_CONTEXT_INODE_HASH_KEY    7 /* info=<empty>               */
 
 int fscrypt_hkdf_expand(const struct fscrypt_hkdf *hkdf, u8 context,
-                       const u8 *info, unsigned int infolen,
+                       u8 *info, unsigned int infolen,
                        u8 *okm, unsigned int okmlen);

Likewise.  In fact some callers rely on 'info' not being modified.

Same here.

If the HKDF API will have a quirk like this, it's better not to "leak" it into
the prototypes of these fscrypt functions.  Just add the needed casts in
fscrypt_init_hkdf() and fscrypt_hkdf_expand().

quoted

quoted

-       err = crypto_shash_setkey(hmac_tfm, prk, sizeof(prk));
+       err = crypto_hkdf_setkey(hmac_tfm, seed, ARRAY_SIZE(seed));
        if (err)
                goto err_free_tfm;

It's weird that the salt and key have to be passed in a kvec.
Why not just have normal function parameters like:

        int crypto_hkdf_setkey(struct crypto_shash *hmac_tfm,
                               const u8 *key, size_t keysize,
                               const u8 *salt, size_t saltsize);

I wanted to have an identical interface for all types of KDFs to allow turning
them into a template eventually. For example, SP800-108 KDFs only have one
parameter. Hence the use of a kvec.

But the API being provided is a library function specifically for HKDF.
So there's no need to make it conform to some other API.

- Eric