(√) 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?
On 5/26/15 9:54 AM, Stephen Farrell wrote:
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
