Does fixedInfo in KEM Combiner need Public Key (Packet)?

[TJ-91]

Currently we have

//   Input:
//   algID - the algorithm ID encoded as octet
//   publicKey - the recipient's encryption sub-key packet
//               serialized as octet string

fixedInfo = algID || SHA3-256(publicKey)

1) Do we really need the sub-key packet here? The key material itself would be easier to implement as the raw packet is not usually passed through to the crypto operations. 2) Wouldn't fixedInfo = algID suffice or does hashing the public key here achieve stronger security?

[wussler]

No, I think it's required. Like this we're binding to both public keys in the exchange:

• On one side (the sender) we're binding to the ciphertext (that is the PK of the sender in this case)
• On the recipient side we're binding to the PK of the recipient

Right now in v4 we're putting the fingerprint, that is equivalent

[wussler]

Also for @falko-strenzke we need to bind the actual key used in the exchange, that is not the primary certification PK

[TJ-91]

Ok, we should keep it like it is then. Also it turned out not to be that hard to pass through the raw packet data after all.