Just to be clear, kem is guessable in the examples based on `kid` and the assumption that the hint is enough to get the right private key, and that key will only ever have 1 supported kem, right?
It's guaranteed to be known if private key is kty HPKE and kem is required... Right? OS On Fri, Nov 18, 2022, 5:09 AM Ilari Liusvaara <[email protected]> wrote: > On Fri, Nov 18, 2022 at 09:46:39AM +0000, Hannes Tschofenig wrote: > > Hi all, > > > > We have two alternative proposals for encoding the HPKE-related > information, namely > > * Ilari's proposal: https://github.com/cose-wg/HPKE/pull/10 > > * Daisuke's proposal: https://github.com/cose-wg/HPKE/pull/9 > > > > While Daisuke's proposal contains an example (although we are still > > debating about how it should look like), Ilari's proposal does not > > have one yet. > > > > It would be good to have an example (or even multiple examples) to > > discover inconsistencies with the proposals. > > I think translating the one layer example is straightforward, since > the only real difference is encoding of COSE_HPKE_Sender (I don't > think that even affects any cryptographic calculations): > > > // Example of COSE-HPKE (Encrypt0) > // payload: "This is the content", aad: "" > // > 16([ > h'a10120', // alg = HPKE (-1) > { > 4: h'3031', // kid > -4: [ // HPKE sender information > 1, // kdf = HKDF-SHA256 > 1, // aead = AES-128-GCM > h'048c6f75e463a773082f3cb0d3a701348a578c67 > 80aba658646682a9af7291dfc277ec93c3d58707 > 818286c1097825457338dc3dcaff367e2951342e > 9db30dc0e7', // enc > 16, // kem = DHKEM(P-256, HKDF-SHA256) > ], > }, > / encrypted plaintext / > h'ee22206308e478c279b94bb071f3a5fbbac412a6effe34195f7 > c4169d7d8e81666d8be13', > ]) > > The optional kem field is included because the original examples also > had those (even if the kem should be easily guessable). > > > The two layer example looks to be errorneous: It uses HPKE as outer > algorithm, which is not possible, as outer algorithm must be > symmmetric bulk cipher (e.g., AES-GCM or Chacha20-Poly1305), but HPKE > is always either asymmetric or hybrid. > > The recipient structure, which seems to be sane, translates in a > straightforward way: > > [ > h'a10120', // alg = HPKE > { > 4: h'3031', // kid > -4: [ // HPKE sender information > 1, // kdf = HKDF-SHA256 > 1, // aead = AES-128-GCM > / enc output / > h'0421ccd1b00dd958d77e10399c > 97530fcbb91a1dc71cb3bf41d9 > 9fd39f22918505c973816ecbca > 6de507c4073d05cceff73e0d35 > f60e2373e09a9433be9e95e53c', > 16, // kem = DHKEM(P-256, HKDF-SHA256) > ], > }, > // ciphertext containing encrypted CEK > h'bb2f1433546c55fb38d6f23f5cd95e1d72eb4 > c129b99a165cd5a28bd75859c10939b7e4d', > ], > > Again, the kem should be guessable, but was included as it was in the > original. > > > > > -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
