Value of Public Exponent is longer than 5 bytes, Signature.isVerify will always return false. about conscrypt HOT 4 OPEN

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.

from conscrypt.

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.

from conscrypt.

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 #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. :-/

from conscrypt.

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.

from conscrypt.