Re: [saag] Possible backdoor in RFC 5114

[Ben Laurie <[e-mail]>]

On 29 March 2017 at 22:52, Watson Ladd <[e-mail]> wrote:

> On Wed, Mar 29, 2017 at 12:26 PM, Ben Laurie <[e-mail]> wrote:
> > On 29 March 2017 at 18:17, Yoav Nir <[e-mail]> wrote:
> >>
> >> On 29 Mar 2017, at 11:50, Ben Laurie <[e-mail]> wrote:
> >>
> >>
> >>
> >> On 22 March 2017 at 18:20, Watson Ladd <[e-mail]> wrote:
> >>>
> >>>
> >>>
> >>> On Mar 22, 2017 8:15 AM, "Ben Laurie" <[e-mail]> wrote:
> >>>
> >>>
> >>>
> >>> On 7 October 2016 at 16:56, Yoav Nir <[e-mail]> wrote:
> >>>>
> >>>>
> >>>> > On 7 Oct 2016, at 16:59, Tero Kivinen <[e-mail]> wrote:
> >>>> >
> >>>> > Stephen Farrell writes:
> >>>> >>
> >>>> >> So I'm not seeing anyone so far argue to not
> >>>> >> deprecate these somehow.
> >>>> >>
> >>>> >> We could just make 5114 historic as Yoav suggests,
> >>>> >> or, if someone writes an I-D to explain why, we
> >>>> >> could obsolete 5114. (Such an I-D would presumably
> >>>> >> also say something about codepoints that point at
> >>>> >> 5114 from other registries.)
> >>>> >>
> >>>> >> Assuming nobody shows up saying these are in
> >>>> >> fact in widespread use I'd be supportive of us
> >>>> >> getting rid of cruft.
> >>>> >
> >>>> > I think the NIST ECP groups are quite widely supportd, and used.
> >>>> > RFC5114 includes both Nist ECP Groups (192, 224, 256, 384 and 521)
> and
> >>>> > 3 MODP groups.
> >>>> >
> >>>> > In IPsec, ECP groups are widely used, those MODP groups with
> subgroup
> >>>> > are not. On the other hand I think only those 192, 256 and 521 bit
> >>>> > groups are really used, and those are defined also in RFC5903 (which
> >>>> > obsoleted original 4753 which had serious bug in it).
> >>>>
> >>>>
> >>>> First, I think you meant 256, 384 and 521 bit, not the 192.
> >>>>
> >>>> Second, 5114 did not fix the bug in 4753. It just referenced 4753 for
> >>>> formatting. You know this better than I do, but I don’t think the IANA
> >>>> registry ever referenced 5114 for these ECP groups.
> >>>>
> >>>> So for the three useful groups in 5114 you didn’t need it (as 4753)
> >>>> already existed, and you don’t need it now, as 5903 exists. I don’t
> see
> >>>> anything standing in the way of moving to historic or obsoleting it.
> >>>
> >>>
> >>> Possibly I missed something here: why should we be any happier about
> 5903
> >>> than we are about 5114?
> >>>
> >>>
> >>> Can you prepare a backdoored elliptic curve that passes all acceptence
> >>> critera?
> >>
> >>
> >> No, but can the NSA?
> >>
> >>
> >> I don’t know, but we can speculate all day about what the NSA can or
> cannot
> >> do, including wandless magic or generally solving the DLP. We can only
> make
> >> decisions on the basis of what we know or can reasonably project.
> >
> > But isn't that the point of nothing up my sleeve numbers? Which 5903
> > doesn't use...
>
> Ben:
> Do you understand the difference between an attack that has been
> demonstrated to be possible, and one that we have no idea how to do?
>

Indeed I do.


>
> I'm forced to assume not from the contents of the thread. Futhermore,
> the alternative is to go to the MODP groups which do not have this
> backdoor possibility if you really think the NSA is a few decades
> ahead in number theory.
>

Hasn't it been repeatedly demonstrated that the NSA is ahead?

What I'm saying is why should we trust parameters generated by an opaque
process by someone who has been shown to misbehave in the generation of
such parameters? Particularly if there's a way to generate appropriate
parameters that is not opaque? Perhaps I'm missing something (but I am not
missing that we don't currently know how to exploit the opaque process, I
get that)?


>
> Sincerely,
> Watson Ladd
> >
> > _______________________________________________
> > saag mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/saag
>
>
>
> --
> "Man is born free, but everywhere he is in chains".
> --Rousseau.
>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
>