Closed reneme closed 1 week ago
To be considered: When using the now-deprecated constructor we have access to an RNG. This allows us to do a random blinding when performing the multiplication with the base point, to get the associated public key. The new "key loading" constructor doesn't have an RNG and hence won't be able to use random blinding.
However, the same is true for the existing (and probably much more useful) constructor taking an AlgorithmIdentifier
.
Thanks! I had this on the docket re #4027
Re the removed RNG being used for blinding, indeed I think historically that is the reason for this (kind of weird in retrospect) combined generator-or-load constructor that took an RNG instance.
Currently, the ECC private keys provide two constructors:
AlgorithmIdentifier
and key bitsEC_Group
and an optional secret value asBigInt
The second option either generates a new key or loads the optional secret value within the provided domain. If a user wants to load an ECC private key for which they don't have an
AlgorithmIdentifier
handy, they have to use this second constructor and "hope" that they'll use it correctly. E.g. by passing aNull_RNG
to at least get some error if used incorrectly.This PR deprecates the second constructor and replaces it by two new ones:
Users that never call the now-deprecated constructor with the optional secret value won't ever see the deprecation. Their code will now just bind to the new "generating" constructor. This is achieved by making the secret value mandatory in the now-deprecated constructor.