Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> writes:
> On Tue, Apr 20, 2021 at 01:41:18PM +0200, Varad Gautam wrote:
>>
>> +static int psspad_set_sig_params(struct crypto_akcipher *tfm,
>> + const void *sig,
>> + unsigned int siglen)
>> +{
>> + struct akcipher_instance *inst = akcipher_alg_instance(tfm);
>> + struct rsapad_inst_ctx *ictx = akcipher_instance_ctx(inst);
>> + const struct public_key_signature *s = sig;
>> +
>> + if (!sig)
>> + return -EINVAL;
>> +
>> + ictx->salt_len = s->salt_length;
>> + ictx->mgf_hash_algo = s->mgf_hash_algo;
>
> Is there any reason why this couldn't be embedded into the key
> instead?
>
Whilst is is correct that the same key can be used to verify either
types of signatures, it is best practice to use separate and new keys
in such situations. This prevents compromising key due to any
weaknesses in the one or the other signature types.
Thus imho it does make sense to embed sal_len & hash_algo into the key
instead, and thus only allow PSS signature verification with such a
key. This is common for x509 certs too as used in TLS. (at least this
is my understanding of all of this).
But this is a minor point which can fix now or later.
BTW, this patch series overall look very good to me and I want to use
PSS signatures in my kernel builds. What is the status of merging this
patch series?
Regards,
Dimitri.
