Padding implementation is not constant-time

[tarcieri]

This is a followup to #19, which was originally about the modular exponentiation implementation not being constant-time, and also became our general tracking issue for the subsequent Marvin Attack.

We've gone to great lengths in crypto-bigint to produce the closest thing we can to a constant-time implementation of modular exponentiation, and while we still need to e.g. verify that's truly the case via static analysis tooling, based on the latest analysis from the Marvin Toolkit it seems like the remaining sidechannels in our implementation are probably no longer coming from crypto-bigint, but are instead in this crate's implementation of RSA padding modes.

PKCS#1 v1.5 in particular notably has a long history of sidechannels going back to Bleichenbacher's original 1998 attack, and attacks like Marvin can be seen as an evolution of that attack.

This I-D contains guidance for implementing RSA in constant-time, including things like handling depadding errors using strategies like implicit rejection:

https://datatracker.ietf.org/doc/draft-irtf-cfrg-rsa-guidance/

[itsalfredakku]

Proposed Implementation: Implicit Rejection for PKCS#1 v1.5

I've been working on implementing implicit rejection as specified in IETF draft-irtf-cfrg-rsa-guidance to mitigate the Marvin timing attack on PKCS#1 v1.5 padding.

Implementation Approach

The key insight from the IETF draft is that instead of returning an error on invalid padding (which leaks timing information), we should return a deterministic synthetic message derived from the ciphertext using a PRF keyed by the private key.

New Trait: ImplicitRejectionDecryptor

/// Decrypt with implicit rejection to prevent Bleichenbacher/Marvin timing attacks.
#[cfg(feature = "implicit-rejection")]
pub trait ImplicitRejectionDecryptor {
    /// Decrypt the ciphertext with implicit rejection.
    /// This method **never fails** due to padding errors.
    fn decrypt_implicit_rejection(&self, ciphertext: &[u8], expected_len: usize) -> Result<Vec<u8>>;
}

PRF Design (following IETF draft Section 7.2)

// Key derivation from private key
key = HMAC-SHA256(d || p || q, "implicit rejection key")

// Synthetic message generation
synthetic = HMAC-SHA256(key, counter || "implicit rejection PKCS#1 v1.5 ciphertext" || ciphertext)

Constant-Time Unpadding

The pkcs1v15_encrypt_unpad_implicit_rejection function:

1. Always computes the synthetic message (constant time)
2. Validates padding in constant time using existing decrypt_inner
3. Uses ct_select to choose between real and synthetic message
4. Returns synthetic message if padding is invalid OR length doesn't match expected

Usage Example

use rsa::pkcs1v15::DecryptingKey;
use rsa::traits::ImplicitRejectionDecryptor;

let decrypting_key = DecryptingKey::new(private_key);

// For TLS premaster secret (48 bytes expected)
let plaintext = decrypting_key
    .decrypt_implicit_rejection(&ciphertext, 48)
    .unwrap();
// Never returns error for padding - returns synthetic data instead

Feature Flag

This is behind an implicit-rejection feature flag that pulls in hmac and sha2:

[features]
implicit-rejection = ["dep:hmac", "dep:sha2"]

Tests

I've added tests verifying:

• Valid ciphertext decrypts correctly
• Invalid ciphertext returns synthetic message (no error)
• Synthetic messages are deterministic (same ciphertext → same result)
• Different ciphertexts produce different synthetic messages
• Length mismatch returns synthetic message

Next Steps

1. Add RSA blinding to the implicit rejection path
2. Add IETF test vectors from Appendix B
3. Run Marvin toolkit to verify timing leakage is eliminated

Would love feedback on this approach before submitting a PR!

Ref: #627