[security] OIC self-issued mode is insecure

Nat Sakimura sakimura at gmail.com
Wed Feb 26 13:35:43 UTC 2014


Unfortunately, the errata process takes time. i.e., in our process, we need
45 days review period after the WG consensus and one week voting period, so
we are talking like the minimum of two months.

In the mean time, we need a minimum impact interim "work around" to
recommend.

Nat



2014-02-26 5:24 GMT-08:00 Manger, James <James.H.Manger at team.telstra.com>:

> Why are we discussing ad hoc crypto restrictions on n & e, instead of
> simply fixing an obviously flawed method of fingerprinting a key?
>
> --
> James Manger
>
> ----- Reply message -----
> From: "Nat Sakimura" <sakimura at gmail.com>
> Date: Wed, Feb 26, 2014 7:11 pm
> Subject: [security] OIC self-issued mode is insecure
> To: "Manger, James" <James.H.Manger at team.telstra.com>
> Cc: "Mike Jones" <Michael.Jones at microsoft.com>, "
> openid-security at lists.openid.net" <openid-security at lists.openid.net>
>
> Hi James,
>
> Thanks for pointing it out.
>
> 2014-02-25 16:48 GMT-08:00 Manger, James <James.H.Manger at team.telstra.com
> <mailto:James.H.Manger at team.telstra.com>>:
> > 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
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20140226/d35b4e1b/attachment.html>


More information about the security mailing list