Hi Tadeusz,
>> +++ b/crypto/rsaprivatekey.asn1
>> @@ -0,0 +1,13 @@
>> +RSAPrivateKey ::= SEQUENCE {
>> + version Version,
>> + modulus INTEGER ({ rsa_get_n }), -- n
>> + publicExponent INTEGER ({ rsa_get_e }), -- e
>> + privateExponent INTEGER ({ rsa_get_d }), -- d
>> + prime1 INTEGER, -- p
>> + prime2 INTEGER, -- q
>> + exponent1 INTEGER, -- d mod (p-1)
>> + exponent2 INTEGER, -- d mod (q-1)
>> + coefficient INTEGER -- (inverse of q) mod p
>> +}
>> +
>> +Version ::= INTEGER
>
> If you want to do this you should also update the existing RSA test vectors,
> because
> they are failing after this patch is applied.
the test vectors have been failing no matter what. The crypto/rsakey.asn1 is
actually broken as I explained in previous emails. That the ASN.1 parser
accepted the test vectors was a bug which has been fixed now.
> The reason is that there is no version in the private keys in crypto/testmgr.h
> And the QAT RSA implementation should also be updated so they are consistent.
The QAT code should be updated indeed, but honestly I am still maintaining the
case that akcipher should just only operate on setkeyid with struct key / key
serial and some ASN.1 blob that we have to decode and recode all the time.
> I have already started to do the changes proposed for the akcipher api to add
> SGLs
> support and to split the set_key for set_publickey and set_privatekey so I
> will
> take care of this.
I am not in favor of just hacking in this split until the semantics are
actually understood. As said, the right solution from my point of view is to
remove setkey from akcipher and replace it with setkeyid instead.
Remember that a private key contains the public key as well. Meaning operations
are mutually exclusive. And there is really no point in forcing the caller to
split things into two. With asymmetric cryptography you either have private and
public key or you just have the public key. The case where you only have the
private key is pointless.
We could keep the setkey as it is to load the private + public key information
and add an extra setpubkey for loading only the public key. Then again a
setkeyid would solve both of these problems since the key material would be
nicely represented in a struct key.
However we actually want to load the keys into the asymmetric key type and use
it from there. The asymmetric key type should be the only entity that has to
deal with ASN.1 encoding. Having an akcipher deal with ASN.1 is just wrong.
What we really want is to be able to use keys from certificates to verify and
encrypt information. And we want this all in one single place and not duplicate
this whole ASN.1 stuff in the keys subsystem and the crypto subsystem. This
means I am strongly against trying to add setkey, setpubkey, setcert,
setkeychain or whatever else you might need when it comes to akcipher. There is
one thing that is needed and that is setkeyid and have to reference the key
serial from the keys subsystem.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
