Re: [Cfrg] Adoption call for draft-barnes-cfrg-hpke

Hugo Krawczyk <> Wed, 22 May 2019 04:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B684120074 for <>; Tue, 21 May 2019 21:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 759AaSZYSXUR for <>; Tue, 21 May 2019 21:29:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DF3912002F for <>; Tue, 21 May 2019 21:29:21 -0700 (PDT)
Received: by with SMTP id g16so749343iom.9 for <>; Tue, 21 May 2019 21:29:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+tUH3I2cGELwHy7ziulHRgKp6ZDmySCpvbptE0TfeWg=; b=deD1tbFI0x/yp+HkO4hpGBGTtcxwKYBO1/Hc3CPZMB6d8F+XjPPKEBpHJUYVniRHV3 nxWy6howTH0BcNWaZS/tizvqOR2VQSyIKupYZiLBdah+r7WBFKRk/tZuO/Qe6ZZMi/zE AoDFpaacLguYqH3aM9tko/icoQD+frLeRAgYvVgqa5G3VBtBkk+z4jleMRc1On8Px7n1 Ui/KLv7h/pNgw54pQHfuLl3IKfh4oy0oj84D515mk33gtsxeKs0V3o7+LH01mTLOGuEg JlpnYebb4jgbRFB6tK6fZ1U5Ueeo59i82w5SGENkE7WXPZ0LD5KnQmDAd3JrVt29Uaa2 rZsw==
X-Gm-Message-State: APjAAAWmtDDdG/BnuBWAD4lN+RC4s5nwJEjDoT2oQj21Jo0jfow724ni 3U0V/GSEOimzVctonabTbDwm+U4z+ZK5TZstwJeS3Jer
X-Google-Smtp-Source: APXvYqxKQ3VEA6vkXNllDTOuab5xdLGGzGnhUQN95nRroIRUFszZoIMhAPZZ6nsKIlReNGyydMuAXNnvY+2wWpe7aTI=
X-Received: by 2002:a05:6602:228e:: with SMTP id d14mr18722565iod.172.1558499360570; Tue, 21 May 2019 21:29:20 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Hugo Krawczyk <>
Date: Wed, 22 May 2019 00:28:53 -0400
Message-ID: <>
To: Paterson Kenneth <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="000000000000c503a505897268c7"
Archived-At: <>
Subject: Re: [Cfrg] Adoption call for draft-barnes-cfrg-hpke
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 May 2019 04:29:24 -0000

I support adoption of this document.

I wanted to read the draft in more detail but it is not happening so just a
few remarks.

- I too think that "hybrid" has too many meanings (I believe this was
called hybrid because it mixes public key with symmetric key). This
mechanism is also known as the "envelope method". My preferred name would
be "Encapsulated Public Key Encryption". It goes well with the terminology
KEM/DEM (for "key encapsulation mechanisms" and "data encapsulation
mechanism") as introduced by Shoup and quite common in current crypto

-  I would have liked to see the KEM/DEM terminology not only used but the
sections of the paper titled like that (namely, a section on key
encapsulation and a section of data encapsulation). The draft is
essentially presenting things in equivalent ways but I would like the
terminology and the section separation to be clearer. It would reflect more
clearly the separation and independence between these mechanisms.

- My only technical comment from my superficial reading is that the
"Authentication using an Asymmetric Key" when implemented with the DH
mechanism "zz = DH(skE, pkR) + DH(skI, pkR)"  is open to a KCI attack. If I
learn R's private key not only I can read data sent to him (unavoidable in
this setting) but I can also impersonate other parties to R, namely, I can
send data to R as coming from any originator I choose. This is not a nice
property of an authenticated KEM. Two solutions that address this issue are:
1) The KEM/DEM data is signed by the sender and identities input into the
key derivation (this requires some care)
2) Use One-Pass HMQV as described in as
it gives optimal performance.
Since HMQV has a patent one may want to replace it with some other
somewhat-less-efficient implicitly-authenticated mechanism. I think Signal
is doing something like that (but I am not sure about the details).

- The draft does not discuss forward secrecy. Clearly security cannot be
achieved in case of the compromise of the recipient's private key. However,
in the authenticated scenario where the sender has a private key forward
secrecy is achieved (with the DH-based solution) for the sender - i.e., the
encapsulated key remains secure even in the case that the sender's private
key is compromised. This, however, is only forward secure against
eavesdroppers (called "weak forward secrecy"). If one also adds the DEM
part with authenticated encryption then one achieves full forward secrecy,
i.e., security against active attacks. This is discussed in the above paper
and the references within.


On Fri, Apr 26, 2019 at 4:11 AM Paterson Kenneth <>

> Dear CFRG,
> (This is the first of two adoption calls today.)
> This email starts a 2-week adoption call for:
> Hybrid Public Key Encryption
> Please give your views on whether this document should be adopted as a
> CFRG draft, and if so, whether you'd be willing to help work on it/review
> it.
> Thanks,
> Kenny (for the chairs)
> _______________________________________________
> Cfrg mailing list