30/07/2024 16:39, Gowrishankar Muthukrishnan: > Hi, > We need to fix padding info in DPDK as per VirtIO specification in order to > support RSA in virtio devices. VirtIO-crypto specification and DPDK > specification differs in the way padding is handled. > With current DPDK & virtio specification, it is impossible to support RSA in > virtio-crypto. If you think DPDK spec should not be modified, we will try to > amend the virtIO spec to match DPDK, but since we do not know if the virtIO > community would accept, can we merge the deprecation notice?
There is a long list of Cc but I see no support outside of Marvell. > >>> +* 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. > > > >>> +* 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.
