Subject: [perpass] Possible attack on Diffie-Hellman key exchange

From: Mike Liebhold <[email-masked]>
Date: Tue, 26 May 2015 09:40:53 -0700

---------- Forwarded message ----------
From: *Rodney Van Meter* <[email-masked] <mailto:[email-masked]>>
Subject: possible attack on Diffie-Hellman key exchange

It seems some researchers have uncovered a way to *pre-compute* part of 
the function necessary for breaking D-H, in a way that depends *only* on 
the prime number used.  It’s a substantial amount of CPU time to do, but 
is within the range of plausible for someone like the NSA for 1024 bit 
keys.  The existing IKE RFC recommends (requires?) use of one of a small 
set of prime numbers defined at
https://tools.ietf.org/html/rfc5996#appendix-B and
https://tools.ietf.org/html/rfc3526

Blog post from Scott Aaronson:
http://www.scottaaronson.com/blog/?p=2293
Follow the links to the paper, too:
https://weakdh.org/imperfect-forward-secrecy.pdf
Their website has more information, and a test for whether your browser 
is vulnerable to the same attack:
https://weakdh.org/

Of course, the obvious answer is to just raise the key length and/or use 
your own prime numbers rather than the ones in the spec, but who knows 
what else waits to be discovered? This serves as something of a 
motivation for continued work on alternatives to D-H; not because we 
believe D-H is inherently busted, or even that we necessarily believe 
that quantum key distribution (QKD) has no vulnerabilities of its own, 
but simply to have alternatives available as research lurches forward.  
We are working on documenting (as an RFC) a method for using 
QKD-generated keys with IKE in place of D-H. Our I-D has expired, but 
working is continuing, and we are actually generalizing it to support 
other methods of creating keys, including one-time pads that are 
delivered via some out-of-band mechanism.
https://tools.ietf.org/id/draft-nagayama-ipsecme-ipsec-with-qkd-01.txt

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 May 2015 17:54:00 +0100

Hiya,

That's being discussed at length on the TLS list. I figure any
conclusions from there will percolate to IPsec etc in good time.
Is there another angle we ought be considering too or is that
probably ok?

Cheers,
S.

On 26/05/15 17:40, Mike Liebhold wrote:
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

---

From: Mike Liebhold <[email-masked]>
Date: Tue, 26 May 2015 10:13:46 -0700

(√) thanks.  I'm glad to learn the right people are on the case from TLS 
and IPsec perspectives - but who specifically will scope out new 
prospective architectures -across the stack - for "other methods of 
creating keys, including one-time pads that are delivered via some 
out-of-band mechanism."

Specifically, what are the new viable "out of band"  mechanisms, and how 
would  those  scale effectively.

  Is that still out of scope for perpass?

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 May 2015 18:48:44 +0100

Hiya,

> would  those  scale effectively.

Well, for key agreement (which is the scope here) we do have some
clear recommendations - prefer ECDH (soon with our newly selected
curves, now with NIST curves) and then DH 2048 or better. And after
that probably fall back to RSA key transport. The role (if any) for
site-specific integer DH primes is being discussed on the TLS list
including with the authors of the logjam paper. My guess is they may
want to revisit a bit of the phrasing of some of the recommendations
from the paper, so we'll see how that pans out.

For lower level crypto mechanism things, then CFRG is the right
place within the IETF/IRTF though they are currently busy with
finishing the new curves work so it'll likely be a while before
they have bandwidth for much more.

That said, I don't think CFRG is a good place to invent new crypto
but rather it's a good place to figure out which of the already peer
reviewed academic cryptography work we want to take into standards,
and how, at the bit fiddling level. CFRG ought be doing the selection
(which requires real knowledge of the state of the art) and defining
the bit fiddling (where IETFers can help) but not the basic inventing
of algorithms or similar.

For that last, CHES and the crypto conferences or are really better
venues as would be any IACR journal or equivalent. Algorithm work
really is better started in a peer-reviewed academic context and not
dealt with on our mailing lists. (This thread [1] is a fine example
of why it's a bad idea to try invent stuff on our mailing lists;-)

    [1] https://www.ietf.org/mail-archive/web/cfrg/current/msg06790.html

>  Is that still out of scope for perpass?

Hope the above helps - the main idea of this list is to find the
right place for stuff, so asking "where" and getting views on that is
entirely correct. (And more are welcome.)

S.