Decouple KEM and BL key generation

[sander]

In the current HDK draft, the holder:

• generates BL keys only for the root node, and
• generates KEM keys for every issuance process.

This makes it inefficient to invoke ARKG.GenerateSeed() which encapsulates BL and KEM. This means that HDK directly depends on BL and KEM, complicating dependencies and leaking implementation details of ARKG.

[emlun]

This would be one of my comments from reviewing HDK yesterday: why is HDK constructed in this way? ARKG.Derive-Public-Key already generates a new, ephemeral KEM key for exchanging the blinding factor (though there are requests for a deterministic variant for use with key indexing constructions). Why is a new delegating party KEM key needed for each issuance process?

[sander]

HDK supports having attestations from multiple issuers in a single tree of keys with a single root key pair. To meet the Weak-Issuer-Unlinkability requirement from Context, these multiple issuers must not receive the same pk_kem from the user during the issuance process. Otherwise, that pk_kem would become a correlation handle. Therefore, HDK currently generates a new KEM key pair for the user upon each issuance request.

[emlun]

Hm, I see. But in that case wouldn't pk_bl also be a correlation handle? Or if pk_bl is also unique per issuer, couldn't you use ARKG.Generate-Seed() to generate both together without having to reach into ARKG internals? (Or you could of course generate pk_kem and pk_bl by any other method that results in the right keys, including generating them using ARKG itself. :slightly_smiling_face:)

[sander]

@emlun This is exactly the idea of the hierarchy: each PoP key is presented only once, and can be used as a BL key (along with a newly generated KEM key) for subsequent batch issuance using ARKG. I’ve tried to illustrate this with the diagrams and the use case sequences.

[emlun]

Ah right, because ARKG returns a blinding of the BL key but not the KEM key, so to build a hierarchy you need to also replace the KEM key for each new layer. Thanks!

Yeah, on second thought I don't really see any issue with referring to the KEM functions outside of ARKG for this use. ARKG-Generate-Seed is given for completeness, but really any way to come up with the arguments for ARKG-Derive-Public-Key and ARKG-Derive-Secret-Key are equally valid.

[sander]

OK, then to make it less confusing, the HDK spec should:

• [ ] Remove ARKG-Generate-Seed and just invoke BL-Generate-Keypair when needed
• [ ] Clarify relation between BL-Generate-Keypair and KEM-Generate-Keypair outputs and ARKG-Derive-Public-Key input

[sander]

Addressed in 5ebb9be by actually using ARKG-Generate-Seed in a way that is consistent with ARKG § 2.2.1.