[prev in list] [next in list] [prev in thread] [next in thread]
List: cfrg
Subject: Re: [Cfrg] Postquantum cryptography in IETF protocols
From: William Whyte <wwhyte () onboardsecurity ! com>
Date: 2017-03-14 19:34:56
Message-ID: CAND9ES30xXz3zhGAsU4aED=fH0QWDD0TYc1QGM_n9a4fxCDt-g () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I should note that Security Innovation, which owns the patents for NTRU and
which I work for, has announced an intent to make the NTRUEncrypt IP public
domain. A formal announcement should follow shortly.
Cheers,
William
On Tue, Mar 14, 2017 at 1:31 PM, Tams, Benjamin <Benjamin.Tams@secunet.com>
wrote:
> Hi John,
>
> > Good that CFRG starts some more detailed discussion on PQC. It makes
> sense
> > to support post-quantum key exchange for use cases that need long-term
> > confidentiality (15 years). For other use cases I think it can wait until
> > PQC key exchange algorithms has been thoroughly evaluated and
> > standardized. If implemented now, it should be used in addition to ECDHE,
> > just like Google has done with their experimental New Hope
> implementation.
>
> I absolutely agree with your view on the subject. Especially for those use
> cases where the attack scenario "collect today, decrypt tomorrow" is a
> threat,
> we should start thinking of PQ-safe key exchange methods in time. Even if
> they eventually turn out to be insecure; we can now combine them with
> classical key exchange algorithms. We have nothing to lose.
>
> There is already IETF work addressing PQ-security in Internet protocols,
> e.g.
> IKE and an Internet Draft for a Quantum-Safe Hybrid Ciphersuite for TLS
>
> https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-03
> https://tools.ietf.org/html/draft-whyte-qsh-tls13-03
>
> On the other hand, there is (to my knowledge) no specification for a
> PQ-safe
> patent-free key exchange algorithm suitable for implementation. In fact, in
> https://tools.ietf.org/html/draft-whyte-qsh-tls13-03
> only NTRUEncrypt is specified but is subject to patents.
>
> A possible first step is that CFRG creates an Internet Draft. In fact,
> the algorithm New Hope has already been implemented as a plugin for
> strongSwan (IPSec implementation for the Linux kernel)
>
> https://github.com/strongswan/strongswan/tree/master/src/
> libstrongswan/plugins/newhope
>
> So why do we not start with a draft for which the above implementation can
> serve as a reference implementation?
>
> Kind regards,
> Benjamin
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>
[Attachment #5 (text/html)]
<div dir="ltr">I should note that Security Innovation, which owns the patents for \
NTRU and which I work for, has announced an intent to make the NTRUEncrypt IP public \
domain. A formal announcement should follow \
shortly.<div><br></div><div>Cheers,</div><div><br></div><div>William</div></div><div \
class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 14, 2017 at 1:31 PM, \
Tams, Benjamin <span dir="ltr"><<a href="mailto:Benjamin.Tams@secunet.com" \
target="_blank">Benjamin.Tams@secunet.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Hi John,<br> <br>
> Good that CFRG starts some more detailed discussion on PQC. It makes sense<br>
> to support post-quantum key exchange for use cases that need long-term<br>
> confidentiality (15 years). For other use cases I think it can wait until<br>
> PQC key exchange algorithms has been thoroughly evaluated and<br>
> standardized. If implemented now, it should be used in addition to ECDHE,<br>
> just like Google has done with their experimental New Hope implementation.<br>
<br>
I absolutely agree with your view on the subject. Especially for those use<br>
cases where the attack scenario "collect today, decrypt tomorrow" is a \
threat,<br> we should start thinking of PQ-safe key exchange methods in time. Even \
if<br> they eventually turn out to be insecure; we can now combine them with<br>
classical key exchange algorithms. We have nothing to lose.<br>
<br>
There is already IETF work addressing PQ-security in Internet protocols, e.g.<br>
IKE and an Internet Draft for a Quantum-Safe Hybrid Ciphersuite for TLS<br>
<br>
<a href="https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-03" rel="noreferrer" \
target="_blank">https://tools.ietf.org/html/<wbr>draft-fluhrer-qr-ikev2-03</a><br> <a \
href="https://tools.ietf.org/html/draft-whyte-qsh-tls13-03" rel="noreferrer" \
target="_blank">https://tools.ietf.org/html/<wbr>draft-whyte-qsh-tls13-03</a><br> \
<br> On the other hand, there is (to my knowledge) no specification for a PQ-safe<br>
patent-free key exchange algorithm suitable for implementation. In fact, in<br>
<a href="https://tools.ietf.org/html/draft-whyte-qsh-tls13-03" rel="noreferrer" \
target="_blank">https://tools.ietf.org/html/<wbr>draft-whyte-qsh-tls13-03</a><br> \
only NTRUEncrypt is specified but is subject to patents.<br> <br>
A possible first step is that CFRG creates an Internet Draft. In fact,<br>
the algorithm New Hope has already been implemented as a plugin for<br>
strongSwan (IPSec implementation for the Linux kernel)<br>
<br>
<a href="https://github.com/strongswan/strongswan/tree/master/src/libstrongswan/plugins/newhope" \
rel="noreferrer" target="_blank">https://github.com/strongswan/<wbr>strongswan/tree/master/src/<wbr>libstrongswan/plugins/newhope</a><br>
<br>
So why do we not start with a draft for which the above implementation can<br>
serve as a reference implementation?<br>
<br>
Kind regards,<br>
Benjamin<br>
<br>
<br>
______________________________<wbr>_________________<br>
Cfrg mailing list<br>
<a href="mailto:Cfrg@irtf.org">Cfrg@irtf.org</a><br>
<a href="https://www.irtf.org/mailman/listinfo/cfrg" rel="noreferrer" \
target="_blank">https://www.irtf.org/mailman/<wbr>listinfo/cfrg</a><br> \
</blockquote></div><br></div>
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic