Assess risk of weak issuer entropy

[sander]

BSI feedback

[sander]

In hdkeys-02 we apply KEM. In the case of DHKEM, the established salt is derived using Holder-private scalar skH and Issuer-private scalar skI with shared secret I2OSP(x([skH][skI]G)).

There is no way for the Issuer to cancel out the Holder contribution to this secret given DH strength.

The Issuer may generate a weak skI, e.g. skI = 1, enabling anyone who has eavesdropped the Holder’s KEM public key to know the salt. This breaks confidentiality of descendant key association, until another Issuer is involved without the weakness. This confidentiality would be broken in the same way if the Issuer would leak the established salt directly. Or if instead non-repudiable PoA were used and the Issuer would leak the proofs. The risk seems acceptable. Note that in ARF topic A the issuer seems to be required to use strong entropy anyway.

Possibly we could make it easier for the issuer to generate a strong skI by deriving it from a seed byte string, which is more straightforward for implementers. This should depend on support of common DHKEM implementations.