Hi Ilari and Hannes, For now, I will answer one comment first.
> - Not concatenating KDF and AEAD would likely save a bit of space. > The concatenated form takes 6 bytes, but split form would likely > take 4. Thanks. I mentioned this alternative in my slides shared previously. I thought it would be a candidate in terms of the simplicity and the ease of implementation, but I did not recognize it would also reduce the data size. There is no reason not to adopt it. Regards, Daisuke 2022年10月10日(月) 21:21 Ilari Liusvaara <[email protected]>: > On Wed, Oct 05, 2022 at 08:16:44AM +0000, Hannes Tschofenig wrote: > > Hi all, > > > > I have prepared a PR: > > https://github.com/cose-wg/HPKE/pull/9 > > > > Please let me know what you think. > > > > Some quick comments: > > - Why the optional KEM field in the message structure? The recipient > has to be able to dig the KEM from the private key anyway. > > One situation where having KEM id in message could be useful would be > if recipient supports both P-* and CP-* with COSE_Key EC2 private key. > Altough that is not absolutely mandatory, as one can successfully > tiebreak using ek length. > > (When decrypting with P-* and CP-* KEMs using EC2 private key, taking > d value as byte string from key and stuffing it raw into HPKE private > key input should work. With future CP-* KEMs, doing similar thing with > x value when encrypting should also work). > > > - Not concatenating KDF and AEAD would likely save a bit of space. > The concatenated form takes 6 bytes, but split form would likely > take 4. > > + There is no AEAD 0, so the composite id is pushed to 32 bit > range. And encoding 32 bit integer takes 5 bytes. Plus there is > the key byte for total of 6. > > + Whereas presently assigned AEAD and KEM ids are in the 4.5 > bit range, which takes 1 byte to encode. Two of those plus > two key bytes for total of 4. > > > - I do not see the reason why the COSE HPKE Sender Parameter Registry > is defined. > > It seems to me that any possible extension has to be incompatible > (the present structure seems to be enough to completely use the > HPKE base mode). > > Such incompatible extensions can not be ignored: The decryption > will fail. Therefore such extensions should presumably have their > own alg values, with redefined context structure. > > > - I do not see a way to generically represent long-term HPKE > keys. > > Two ways this could be done: > > + Define new HPKE kty, with fields: > * kem (integer) > * priv (bstr) > * pub (bstr) > > + Reserve 16-bit aligned range from positive 32-bit elliptic > curve identifiers to HPKE, and then use that with OKP. > > E.g., range 1212481536 to 1212547071 inclusive (0x48450000 > to 0x4845FFFF, 0x4845 is "HE"). > > Then if HPKE defines say KEM 0x0030, keys for that can be > represented as OKP keys with curve 1212481584. > > > - I think having compact NIST curves in HPKE is such importance (saving > quite a bit of space) that COSE-HPKE specification should attempt to > register those (dropping the registrations if someone else does that > first). > > Some draft text for IANA considerations: > > > HPKE KEM DHKEM(CP-256, HKDF-SHA256): > > * Value: TBD1 > * KEM: DHKEM(CP-256, HKDF-SHA256) > * Nsecret: 32 > * Nenc: 32 > * Npk: 32 > * Nsk: 32 > * Auth: Yes > * Reference: [THIS] > > DHKEM(CP-256, HKDF-SHA256) is like DHKEM(P-256, HKDF-SHA256) > except SerializePublicKey() returns the 32 octet big endian > serialization of the smallest nonnegative representative of the > x coordinate of the elliptic curve point. DeserializePrivateKey() is > the converse, with the tie broken in arbitrary way (both choices lead > to the same ultimate result). > > [Note: This is identical to DHKEM(CP-256, HKDF-SHA256) from > draft-harkins-cfrg-dnhpke-02.] > > > HPKE KEM DHKEM(CP-384, HKDF-SHA384): > > * Value: TBD2 > * KEM: DHKEM(CP-384, HKDF-SHA384) > * Nsecret: 48 > * Nenc: 48 > * Npk: 48 > * Nsk: 48 > * Auth: Yes > * Reference: [THIS] > > DHKEM(CP-384, HKDF-SHA384) is like DHKEM(P-384, HKDF-SHA384) > except SerializePublicKey() returns the 48 octet big endian > serialization of the smallest nonnegative representative of the > x coordinate of the elliptic curve point. DeserializePrivateKey() is > the converse, with the tie broken in arbitrary way (both choices lead > to the same ultimate result). > > [Note: This is identical to DHKEM(CP-384, HKDF-SHA384) from > draft-harkins-cfrg-dnhpke-02.] > > > HPKE KEM DHKEM(CP-521, HKDF-SHA512): > > * Value: TBD3 > * KEM: DHKEM(CP-521, HKDF-SHA512) > * Nsecret: 66 > * Nenc: 66 > * Npk: 66 > * Nsk: 66 > * Auth: Yes > * Reference: [THIS] > > DHKEM(CP-521, HKDF-SHA512) is like DHKEM(P-521, HKDF-SHA512) > except SerializePublicKey() returns the 66 octet big endian > serialization of the smallest nonnegative representative of the > x coordinate of the elliptic curve point. DeserializePrivateKey() is > the converse, with the tie broken in arbitrary way (both choices lead > to the same ultimate result). > > [Note: This is identical to DHKEM(CP-521, HKDF-SHA512) from > draft-harkins-cfrg-dnhpke-02.] > > > > -Ilari > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
