Re: [Cfrg] Security proofs v DH backdoors

One question is what a good standard would be?

PKCS #3 does not include the q in the parameters.
Implementations (e.g. DHParameterSpec in java) use this standard and hence
don't have this parameter either.
Without q it doesn't seem just tricky to verify general DH public keys, it
kind of seems infeasible.

On Thu, Oct 27, 2016 at 12:51 PM, Hanno Böck <hanno@hboeck.de> wrote:

> On Thu, 27 Oct 2016 10:32:17 +0000
> Dan Brown <danibrown@blackberry.com> wrote:
>
> > For q=(p-1)/2, literally computing c^q for client public key is very
> > slow.
> >
> > Why not use a faster alternative, such as checking Legendre symbol
> > (c/p), use cofactor DH,‎ or use even private keys?
>
> This line of debate and all the recently released papers show one very
> concerning thing: We haven't learned how to use Diffie Hellman properly
> - although it's an algorithm at the end of its life.
>
> I think when I read the logjam paper I became aware of how tricky of an
> issue this is and how many things can go wrong with DH. It was also the
> time when I concluded that the best is probably to just move beyond DH.
>
> Sure, there is probably a way to use DH in a way that reflects all
> security concerns, is still reasonably performant etc. But why should
> we have this discussion when we already know DH is on its way out?
> Chrome already decided to disable it, others will follow.
> Is there a good reason to keep DH around? One I'm aware of is that some
> people think due to its larger size it's more resistant against
> quantum computers. But I have heard multiple people familiar with QC
> and pqcrypto that they don't buy that argument.
>
> I'm not arguing that ECC is simpler, but I'm arguing that we have
> solved a lot of these issues facing DH already in a better way for ECC:
> By simply not using random parameters which whoever decides, but by
> using one or two good curves that have all desired properties. We
> probably could do the same for DH, but we don't have to if DH is
> deprecated anyway.
>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: hanno@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>
>