From neried7@gmail.com Wed Feb 21 13:11:19 2024 Return-Path: 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 80B41C14F71A for ; Wed, 21 Feb 2024 13:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.855 X-Spam-Level: X-Spam-Status: No, score=-6.855 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efWQuXS9Be-t for ; Wed, 21 Feb 2024 13:11:15 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D52C14F700 for ; Wed, 21 Feb 2024 13:11:15 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2d2505352e6so24744651fa.3 for ; Wed, 21 Feb 2024 13:11:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708549873; x=1709154673; darn=irtf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ONTRRblnvp4X3WKIiukueygBFOBk2Rqb3pnpcqMYT08=; b=b2NxlvwQmnJNfqXBAbX6aEzEmYHnzrW1efA+46bQbLVLfqxU8fuH977ovYQtXVLCQu f5SnixneTwiDEO/KKqUmwx6H9y/9mnZnsQATiZ4N5eDFHTOzfQJV06SBgaLU1agY5/w7 WtJqmKjrxeNUBBEjslaPko4VA845reOVRpKbubDvXuJ0i1vCQsZtQSA9/6z+s/HPE16V GvbjMpeLYH5FxCphYOhMLJhMYBuv4STjNq13F75NNI7qqjPwOjXM8JxXxOx02zkJFH/N W4gSGiqWGOCUxAlcCil0iVy2Sf0f/4gdtrsG1rM/CRERt44sFjSANbJyLHU4QlVN3r57 yoTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708549873; x=1709154673; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ONTRRblnvp4X3WKIiukueygBFOBk2Rqb3pnpcqMYT08=; b=hsYMvRsXSmnpRh342LqygnDmMEKwXXx1fkzMWtt/uIjSWo2OcSQuttkvcJXM4uAr8b 4Wm02Ac0o1fJm0ucNoRDYRficJFGRmkLtTZyOy9bpdFZUi4XogoWcCqtiGyjZNWmWKu/ aKfkEi49MhoQFv4ajItHKLmVLlxKbBzRNLK8avVWnnpBu59aZhKABpvedsUmazsM1YF7 9VOZvXaCU0iaE+vpBHXQrWsc9WvHZc+70kw35e786mtULXfvD769YYgHO1Y9R38e15iz 2XJggoUlyz50JrVkOsh3DaKH/Dk4Lmf2qPr66yOAA4x8ayV2nCa4unsrdrNmsexFHSq6 bm/A== X-Forwarded-Encrypted: i=1; AJvYcCU1Uyo/Ce5QRHqTR/lpJloMr9CdtWoWef/DDXKP8g6tLs9SjhWDDkMfhwcBy+MRY1EvE4+6XxKTXCCYo/3g X-Gm-Message-State: AOJu0Yz9j89wz6skcU2FcMkvRArR9qPIcuyM1ccBdBrVO1pGuMy0sDhK C6xVmTiTeieIve6XMKKmcT2EJc7Qj3YwOFDLuDpopczK6ELqUEmPUnQNN1nxPE9Tk4Ju8vHEzMf azNZTnwyCeGmvu8iMSoEosgCXSbI= X-Google-Smtp-Source: AGHT+IFrmICB1h8i1siPvcgNEWGCEnwwlvvVpMgOhVFh8CNx2JSQog510/9DQDUb8d1akXN88vZBY1jfOQhhxOEhHcA= X-Received: by 2002:a2e:b88a:0:b0:2d2:44b8:db3f with SMTP id r10-20020a2eb88a000000b002d244b8db3fmr5478875ljp.48.1708549872702; Wed, 21 Feb 2024 13:11:12 -0800 (PST) MIME-Version: 1.0 References: <9D4E5BFF-E948-4460-94C1-BF1E77D641FE@gmail.com> In-Reply-To: <9D4E5BFF-E948-4460-94C1-BF1E77D641FE@gmail.com> From: Deirdre Connolly Date: Wed, 21 Feb 2024 16:10:36 -0500 Message-ID: To: Neil Madden Cc: Orie Steele , CFRG Content-Type: multipart/alternative; boundary="0000000000003e582b0611eac453" Archived-At: Subject: Re: [CFRG] More custom kem combiners: ML-KEM and ECDH with P-256 X-BeenThere: cfrg@irtf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Crypto Forum Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2024 21:11:19 -0000 --0000000000003e582b0611eac453 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ah good, someone else noticed! > They are using HKDF and chaining things via the salt parameter, which AFAICT is what WireGuard, Signal, Signal PQXDH (their hybrid update to X3DH) used HKDF with the salt parameter encoding the hash output length in bytes and the input key material as the common concatenated shared secrets with some other information as input; it doesn't look like they are chaining that invocation of HKDF by including prior secret material in the salt parameter. Apple is chaining 2 HKDF-Extracts and then a final HKDF-Expand (binding session information and transcript material via the label), and uses the whole thing as a KDF. Is this design possibly informed by results on HMAC as a dual-PRF ? On Wed, Feb 21, 2024 at 2:08=E2=80=AFPM Neil Madden wrote: > On 21 Feb 2024, at 17:16, Orie Steele wrote: > > =EF=BB=BF > Looks like Apple just announced they are going to use a custom kem > combiner with ML-KEM and ECDH with P-256. > > https://security.apple.com/blog/imessage-pq3/ > > Here is the security analysis paper: > https://security.apple.com/assets/files/Security_analysis_of_the_iMessage= _PQ3_protocol_Stebila.pdf > > > (The =E2=80=9CKEM combiner=E2=80=9D is in section 3.5.2). > > They are using HKDF and chaining things via the salt parameter, which > AFAICT is what WireGuard, Signal, Noise, TLS, IPSec, and now apparently > iMessage all do. I=E2=80=99ve actually been surprised that that hasn=E2= =80=99t been > proposed here, as it seems like a de facto standard. > > You might object that they all do this for *PSKs*, not for KEM combining, > but at least the WireGuard author has explicitly stated that they intende= d > the PSK mechanism exactly for mixing in the result of a post-quantum key > exchange: > > https://www.reddit.com/r/linux/comments/hzyu8j/comment/fzmd983/ > > (You might even say this *is* a PSK, it just happens to have been > =E2=80=9Cpre-shared=E2=80=9D very recently=E2=80=A6 during the same hands= hake=E2=80=A6) > > > It's not obvious to me if this is using a DHKem like those registered in > HPKE or if it's some custom construction. > > > It=E2=80=99s using ECDH, not a KEM, for the DH part. (I mean DHKEM basica= lly is > ECIES, so it=E2=80=99s not like there=E2=80=99s a massive difference). > > =E2=80=94 Neil > _______________________________________________ > CFRG mailing list > CFRG@irtf.org > https://mailman.irtf.org/mailman/listinfo/cfrg > --0000000000003e582b0611eac453 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ah good, someone else noticed!

>=C2=A0They are u= sing HKDF and chaining things via the salt parameter, which AFAICT is what = WireGuard, Signal,

Signal PQXDH (their hybrid update= to X3DH) used HKDF with the salt parameter encoding the hash output length= in bytes and the input key material as the common concatenated shared secr= ets with some other information as input; it doesn't look like they are= chaining that invocation of HKDF by including prior secret material in the= salt parameter.

Apple is ch= aining 2 HKDF-Extracts and then a final HKDF-Expand (binding session inform= ation and transcript material via the label), and uses the whole thing as a= KDF.=C2=A0

Is this design possibly informed by results on HMAC as a dual-PRF?=C2=A0
On W= ed, Feb 21, 2024 at 2:08=E2=80=AFPM Neil Madden <neil.e.madden@gmail.com> wrote:
On 21 Feb 2024, at 17:1= 6, Orie Steele <orie@transmute.industries> wrote:

=EF=BB=BF
Looks like Apple just announced they are going to use a custom kem co= mbiner with ML-KEM and ECDH with P-256.

https://security.apple.com/= blog/imessage-pq3/

Here is the security analysis paper:=C2=A0https://security.apple.c= om/assets/files/Security_analysis_of_the_iMessage_PQ3_protocol_Stebila.pdf<= /a>


https://www.reddit.com/r/linux/comments/hzyu8j/comment/= fzmd983/

(You might even say this *is* a PSK, it just ha= ppens to have been =E2=80=9Cpre-shared=E2=80=9D very recently=E2=80=A6 duri= ng the same handshake=E2=80=A6)


It's not obvious to me if this= is using a DHKem=C2=A0like those registered in HPKE or if it's=C2=A0so= me custom construction.


It= =E2=80=99s using ECDH, not a KEM, for the DH part. (I mean DHKEM basically = is ECIES, so it=E2=80=99s not like there=E2=80=99s a massive difference).= =C2=A0

=E2=80=94 Neil
_________________= ______________________________
CFRG mailing list
CFRG@irtf.org
https://mailman.irtf.org/mailman/listinfo/cfrg
--0000000000003e582b0611eac453--