Closed Patrik-Stas closed 4 months ago
@andrewwhitehead — could you please weigh in here?
Hiya, I believe what you're doing is effectively the same as passing in None
for the signature type. In that case the default signature type for that key is chosen.
@andrewwhitehead excuse the lack of my knowledge - you indicate that there might be keys which can be used for variaty of signature types. Is that right?
There are keys for which multiple signature types could be supported, for example EdDSA signatures can be deterministic or randomized: https://www.ietf.org/archive/id/draft-mattsson-cfrg-det-sigs-with-noise-04.html
At the moment none of the implemented key types support multiple signature types, though.
While integrating
askar
toaries-vcx
, following pattern has appeared in oursign
function implementation:What happens here is:
LocalKey
SigType
. We have to fallibly try to get that askey_alg
from thelocal_key
local_key
and thekey_alg
to make magic happenI find this un-intuitive that I need to use
SigType::try_from_key_alg
before I can useLocalKey
'ssign_message
, even though the information about key type is in fact contained inlocal_key
variable itself. Therefore I would rather welcome following API:Such that
sign_message
would check the key type itself.Additionally, the current API opens up doors to error where I load up
local_key
of certain cryptography type, but then pass wrong value ofSigType
argument tosign_message
function.I am open to make contribution, but before I proceed, is there's some perspective I am missing?