Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-hpke-02.txt

From: Nasrul Zikri <[email-masked]>
Date: Wed, 4 Dec 2019 01:16:37 +0000

Hello Richard,

Thanks for looking at my use-case. I have been working recently on a quick implementation of FFDH so I would be interested to see how this perform in HPKE. If I can test this first and then request code points later that is good enough. If you can find a way to re-use TLS cipher suite code points (like Stephen say) that is good also because this defines ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102), ffdhe6144(0x0103), ffdhe8192(0x0104), ffdhe_private_use(0x01FC..0x01FF).

I think there are improvements that can be made for generating custom group for better security and speed. Using custom group help defend against an powerful adversary who would put a lot of work into breaking a fixed group, so I disagree that they are "even worse idea", but I realise there will be difficulties in negotiate parameters for custom group so I don't want to delay your draft.

Tk,
Nasrul

________________________________
From: Richard Barnes <[email-masked]>
Sent: Thursday, November 28, 2019 04:02
To: Nasrul Zikri <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-hpke-02.txt

Hi Nasrul,

Thanks for taking a look at this draft.  Personally, I am disinclined to define FFDH schemes, unless there are other folks in the RG who think they would be useful.  That said, the registry policy on group IDs is Specification Required, so you can get code points if you have a specification; it doesn't have to be in this doc.  AFAIK, there should be no technical barrier to doing FFDH.

As far as custom parameters, I think the only reasonable way to accommodate them here would be to reserve some space in the registry for private, vendor-specific use.  But this seems like an even worse idea than FFDH, so again, I'm inclined to do nothing here.

If other folks are interested in these cases, please speak up.

--Richard

On Wed, Nov 20, 2019 at 1:32 AM Nasrul Zikri <[email-masked]<mailto:[email-masked]>> wrote:
On your draft of Hybrid Public Key Encryption.

The draft appears to be for any DH KEM, but I note, however that the
examples and test vectors it gives are only for the elliptic curves
P-256, Curve25519, P-521, Curve448.

Would it be possible to define the algorithm identifiers and test
vectors for some FFDH groups as well as the elliptic curve? Or is there
some important reason why only ECDH methods are suitable?

If FFDH groups are indeed correct for use in the draft, it would appear
that the table in section 8.1 could be extended to allocate identifiers
for at least the parameter ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144,
ffdhe8192 as stated in RFC 7919, and perhaps the MODP groups as stated
in RFC 3526 and RFC 5114.

I would also like there to be a way of specifying the use of a custom
finite field for when the use of a defined elliptic curve or finite
field is not enough. I realise that stating a method for transporting
the parameters {p,q,g} is outside the scope of this draft, but could a
value for custom groups or private use be stated in this table also?

Tk,
Nasrul

> Hey all,
>
> Happy IETF 106 deadline day!
>
> The authors feel that this version of HPKE is substantially complete.  All
> of the functional parts are there, as well as test vectors to facilitate
> interop.  And I think we've got some formal proofs on the way.  Please take
> a look and speak up if you see any gaps.
>
> Thanks,
> --Richard
>
> On Mon, Nov 4, 2019 at 3:47 PM <[email-masked]<mailto:[email-masked]>>; wrote:
>
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Crypto Forum RG of the IRTF.
> >
> >         Title           : Hybrid Public Key Encryption
> >         Authors         : Richard L. Barnes
> >                           Karthik Bhargavan
> >         Filename        : draft-irtf-cfrg-hpke-02.txt
> >         Pages           : 45
> >         Date            : 2019-11-04
> >
> > Abstract:
> >    This document describes a scheme for hybrid public-key encryption
> >    (HPKE).  This scheme provides authenticated public key encryption of
> >    arbitrary-sized plaintexts for a recipient public key.  HPKE works
> >    for any combination of an asymmetric key encapsulation mechanism
> >    (KEM), key derivation function (KDF), and authenticated encryption
> >    with additional data (AEAD) encryption function..  We provide
> >    instantiations of the scheme using widely-used and efficient
> >    primitives.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-irtf-cfrg-hpke-02
> > https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-02
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-hpke-02
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission
> > until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > Cfrg mailing list
> > [email-masked]<mailto:[email-masked]>
> > https://www.irtf.org/mailman/listinfo/cfrg

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

---

From: Michael Scott <[email-masked]>
Date: Wed, 4 Dec 2019 11:29:53 +0000

Hello,

We have implemented an experimental version of HPKE, working from the
latest draft (in the C++ language only for now)

https://github.com/miracl/core

Our experimental API supports all 4 modes of operation, but currently only
for AES-GCM and the curves X25519 and P521.

Some feed-back: It would be a good idea to explicitly warn the reader that
the X25519/X448 keys are actually in little-endian format, whereas for
P256/521 they are big-endian.

The Npk sizes given for the KEMS for curves P256 and P521 appear to be for
a compressed form of the points. In the test vectors uncompressed public
keys are used.

The first test vector provided (for mode 3) appears out-of-order.

Other than that a well written and easy to follow draft.

Mike

On Wed, Dec 4, 2019 at 1:17 AM Nasrul Zikri <[email-masked]> wrote:

>
> Hello Richard,
>
> Thanks for looking at my use-case. I have been working recently on a quick
> implementation of FFDH so I would be interested to see how this perform in
> HPKE. If I can test this first and then request code points later that is
> good enough. If you can find a way to re-use TLS cipher suite code points
> (like Stephen say) that is good also because this defines
> ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102), ffdhe6144(0x0103),
> ffdhe8192(0x0104), ffdhe_private_use(0x01FC..0x01FF).
>
> I think there are improvements that can be made for generating custom
> group for better security and speed. Using custom group help defend against
> an powerful adversary who would put a lot of work into breaking a fixed
> group, so I disagree that they are "even worse idea", but I realise there
> will be difficulties in negotiate parameters for custom group so I don't
> want to delay your draft.
>
> Tk,
> Nasrul
>
>
> ------------------------------
> *From:* Richard Barnes <[email-masked]>
> *Sent:* Thursday, November 28, 2019 04:02
> *To:* Nasrul Zikri <[email-masked]>
> *Cc:* [email-masked] <[email-masked]>
> *Subject:* Re: [Cfrg] I-D Action: draft-irtf-cfrg-hpke-02.txt
>
> Hi Nasrul,
>
> Thanks for taking a look at this draft.  Personally, I am disinclined to
> define FFDH schemes, unless there are other folks in the RG who think they
> would be useful.  That said, the registry policy on group IDs is
> Specification Required, so you can get code points if you have a
> specification; it doesn't have to be in this doc..  AFAIK, there should be
> no technical barrier to doing FFDH.
>
> As far as custom parameters, I think the only reasonable way to
> accommodate them here would be to reserve some space in the registry for
> private, vendor-specific use.  But this seems like an even worse idea than
> FFDH, so again, I'm inclined to do nothing here.
>
> On Wed, Nov 20, 2019 at 1:32 AM Nasrul Zikri <[email-masked]>
> wrote:
>
> > On Mon, Nov 4, 2019 at 3:47 PM <[email-masked]>; wrote:
> >
> > >
> > >    with additional data (AEAD) encryption function...  We provide
> > > until the htmlized version and diff are available at tools.ietf.org.
> > >
> > > [email-masked]
> [email-masked]
> [email-masked]

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 6 Dec 2019 19:11:01 -0800

> P256/521 they are big-endian.

I think the general idea is that X25519 and X448 APIs act on fixed-length
byte strings and you are not supposed to care about the internal structure
or encoding.  I'm not sure that giving advice of this nature in a document
that solely consumes the algorithms is helpful, with that in mind.

-Ben

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 7 Dec 2019 11:50:03 +0200

On Fri, Dec 06, 2019 at 07:11:01PM -0800, Benjamin Kaduk wrote:
> or encoding.  

Correct, from RFC7748:

"Although the functions work internally with integers, the inputs and
outputs are 32-byte strings (for X25519) or 56-byte strings (for X448)
and this specification defines their encoding."

-Ilari

---

From: Michael Scott <[email-masked]>
Date: Sat, 7 Dec 2019 10:21:59 +0000

> and this specification defines their encoding."

Interesting point: Are these drafts primarily blueprints for developers who
want to implement them, or user manuals for implementations (which may not
yet exist). In practise, for good or ill,  they are used as blueprints by
implementers (as highlighted just now by Watson Ladd in another thread),
and I would suggest that is part of their purpose. Why else provide test
vectors?

But I agree that over time as they become more established and standardised
they do become primarily user manuals for use with implementations which
can be assumed to be fully compliant. In which case friendly hints to
struggling developers would become redundant.

Mike

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 9 Dec 2019 20:30:24 +0000

Hiya,

> a compressed form of the points. In the test vectors uncompressed public

Yep, I'd suggest changing to use uncompressed form and
changing the Npk, Nenc sizes accordingly. (To 65 for p256
and 133 for p521 if I got it right.) Anyway, my code [1]
does that and it matches the test vectors. BTW, if we did
stick with the compressed form, then 33 would seem more
useful than 32 for p256/Npk, but sticking with uncompressed
is likely better as that's what TLS does, so maybe code
supporting uncompressed will be easier to find.

> Other than that a well written and easy to follow draft.

Not sure I'd agree with "easily" but I suspect your better
familiarity with the underlying crypto and your own miracl
code helped. FWIW though, even a relative ignoramus like me
thrashing about with OpenSSL managed to get it working:-)

Cheers,
S.

[1] https://github.com/sftcd/happykey