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:
> 
> ---------- Forwarded message ----------
> From: *Rodney Van Meter* <[email protected] <mailto:[email protected]>>
> 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
> 
> 
> 
> 
> 
> _______________________________________________
> perpass mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/perpass
> 

_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass

Reply via email to