View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010534 | GNUnet | util library | public | 2025-10-27 11:53 | 2026-03-11 18:25 |
| Reporter | schanzen | Assigned To | schanzen | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Target Version | 0.27.0 | Fixed in Version | 0.27.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 | |
| 2025-11-13 20:53 | schanzen | Target Version | 0.26.0 => 0.27.0 |
| 2026-03-11 18:25 | schanzen | Assigned To | => schanzen |
| 2026-03-11 18:25 | schanzen | Status | new => resolved |
| 2026-03-11 18:25 | schanzen | Resolution | open => fixed |
| 2026-03-11 18:25 | schanzen | Fixed in Version | => 0.27.0 |
| 2026-03-11 18:25 | schanzen | Note Added: 0028101 |
