0010534: HPKE keys are generated somewhat off spec

ID	Project	Category	View Status	Date Submitted	Last Update

0010534	GNUnet	util library	public	2025-10-27 11:53	2025-10-27 11:53

Reporter	schanzen	Assigned To
Priority	normal	Severity	minor	Reproducibility	have not tried
Status	new	Resolution	open
Target Version	0.26.0

Summary	0010534: HPKE keys are generated somewhat off spec
Description	According to RFC 9180, private keys are not only sampled randomly for ECC, but also then derived using an algorithm seemingly required to implement: https://www.rfc-editor.org/rfc/rfc9180.html#name-derivekeypair This is a bit odd and also still begin discussed as part of the planned new revision of 9180: https://mailarchive.ietf.org/arch/msg/cfrg/GX2hHXxnr2UfAhnGw4LlXSekgx8/ The derivation function to derive X25519 keys (which we use) appears to be: def DeriveKeyPair(ikm): dkp_prk = LabeledExtract("", "dkp_prk", ikm) sk = LabeledExpand(dkp_prk, "sk", "", Nsk) return (sk, pk(sk)) Given "ikm" as initial keying material. Notice that it is practically impossible to verify that a given public key was generated from a private key from this derivation logic. This appears to be done primarily to domain-separte HPKE keys from other keys used elsewhere. To me, it is unclear currently if we need this spec-conform key generation logic in GNUnet. For https://lsd.gnunet.org/lsd0011/ (Elligator KEM), we override the key generation and do not use the RFC9180 DeriveKeyPair(). However, we could do that (and we would have to modify the LSD/ID.
Tags	No tags attached.

Date Modified	Username	Field	Change
2025-10-27 11:53	schanzen	New Issue