Hi James, Thanks for pointing it out.
2014-02-25 16:48 GMT-08:00 Manger, James <[email protected]>: > > Having implementations verify that RSA key lengths are powers of two > > seems like it could be one mitigation. > > I don't think so. There are 1536-bit keys (just as historically there were > 768-bit keys). I'm sure some will pick 3072-bit keys. > Also, many supposedly 2048-bit keys are actually 2047-bit keys (still a > product of two 1024-bit primes). Reject those and you will break things. > > ANSI X9.31 requires the key length to be the multiple of 256 bit, does it not? In which case, is not 2047-bit keys rejected? Also, I was wondering if requiring exponent to be selected from small set of candidates or even just requiring one would help. i.e., either e={3, 5, 17, 257, 65537} or e=65537. Some specs requires e>=65537 so just requiring e=65537 is not unreasonable, I think. Also, there is a study [1] that over 95% of the e value used is 65537. Adding the fact that Windows' CAPI only accepts 65537 as e in key generation makes me think that most if not all libraries will accept 65537 as an input value for signature verification that in this particular case of self-issued provider, it would not hart to mandate that e be 65537. Do not you think it would help in the case of RSA? [1] https://eprint.iacr.org/2012/064.pdf -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
