Hi ArkadiuszX,

> +

> +* cryptodev: The struct rte_crypto_rsa_padding will be moved from

> +  rte_crypto_rsa_op_param struct to rte_crypto_rsa_xform struct,

> +  breaking ABI. The new location is recommended to comply with

> +  virtio-crypto specification. Applications and drivers using

> +  this struct will be updated.

> +



The problem here, I see is that there is one private key but multiple 
combinations of padding.

Therefore, for every padding variation, we need to copy the same private key 
anew, duplicating it in memory.

The only reason for me to keep a session-like struct in asymmetric crypto was 
exactly this.





Each padding scheme in RSA has its own pros and cons (in terms of 
implementations as well).

When we share the same private key for Sign (and its public key in case of 
Encryption) between

multiple crypto ops (varying by padding schemes among cops), a vulnerable 
attack against one scheme

could potentially open door to used private key in the session and hence take 
advantage

on other crypto operations.



I think, this could be one reason for why VirtIO spec mandates padding info as 
session parameter.

Hence, more than duplicating in memory, private and public keys are secured and 
in catastrophe,

only that session could be destroyed.



Please share your thoughts.



> +* cryptodev: The rte_crypto_rsa_xform struct member to hold private key

> +  in either exponent or quintuple format is changed from union to

> +struct

> +  data type. This change is to support ASN.1 syntax (RFC 3447 Appendix 
> A.1.2).

> +  This change will not break existing applications.

This one I agree. RFC 8017 obsoletes RFC 3447.



Thanks,

Gowrishankar



> --

> 2.21.0


Reply via email to