Subject: Re: [Cfrg] malicious DH base points [was Re: should the CFRG really strive for consensus?]

From: Christoph Anton Mitterer <[email-masked]>
Date: Thu, 01 Jan 2015 18:14:37 +0100

On Thu, 2015-01-01 at 13:39 +0100, Adam Back wrote: 
> Seems like on
> topic and to the point, not spam.
plus: it seems kinda dangerous to me, if certain topics are more or
less... well not forbidden, but at least "moderated to silence".

CFRG should be really open, even if this includes more wood and less
trees,... trust is very important and if people feel that some
topics/questions/concerns might have been suppressed, CFRG will have the
same problems as NIST.

Cheers,
Chris.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 01 Jan 2015 20:22:56 +0000

> topics/questions/concerns might have been suppressed, CFRG will have the

Maybe a little more explanation is warranted then. Dan's mail
accused someone of bad faith by saying that that person did
thing x "in the guise" of doing thing y. That is always
inappropriate no matter what provocation and no matter who
says it. By itself that is sufficient to call out the message
as inappropriate for any IETF or IRTF list. And that is why
I agree with the chairs on this.

For me, it's just about appropriate list behaviour that is
more likely to result in the RG making sound technical choices
in a useful time-frame and is nothing to do with silencing
anyone. Inappropriate list behaviour simply makes it much
harder to get done.

As I said before Dan is by no means the only one who's
strayed beyond what's acceptable on this topic by my
reading. But I hope the group put this behind us all and
move on to at least finish up the work on the 128 bit
work factor key agreement topic in the very near future.

>From my pov I think that work is 99% done and should be easy
to finish up, based on the assumption that there's no
remaining security difference, nor significant performance
difference and there is a reasonable amount of running
code for one set of options. It's that kind of discussion
and not who makes what point for what reason that is
important.

And once that is out of the way then moving on to signatures
and other work factors should be much easier.

So add my voice to those saying: let's just get that part
done now please and where there's no other basis on which
to distinguish, the running code should be fine to go
with.

S.

> 
> 
> Cheers,
> Chris.
> 
> 
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>

---

From: "D. J. Bernstein" <[email-masked]>
Date: 2 Jan 2015 18:33:10 -0000

Stephen Farrell writes:
> Dan's mail accused someone of bad faith by saying that that person did
> thing x "in the guise" of doing thing y.

No, "in the guise" does not imply or suggest bad faith. Consider, e.g.,
the purely positive quote

   Sometimes he needs to regard the troop with clinical dispassion -- in
   the guise of a Stanford professor who publishes papers on the
   dynamics of bovine tuberculosis transmission in the olive baboon,
   Papio anubis, in The Journal of Medical Primatology

from http://www.nytimes.com/books/01/04/01/reviews/010401.01nixont.html.

Might I gently suggest that we take this ridiculous side discussion off
list (as the chairs should have done in the first place---see RFC 3934)
and leave CFRG free for technical discussions?

---Dan

---

From: "Paterson, Kenny" <[email-masked]>
Date: Sat, 3 Jan 2015 17:28:46 +0000

Hi,

>less... well not forbidden, but at least "moderated to silence".

In general, I agree of course. But there was sufficient "mainstream"
activity going on on the list over the last few days that I wanted to try
to keep things a bit more focussed. T

And as Adam Langley and others have pointed out, no-one seriously believes
that the choice of base point has any security impact (a more refined
statement about this to which I can subscribe can be found at the bottom
of the safecurves page here: http://safecurves.cr.yp.to/rigid.html). Of
course, it does matter for other reasons, like compatibility with already
deployed code, but that's NOT what was being discussed in the thread.

>trees,

I think you mean "more trees, less wood". The metaphor is "not being able
to see the wood for the trees", the "wood" referring to the whole
collection of trees, that is, the bigger picture. Anyway... what we want
here is lots of trees AND wood, but the right amounts and types of the two
different things at the right times. My message was about trying to keep
the balance right.

>... trust is very important and if people feel that some

Agreed. If you or anyone else reviews the list and comes to think that a
topic is important at the current time AND has received insufficient
attention on the list to date, then they are of course at liberty to post
on it. Even more so if they think something important is being
"suppressed".

Cheers,

Kenny

---

From: Adam Back <[email-masked]>
Date: Sat, 3 Jan 2015 21:48:13 +0100

On 3 January 2015 at 18:28, Paterson, Kenny <[email-masked]> wrote:
> And as Adam Langley and others have pointed out, no-one seriously
> believes that the choice of base point has any security impact (a more
> refined statement about this to which I can subscribe can be found at the
> bottom of the safecurves page here:

Nevertheless I think it should be part of the NUMS generation.

Apart from the academic paper which hypothesises a combined weakness
between the generator and the KDF for key-exchange (which again, is
NOT off-topic), there are situations where you need pairs of
generators which no one knows the discrete log of (for example like
EC_DBRG, a backdooring topic known to all; or u-prove/Brands
representation problem a DL/ECDL schnorr-extension attribute
certificate, which has multiple bases, probably there are other
examples)

If those are mixed with the main base point which is chosen using
unexplained randomness, then it maybe that even if we use G (the main
and non-NUMS base) plus H which given its intended to demonstrate lack
of knowledge wrt to H, would be generated with NUMS, that still fails
because maybe the person who generated G chose it such that it is the
discrete log of H (or vice-versa -- its the same thing).

I dont see what motive we can have for not NUMS the G parameter to for
the avoidance of doubt - its not as if there's a big cost to that.

Adam

---

From: Watson Ladd <[email-masked]>
Date: Sat, 3 Jan 2015 17:24:34 -0500

> the avoidance of doubt - its not as if there's a big cost to that.

9 is the minimal x coordinate that gives a prime order point on the
Montgomery model of Curve25519. I just checked this a moment ago with
PARI, so there is no reason to view the NUMS generator as more rigid.

As for the two-generator protocols, I agree there are issues with how
one would generate two generators. But I've not heard serious
objections to using a hash function: it's the way that Certicom for
instance, generated challenges for finding discrete logs, or the way
that one would close the Dual_EC backdoor. It's true that the attack
you mentioned is possible if we simply pick a generator, and then try
to generate another point.

Sincerely,
Watson

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Adam Back <[email-masked]>
Date: Sat, 3 Jan 2015 23:52:23 +0100

It can be possible to know the discrete log of 9 wrt H(9), if you
chose the curve to make it so.

You are assuming there is insufficient wriggle room in the rest of the
design to make this so, which is a weaker assumption.

Adam