Splitting up crate to reduce advisory blast radius?

[ctz]

As someone who wants to do what I think are reasonable and defensible uses of RSA (that is: RSASSA-PSS and RSASSA-PKCS1-v1_5) it would be great if there was a crate for that. But without bringing along the inevitable, infinite future security advisories for a crate that includes raw RSA, RSAES-PKCS1-v1_5, etc.

I think that could be done along protocol lines (eg, "rsa-signing" and "rsa-hazmat" crates?) or in an opinionated way (eg, "rsa-ok", "rsa-hazmat" crates?). The existing "rsa" crate could just reexport everything from these, perhaps?

[tarcieri]

FWIW, the Marvin Attack enables signature forgeries with RSASSA-PKCS#1v1.5 (i.e. BB'06-style)

The recent advisory affects all private key operations and allows a network attacker to recover either decryption or signing keys. Making modpow constant time (#394) will prevent key recovery but we still won't have fully mitigated the Marvin Attack which will still allow for both PKCS#1v1.5 decryption and signature forgeries by a network attacker observing timing information.

Constant-time modpow should enable safe use of OAEP or PSS, however.

We will continue to look into what can be done for PKCS#1v1.5 (e.g. moving to a pseudorandom rejection symbol for padding failures), however this is merely the latest in a long line of attacks which points to it being fundamentally flawed (see also The 9 Lives of Bleichenbacher's CAT).

(FWIW, this attack impacted many RSA libraries, many of which like the rsa crate are still vulnerable or have only partially mitigated it)

[ctz]

As far as I understood, this was fundamentally still an attack against PKCS#1 decryption. If you don't allow RSA decryption with your key, things are OK. But if you do, the attacker can use the side channel to do arbitrary computations (that includes signature forgeries, decrypting OAEP, etc.)

Is there an additional vulnerability that blinded, RSASSA-PKCS#1 signing also leaks private key data in the timing side channel in this crate?

edit: I've now read the whole of #19 and understand a bit more.

[tarcieri]

Yeah, due to #19 there's timing variability from signature operations which can leak the private key

[tomato42]

FWIW, the Marvin Attack enables signature forgeries with RSASSA-PKCS#1v1.5 (i.e. BB'06-style)

As far as I understood, this was fundamentally still an attack against PKCS#1 decryption.

To be precise: Marvin Attack is a Chosen Ciphertext Attack, as such, in it I've attacked RSA decryption operations only. But depending on where the leak happens, the attack may be applicable to all RSA decryption paddings (RSASVE (effectively raw RSA) as defined in NIST SP 800-56Br2, RSAES-PKCS-v1_5, and RSAES-OAEP, as defined in rfc8017), or if the leak happens in de-padding then only the specific RSAES-PKCS-v1_5 or RSAES-OAEP operation may be affected.

Having said that. If the leak happens in numerical library (like in case of RustCrypto RSA crate), and the signing operation doesn't apply recommended protections (base blinding and exponent blinding, see draft-kario-rsa-guidance for details), then the presence of an attack on RSA decryption suggests that RSA signing may be similarly affected.

Just to be painfully clear: I have not shown that RSA signing is vulnerable, but it's a valid conclusion to draw from the results of the test performed over the decryption operation.

And if the modular exponentiation operation leaks, then all operations with the private key will be affected, irrespective of operation or padding used. So, RSASSA-PKCS1-v1_5, RSASSA-PSS, RSAES-PKCS1-v1_5, and RSAES-OAEP will be affected.

If the modular exponentiation operation is side-channel free, then RSASSA-PKCS1-v1_5, RSASSA-PSS will be safe to use. If, in addition to that, the depadding operation is side-channel free, than RSAES-OAEP will be safe to use.

Technically it is possible to implement RSAES-PKCS1-v1_5 in side-channel free manner, but on top of the above requirements it requires either:

1. very specific API design that provides it and safe use of it on the calling application side
2. implementation of the implicit rejection mechanism (a.k.a. Marvin workaround) in the RSAES-PKCS1-v1_5 API

(It should be noted though, that the Marvin workaround can be implemented only with access to the private key, as such, if the private key is stored in a smart-card or in a Hardware Security Module, the issues of bad API design and requirement of safe handling of decryption result (point 1.) return, and can't be workarounded)

[tarcieri]

Going to close this as splitting up the crate would not help for at least this specific incident