Subject: [Cfrg] KEX from the ring-LWE Problem: draft-khera-lpr-ring-lwe-kex-00

From: Rohit Khera <[email-masked]>
Date: Tue, 24 Oct 2017 17:42:03 -0700

Dear Members of the CFRG,

I have started a draft to outline a key exchange method based on the
ring-LWE (RLWE) assumption. Recent years have seen implementations of key
exchange methods based on this problem.

The basis for such implementations (and for the method detailed in this
draft) is chiefly the foundational work of Ajtai, Micciancio, Regev,
Lyubashevsky and Peikert on reductions from worst case problems on
lattices, to the average case hardness of certain problems (including
certain learning problems).

I am not aware of any efforts within the IRTF, and the CFRG in particular,
that are focused on the more recent lattice based schemes, and request the
CFRG to consider adoption of this draft, which is available here:
https://datatracker.ietf.org/doc/draft-khera-lpr-ring-lwe-ke
x/?include_text=1

As you read through the draft, you will notice that some areas around
specifying TLS extensions for hybrid RLWE cipher suites are a work in
progress.

Thanks for considering this draft, and I look forward to your feedback!

Regards,
Rohit

---

From: Watson Ladd <[email-masked]>
Date: Tue, 24 Oct 2017 17:48:35 -0700

Why don't we wait for the NIST process?

On Tue, Oct 24, 2017 at 5:42 PM, Rohit Khera <[email-masked]> wrote:

> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>
>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 25 Oct 2017 09:30:22 +0300

> specifying TLS extensions for hybrid RLWE cipher suites are a work in

Some comments about the TLS stuff:

- I expect that at least initially, post-quantum key exchange will be
  deployed in hybrids with ECC.
- TLS 1.3 support is needed (as pseudogroup(s) encopassing hybrid key
  exchange). In fact, I consider such support higher priority than
  support for TLS 1.2.
- Allowing mixing and matching different parameters seems dubious to me.
  I expect there to be predefined parameter sets. Such mixing and 
  matching does not work well in TLS 1.3 anyway.
- With TLS 1.2, one easily runs into protocol bugs. For example, the
  TLS 1.2 signing process is flawed, allowing attacks _between_ key
  exchange types. Analyzing these interactions is not trivial. There
  is no fix in TLS 1.2. Furthermore, the key derivation is also
  screwed, requiring very strong properties from key exchange for
  security. This is fixed by Extended Master Secret.
- I expect there to be Chacha20-Poly1305 ciphersuites as well.

-Ilari

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 25 Oct 2017 08:24:21 +0000

This question has been discussed on the list several times.

It is the settled opinion of the CFRG chairs that we should wait for the
NIST process. 

Our approach can be revisited, but only if a significant number of people
come forward with good arguments for why we should do so.

Regards,

Kenny (for the chairs)

On 25/10/2017 01:48, "Cfrg on behalf of Watson Ladd"
<[email-masked] on behalf of [email-masked]> wrote:

>lattices, to the average
> case hardness of certain problems (including certain learning problems).
> 
>
>
>I am not aware of any efforts within the IRTF, and the CFRG in
>particular, that are focused on the more recent lattice based schemes,
>and request the CFRG to consider adoption of this draft, which is
>available here:
>
>
>https://datatracker.ietf.org/doc/draft-khera-lpr-ring-lwe-kex/?include_tex
>t=1
>
>
>