Open nonark opened 1 year ago
On the one hand, this is expected behaviour. BoringSSL rejects any RSA public key where e > 33 bits long. See the references in the relevant check for a good background on why. In general, large values of e add computational complexity without adding security, and I believe BoringSSL would have chosen a (slightly) lower limit[1] except 2^32+1 is in use for DNSSEC by some TLDs.
On the other hand, the results you are getting here are buggy. In the first example Signature.initVerify()
should have thrown InvalidKeyException
and in the second Cipher.init()
should have thrown it, so thanks for catching that!
[1] E.g. The Windows struct _RSAPUBKEY
only allows 32 bits for e, so that provides a good upper bound for anything that needs to interoperate with Windows.
Actually, thinking about it, the validity checks should probably go on the code paths which create public and private RSA keys either from KeySpec
value constructors as above or PKCS#8 / X.509 encodings.
Yeah the validity checks being delayed is a consequence of bad OpenSSL APIs. If you create them from the parser, BoringSSL will check such things eagerly. But if you create from individual components, it's a mess. In a lot of cases, you have to call RSA_check_key. Except that's particularly tricky for Conscrypt because by default, RSA_check_key won't tolerate keys with n and d, but not e.
The new APIs from https://github.com/google/conscrypt/pull/1133 resolve this mess. Actually, one of the side effects is that PR + new BoringSSLwill check validity at key creation rather than deferring to use. (Sorry I should have called that out but forgot to.) So that part is all set, for newer BoringSSL. For older BoringSSL, you almost could turn on the RSA_check_key codepath, but you'd have to deal with the n , d thing, so might be easier to just get everything to new BoringSSL. :-/
Actually, one of the side effects is that PR + new BoringSSL will check validity at key creation rather than deferring to use
Fab! We probably need some tests on the Conscrypt side (if only to validate the exception thrown), but I can take care of that.
Using Conscrypt Library Version
Descript
Signature.isVerify
will always return false.Sample Data
Sample Test Verify Result
Sample Code 1
Sample Code 2
Sample Code 2 Result