Re: [Cfrg] Adoption call for draft-barnes-cfrg-hpke
Hugo Krawczyk <hugo@ee.technion.ac.il> Thu, 23 May 2019 18:04 UTC
Return-Path: <hugokraw@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E88212007A for <cfrg@ietfa.amsl.com>; Thu, 23 May 2019 11:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.339
X-Spam-Level:
X-Spam-Status: No, score=0.339 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEWg30xfERqE for <cfrg@ietfa.amsl.com>; Thu, 23 May 2019 11:04:36 -0700 (PDT)
Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6CBE12004C for <cfrg@irtf.org>; Thu, 23 May 2019 11:04:35 -0700 (PDT)
Received: by mail-io1-f53.google.com with SMTP id r185so718064iod.6 for <cfrg@irtf.org>; Thu, 23 May 2019 11:04:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uzswp6f0SdwEvQQLDXEtixP+1GpBjwrupfRxZQ5EfUk=; b=sOac47kgMinNZ82kSPpGckABc3zkOmyp0E9OziBmnsIhKH1YZJQoPzkuzN7G58dAHM 6+r9QaXINFEv1J7fXg17IWYZEkFFY2C7Gwfk3xeyRx2FBbjGowH1wg5NJViFjwQ2Dx3Z 6W7LqxtUxjgmdfKjDpBTZ04Vg08yeXSFYS4aVNmHxuGa7K5Uas2vQgVwM3oG8eZxI5Vv 2iWlqKAtFdUhvm3QrqP6xOMCBINARP1QIdVvSeUQkHCrJaNL25JsN0h/n2X0uBP+Odz7 fvO06m3YHtpgNf4Y+mWpXRlC9uiibf1tKz/FnhqOJ0AVEBnegr85P/gIVV8pfYXdOQfz p6/w==
X-Gm-Message-State: APjAAAUj8Y33STqx4n5wlTXExbTw4QsGdrSK0clf2preHgL/WUIMFYLq kaeTva3e0SV5dkGlaLHv65zpzAzwxvETlylekEo=
X-Google-Smtp-Source: APXvYqxq5NO8SvuFN7xXHp1YMToWLSyxn4DYGzEXKXD8ovkrWU2QvU+q5/ESZC6vpZVd7GJVJFLvB1NizJDVpLkq6iY=
X-Received: by 2002:a5d:9a11:: with SMTP id s17mr30381410iol.267.1558634674182; Thu, 23 May 2019 11:04:34 -0700 (PDT)
MIME-Version: 1.0
References: <C7DA46E8-EBE9-4F4F-A621-23A089C59598@inf.ethz.ch> <CADi0yUO=B0tNZvTxsun=jNy=wk4sMau0h09_-07kRuFAnJqudA@mail.gmail.com> <810C31990B57ED40B2062BA10D43FBF501DDDA86@XMB116CNC.rim.net>
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501DDDA86@XMB116CNC.rim.net>
From: Hugo Krawczyk <hugo@ee.technion.ac.il>
Date: Thu, 23 May 2019 14:04:08 -0400
Message-ID: <CADi0yUPke6kmja0uG=X3H7chTouLhBjf66y-+p97SAX+jM94YQ@mail.gmail.com>
To: Dan Brown <danibrown@blackberry.com>
Cc: Paterson Kenneth <kenny.paterson@inf.ethz.ch>, "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="00000000000016dfcc058991ea50"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/WAQ7NcTpYeutAKG0Y4xr82qVznA>
Subject: Re: [Cfrg] Adoption call for draft-barnes-cfrg-hpke
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 May 2019 18:04:39 -0000
Oops. Rushing mistake... You are absolutely right: HOMQV does not provide KCI (I should read my own papers). Thank you for catching this. Using a signature of the sender seems indeed the only mechanism to secure the authenticated KEM against KCI - at the expense of deniability as you point out. Hugo On Thu, May 23, 2019 at 1:09 PM Dan Brown <danibrown@blackberry.com> wrote: > I think deniability is valuable in a one-pass peer-to-peer message > authentication (or authenticated encryption) scheme, and it seems that > resisting KCI (key compromise impersonation) interferes with that, though I > could be wrong. > > > > Therefore, I would favor not adding KCI to one-pass peer-to-peer message > authentication scheme. Rather, to avoid KCI, just use a digital signature > on the message. > > > > Details below. (Sorry for any formatting issues) > > > > Dan Brown > > BlackBerry, Security in Motion > > +1 (289) 261-4157 > > > > *From:* Cfrg <cfrg-bounces@irtf.org> *On Behalf Of * Hugo Krawczyk > > > > - 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) > > > > *[DB] A sender signature hinders sender basic deniability. The recipient > can now prove to the 3rd parties that at least message was sent, albeit > perhaps at the cost of exposing the recipient secret key.* > > > > *More generally, I would naively think that KCI resistance and full > deniability are incompatible. * > > > > *Informally, if Bob reveals his secret key to Charlene, he can convince > Charline that it was Alice who authenticated the message, arguing as > follows. If KCI resistance is believed by Charlene, then Charlene will be > convinced that Bob could not have generated the authenticated tag. If the > authentication security is believed by Charlene, then nobody else, other > than Alice, could have a generated the message. * > > > > *A little more formally, suppose that a pair of functions [Aut,Che] is an > asymmetric authentication scheme in the sense, where Alice and Bob have > secret keys a and b, and public key A and B (respectively), and > Che(b,A,Aut(a,B,M))=1. A KCI attack is a function Kci such that > Che(b,A,Kci(b,A,M)) = 1, i.e. the function Kci can used to authenticate a > message to Bob, using Bob’s secret instead of Alice’s.* > > > > *Convert [Aut,Che] into a pair of functions [Sig,Ver], a signature scheme, > defined by Sig(a,M) = Aut(a,B,M) and Ver(M,S) = Che(b,A,M,S). Then clearly > Ver(A,M,Sig(a,M)) = 1. These functions include Bob’s secret b as built-in > parameter, but work for the set of Alice’s key pairs [a,A] as the > asymmetric authentication scheme. A simple forger would be a function For > such that Ver(A,M,For(A,M))=1. This function replicates what Sig does > except it uses a instead A. (This is a universal-message, key-only, > forger). Then a Kci function implies a function For. So, a no Kci > functions implies no For functions. Therefore [Sig,Ver] is at least weakly > secure as a signature scheme. * > > > > *Maybe there is subtlety here that recovers plausible deniabiltiy by > having [Sig,Ver] very weak, i.e. vulnerable to existential or chosen > message attacks. Maybe this is what designed-verifier signatures are? I > doubt this though, because it seems to that such a weakness would in turn > imply interactive KCI attacks.* > > > > *In doing this, Bob reveals his secret key b, which is a high price. But > perhaps there are off-the-shelf zero-knowledge methods that Bob could use > to avoid revealing b to Charlene, yet still convincing Charlene that Alice > signed the message.* > > > > *If I am right, meaning deniability is the price of KCI resistance, then > one might as well use a proper signature on the message, and then wrap the > message plus signature inside asymmetric encryption scheme (with integrity > protection, etc.) * > > > > *I am in favor of having the option of a basically deniable authenticated > scheme. This gives Alice two options for non-interactive authenticating a > message to Bob: a signature, and a deniable authenticated message. > (Combining these two options reduces down to the signature case.)* > > > > *By the way, I am not referring above to stronger notions of deniability, > in which there is a bogus cover message.* > > > > 2) Use One-Pass HMQV as described in https://eprint.iacr.org/2010/638.pdf > <https://urldefense.proofpoint.com/v2/url?u=https-3A__eprint.iacr.org_2010_638.pdf&d=DwMFaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=mf6j6fOClApRsArWE9wqI1rEGUVkfxZ0aXWmn35nK_c&m=g2W3XR6LRfqmZLpp2cHvD4I--HfrV95Ml0rceifxHsA&s=GTIQhWGOXycNM5LiwsyWMkSUWj4DVUivVAE3H2rAPe8&e=> 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). > > > > *[DB] I am confused here, because that paper discusses HOMQV, and seems to > say that 2-pass or 3-pass HMQV is needed for KCI resistance. Are you > proposing an interactive 2-way communication?* > > > > >
- [Cfrg] Adoption call for draft-barnes-cfrg-hpke Paterson Kenneth
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… Stanislav V. Smyshlyaev
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… Stephen Farrell
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… Richard Barnes
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… Benjamin Beurdouche
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… Scott Arciszewski
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… Dan Brown
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… Mehmet Adalier
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… Russ Housley
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… denis bider
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… John Mattsson
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… Christopher Wood
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… Richard Barnes
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… Richard Barnes
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… Paul Lambert
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… mcgrew
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… Marek Jankowski
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… Jim Schaad
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… Hugo Krawczyk
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… Dan Brown
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… Hugo Krawczyk
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… Natanael
- Re: [Cfrg] Adoption call for draft-barnes-cfrg-hp… Alexey Melnikov