On Tue, May 02, 2023 at 10:43:07AM -0700, Laurence Lundblade wrote:
>
>
> > On May 1, 2023, at 11:55 PM, Ilari Liusvaara <[email protected]>
> > wrote:
> >
> >>
> >> Also tried to figure out what Ilari’s 1212481536 is. Most KEM and
> >> curve IDs are small integers.
> >
> > It is offset between HPKE kem and COSE crv spaces.
> >
> > Such offset needs to exist, because this mapping needs a contiguous
> > block of 65536 crv, and values like 4 are already allocated on COSE
> > side, but available for allocation on HPKE side.
> >
> > And to not hog 1-, 2- or 3-byte space, the offset needs to be at
> > least 65536. And for keeping it in 5-byte space (which is plentiful),
> > the offset can be at most 4294901760.
> >
> > BTW, 1212481536 = 0x48450000. And in ASCII, 0x48 => H, 0x45 => E.
>
> Yeah, I figured it was some offset and looked for candidate ID spaces
> but couldn’t find one. Maybe it’s in the HPKE Python code, not RFC
> 9180? Document reference for the HPKE KEM ID space?
It is a hack specific to my COSE-HPKE code (cose-hpke-lib:src/key.rs):
const HPKE_KEY_CRV_BASE: u64 = 0x48450000; //HE.
...
__decode_key_okp():
let kem = match crv {
COSE_CRV_X25519 => HPKE_KEM_X25519,
COSE_CRV_X448 => HPKE_KEM_X448,
Algorithm::Int(x) if x.wrapping_sub(HPKE_KEY_CRV_BASE) < 65536 => {
(x - HPKE_KEY_CRV_BASE) as u16
},
_ => fail!("Unsupported crv {crv} for okp key")
};
...
__encode_hpke():
let crv = Algorithm::Int(HPKE_KEY_CRV_BASE + kem.raw_value() as u64);
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
