On Thu, Jan 07, 2021 at 08:49:52AM +0100, Stephan Mueller wrote: > > > -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 > > > > > > > > /* > > > @@ -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(). > > > - 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
