RSA padding confusion attacks

Question

Server A produces signed messages on request. You can tell server A what type of RSA padding to use in the signature (either RSASSA-PKCS1v1_5 or RSASSA-PSS). Either way, the message will be signed using the same private key. The signed message is a JSON object where you can supply some of the fields, but the server supplies the others.

Server B accepts these signed messages and verifies the signature using server A's public key. You have the ability to select which padding scheme that server B should use to perform the verification (again, either RSASSA-PKCS1v1_5 or RSASSA-PSS).

Is it possible to abuse the ability to switch between padding schemes in order to tamper with the message? Is it possible to cause server B to misread fields in the JSON object that were supposed to be supplied by server A?

Answer 1

The security proof of RSASSA-PSS assumes that the private key is used only for RSASSA-PSS purposes, that hypothesis is violated, thus the security proof does not hold (but as long as RSASSA-PKCS1v1_5 remains usable, you do not have a security proof anyway).

Similarly, the wide consensus that RSASSA-PKCS1v1_5 is secure in practice was formulated without taking into account the use of the same key for another purpose, so you are left without a wide consensus.

That said, some deployed systems use the same RSA key for different purposes, and I know no example of ensuing disaster as long as the padding schemes are very different, and each is secure (an example is the European Digital Tachograph, which uses the same RSA key for RSASSA-PKCS1v1_5 signature, and a custom authentication and key agreement protocol using ISO/IEC 9796-2 (scheme 1) signature padding; it was rubber-stamped to ITSEC level E3, and no attack emerged). The situation is similar to using the same key for HMAC-MD5 and HMAC-SHA1: that's theoretically undesirable, but the only clear consequence is that the weaker of the two systems caps the security.

I find improbable that a feasible cryptographic attack exists based only on the option to tell A and B to use RSASSA-PKCS1v1_5 or RSASSA-PSS, because these padding schemes are different enough. What I find much more probable is that an exploitable bug creeps in the specification or implementation, and the increased complexity due to the option increases that risk.