Make KEM ciphertext integrity (MAC) optional when unlinkability is not needed

[emlun]

It occurred to me while writing up the API for the WebAuthn sign extension, where a key identifier kid will be the primary way to reference a non-ARKG key, that the only reason we needed the MAC in the KEM is for uncorrelatability when the key handle is transmitted through an untrusted channel - e.g., the original ARKG proposal where the key handle is transmitted between two WebAuthn authenticators through a WebAuthn RP, and the RP must not be able to track users by some ARKG seed identifier. In use cases where this uncorrelatability is not needed - e.g., the WebAuthn signing extension, where the WebAuthn RP is the ARKG subordinate party and the key handle is transmitted directly between subordinate (RP) and delegating party (authenticator), this MAC is not necessary. Thus we can omit the MAC and simply use a static, opaque identifier for the ARKG seed instead.

One argument against this is the proliferation of mostly duplicated ARKG instances (e.g., ARKG-P256ADD-ECDH and ARKG-P256ADD-ECDH-HMAC are close to identical), and the fact that computing/verifying a HMAC is a tiny additional computational cost compared to the dominant operations (EC point multiplication, or even heavier PQC). I would be okay with dismissing this idea and keeping the MAC (KEM ciphertext integrity) requirement for all ARKG instances, as that addresses the widest set of use cases. I'll still rewrite some of the reasoning and some of the "considerations" sections in that case, though.

[sander]

This seems right for Hierarchical Deterministic Keys. After issuance, there should be no contact between the wallet and other parties about the key handle or an ARKG seed identifier. Communicating the MAC from the issuer to the wallet, or storing it in the wallet, does not seem to add anything useful.

One argument against this is the proliferation of mostly duplicated ARKG instances (e.g., ARKG-P256ADD-ECDH and ARKG-P256ADD-ECDH-HMAC are close to identical)

Note that such duplication will happen as well if ARKG includes the distinction between e.g. additive-blinded P256ADD and multiplicative-blinded P256MUL (e.g. for use with threshold ECDSA).

[emlun]

Communicating the MAC from the issuer to the wallet, or storing it in the wallet, does not seem to add anything useful.

Indeed it doesn't when ARKG is used in this architecture, but it does when ARKG is used in other ways as I mentioned above and in the updated text: for example when the key generation parties are instead two wallets (authenticators) without a confidential communication channel.

As I've considered this a bit more I'm now more inclined to keep the MAC for all ARKG instances since that is compatible with more use cases than without, and fewer instances means fewer opportunities for incompatibility. The MAC may be unnecessary for some use cases, but noone wants a future where half of implementations support only MAC-less instances and half support only MAC-ful instances, all else equal. I think it's better that there's only the one variant that works for the most use cases.

Note that such duplication will happen as well if ARKG includes the distinction between e.g. additive-blinded P256ADD and multiplicative-blinded P256MUL (e.g. for use with threshold ECDSA).

Yes, but that distinction will be necessary regardless of use case, so I'm not as opposed to this.