-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support OAEP decryption with modulus above 4096 #418
Comments
Which type of keys are you asking about?
PKCS#8 and SPKI are capped to 4096-bits, following recommendations from the X.509 ecosystem. Since these keys are potentially attacker-controlled they're a potential DoS vector if too large. See #166. |
Sorry, I'm in fact referring to PKCS#8 keys in this particular case. Again, as I said I'm well aware of the implication, that's why I was asking specifically for an opt-in solution, something you'd have to explicitly enable. Can this be done? |
You can parse the PKCS#8 key yourself using the Adding a dedicated feature for this would be rather tricky and seems generally questionable. Can I ask what use case you have for extremely large PKCS#8 keys? |
In this case it's for keys provided by third parties and we cannot change it. Regardless the problem does not occur when initializing the let key = RsaPrivateKey::from_pkcs8_encrypted_pem(my_pem, my_password)?;
let decrypted = key.decrypt(my_oaep_padding_instance, my_encrypted_payload)?; // this errors out with ModulusTooLarge In particular the error seems to come from This last one then calls if public_key.n().bits() > max_size {
return Err(Error::ModulusTooLarge);
} Additionally, the max_size value comes from The idea would be to have some sort of override for this functionality, so that we can use whatever we want as a max size, or even an exact expected size. |
Okay, I agree that's an edge case in OAEP decryption which should be allowed since it's a private key and not a potentially untrusted public key |
Any updates on this? Are you able to give me an ETA, or point me in a direction to propose a PR? |
You can open a PR which removes this restriction, yes |
As per #418, let me know if this is the preferred way or if you'd rather remove the limit some other way Co-authored-by: Gabriele Musco <[email protected]>
Riffing off of #210 I wanted to ask if it's possible to add some feature flag or some other opt-in solution to support keys with modulus size bigger than 4096.
I understand the concerns for algorithmic denial of service, but I think having an escape hatch for when you actually want to use this key size for various reasons would be useful, and in fact it's necessary for a particular need I have 😅
The text was updated successfully, but these errors were encountered: