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 B9952C14F5E5 for ; Tue, 28 May 2024 07:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, 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=transmute.industries 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 ypq0TpbtDrPB for ; Tue, 28 May 2024 07:19:54 -0700 (PDT) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 7FCCFC14F5F5 for ; Tue, 28 May 2024 07:19:54 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id d9443c01a7336-1f082d92864so6679735ad.1 for ; Tue, 28 May 2024 07:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; t=1716905994; x=1717510794; 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=TqlyckG6Jo+Gw/YPlF1HcAMpYtQmPhz6RaJE/FiHECQ=; b=BM/X1fqlljiIFGLRwhOSw46ocMN2uuaawjOkikT5coVJLshZSBCf+rsEGnghpMsa1u lUi8blmIv9T8zuAFrLPiIRdtDZu55byMOdjpDNA2qO9RXQZeKEdSO0QW3W6IECqHAYrZ zWjLNkEEFDbfmk/HlWk4cAl8nAFBl97t7EMZb433RLBI2Cbk3o8CuGRipJBdbexp90gw 3skGlqvdl9WBKrYssPOvtNR2PeKt97DdpGncId5vouVwb14fme14pXQ9yVi5VgONEkg1 SVFkYe64H19w3e5mECHobMqA7OZOstdaQ5hgYGQqCdbCf28sNcM6KwiyUThR9JzPJCwK 28qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716905994; x=1717510794; 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=TqlyckG6Jo+Gw/YPlF1HcAMpYtQmPhz6RaJE/FiHECQ=; b=W1Mm+BfmFtCLjuVQN9feu3/DeVh0rtsHxsAVFNA/uRnDflbCUElfmw9GLe0cPLydXt K9YIDFGJoQy1SjUIN1OEgadGHFe4GVPQe92vjH07+Rq325iZQlPTZzVHy2DnlsV673ZH Ww+otjsKz9V2AardmGs1CHVBCOPiY1NIDrfgz1yK0DbHWRBu3YYYIUdYQmkIeOMvSMEP 0BHAFty4SHyhFYy7GcC6lpxFkYwCiyfK78GCKjb+7HgrzTQdOv1MQsz3CeTCrN4KjSN0 2l70guNONdQk9C2ToeY2Hw9h20pc5mjQ/F8YopbHOAtcKhV8bzNoR9bnaxQoE+a9/Q3Y SsZQ== X-Gm-Message-State: AOJu0YzgcRXgTV+vVof7XPtCX0rWiyjw+A1KoEsxRSDExmNAEriI/aTb lRPPbJDi5H6u2Wp3/MAadtwdVCZvHT5tJoJQRhf0Pk3ahl4EtvuyzeHuj/hYwOH4wXveFNrsVmW Y7dr9GKhGi/5KhgPxsJU47H4xUIcb0xZ0wZotmg== X-Google-Smtp-Source: AGHT+IFwcF2qeAhcE1pTeX1Pmr7rv9IUsey6BHsW2yrnh3xroISHT4FSkizrQRv5JyToWkRAtAKdl4dB3yikZQhDrIM= X-Received: by 2002:a17:902:f687:b0:1f3:5346:35f4 with SMTP id d9443c01a7336-1f44873dd4dmr130657225ad.35.1716905993617; Tue, 28 May 2024 07:19:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Orie Steele Date: Tue, 28 May 2024 09:19:41 -0500 Message-ID: To: Bas Westerbaan Content-Type: multipart/alternative; boundary="000000000000dcde5c0619845304" Message-ID-Hash: BUBXJEDUG6KLXTQMSSJTL6KQ2HEYQBE6 X-Message-ID-Hash: BUBXJEDUG6KLXTQMSSJTL6KQ2HEYQBE6 X-MailFrom: orie@transmute.industries X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: CFRG , Deirdre Connolly X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BCFRG=5D_Re=3A_PQ_HPKE_in_JOSE_and_COSE_with_ML-KEM-768=2C_HKDF-?= =?utf-8?q?SHA256=2C_AES128GCM?= List-Id: Crypto Forum Research Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000dcde5c0619845304 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If I'm reading the pqc-forum correctly, the domain separation applies to KeyGen only (which is before HPKE). Meaning that the parts of test vectors after KeyGen would remain unchanged? Or are you suggesting there will be HPKE ML-KEM domain separation from regular ML-KEM? I'm mostly interested in what parts of HPKE ML-KEM will change, assuming ML-KEM is a black box that will eventually become immutable. Ideally, I'd be able to confirm compatibility, prior to the keygen domain separation being added to FIPS 203 and FIPS 204. Also, I'm prototyping with TypeScript because that's what's easiest for me to generate examples for drafts. I agree with all the normal cautions about doing crypto in javascript. Regards, OS On Tue, May 28, 2024 at 7:31=E2=80=AFAM Bas Westerbaan = wrote: > Some replies inline. > > I based my HPKE KEM implementation on ML-KEM-768 in >> https://github.com/paulmillr/noble-post-quantum >> > > A word of caution that this implementation is not constant time. (It's > very difficult in javascript anyway, but a warning is in place.) > > >> This meant I needed to address both the HPKE and COSE / JOSE related >> context issues myself. >> It was not obvious to me exactly how to do this. >> Especially since there is no registry entries for ML-KEM in: >> https://www.iana.org/assignments/hpke/hpke.xhtml >> The answer appears to be in this draft: >> https://datatracker.ietf.org/doc/html/draft-connolly-cfrg-hpke-mlkem-00#= name-encap-and-decap >> I've done my best to follow the draft, in my experimental implementation= . >> >> Are there implementations of HPKE out there using kem id 0x0070? >> >> Are we waiting on some final confirmation from NIST to add 0x0070 to >> https://www.iana.org/assignments/hpke/hpke.xhtml ? >> I can understand not wanting to burn a code point. >> > > ML-KEM is not final yet. What people call ML-KEM now is typically the > "ipd", the initial public draft. HPKE KEMs test vectors typically include > deterministic key generation, and it seems likely [1] that that will > change for the final version of ML-KEM. > > Best, > > Bas > > [1] > https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/5CT4NC_6zRI/m/KyF= x0sapAgAJ > --=20 ORIE STEELE Chief Technology Officer www.transmute.industries --000000000000dcde5c0619845304 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If I'm reading the pqc-forum correctly, the domain sep= aration=C2=A0applies to KeyGen only (which is before HPKE).

Meaning = that the parts of test vectors after KeyGen=C2=A0would remain unchanged?
Or are you suggesting there will be HPKE ML-KEM domain separation=C2= =A0from regular ML-KEM?

I'm mostly interested in what parts of H= PKE ML-KEM will change, assuming ML-KEM is a black box that will eventually= become immutable.

Ideally, I'd be able to confirm compatibility= , prior to the keygen domain separation=C2=A0being added to FIPS 203 and FI= PS 204.

Also, I'm prototyping with=C2=A0TypeScript because that&= #39;s what's easiest for me to generate examples=C2=A0for drafts.
<= br>I agree with all the normal cautions about doing crypto in javascript.
Regards,

OS

On Tue, May 28, 2024 at 7:31=E2=80=AFAM Bas W= esterbaan <bas@cloudflare.com&= gt; wrote:
Some replies inline.

I based my HPKE KEM implementatio= n on ML-KEM-768 in=C2=A0https://github.com/paulmillr/noble-post-quantum<= /a>=C2=A0

This meant I needed to address both the HPKE an= d COSE / JOSE related context issues myself.
It was not obvious to me ex= actly how to do this.
Especially since there is no registry entries for = ML-KEM in:=C2=A0https://www.iana.org/assignments/hpke/hpke.xhtmlThe answer appears to be in this draft:=C2=A0https://datatracker.ietf.org/doc/html/draft-connolly-cfr= g-hpke-mlkem-00#name-encap-and-decap
I've done my best to follow= the draft, in my experimental implementation.=C2=A0

Are there implementations of HPKE out there= using kem id 0x0070?

Are we waiting on some final confirmation from= NIST to add 0x0070 to=C2=A0https://www.iana.org/assignments/hpke/hpke.= xhtml=C2=A0?
I can understand not wanting to burn a code point.

ML-KEM is not final yet. Wh= at people call ML-KEM now is typically the "ipd", the initial pub= lic draft. HPKE KEMs test vectors typically include deterministic key gener= ation, and it seems likely [1]=C2=A0 that that will change for the final ve= rsion of ML-KEM.

Best,

= =C2=A0Bas



--
--000000000000dcde5c0619845304--