I'm not sure why we don't have a consensus on an idea proposed as RFC in September 2023.
Because there is not enough involvement outside of the Marvell team, I will keep a vague announce for the first item: cryptodev: Some changes may happen to manage RSA padding for virtio-crypto. The second item is applied verbatim, thanks. 31/07/2024 14:51, Thomas Monjalon: > 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.
