Somewhat related to RFC 6979, I've made a patch to unify the way digest
is converted to integer (bits2int, except that it doesn't produce
canonical representation mod q).
I think it would make sense to have a shared helper function for
signing, that takes integer representation of both h (hash) an
Niels Möller writes:
> Daiki Ueno writes:
>
>> I agree, that's a valid use-case. Perhaps this might suffice:
>>
>> /* Sign DIGEST with KEY using deterministic nonce generation.
>>*
>>* DIGEST must be of the same length of SHA-256 output, that is 32
>>* octets long. */
>> void
>>
Daiki Ueno writes:
> I agree, that's a valid use-case. Perhaps this might suffice:
>
> /* Sign DIGEST with KEY using deterministic nonce generation.
>*
>* DIGEST must be of the same length of SHA-256 output, that is 32
>* octets long. */
> void
> ecdsa_sha256_sign_deterministic
Niels Möller writes:
> Daiki Ueno writes:
>
>> I have a slight feeling that the current API is not easy to use, as the
>> caller needs to instantiate both hash and HMAC contexts, as there are no
>> correlations between the two:
>
> On a more abstract level, are there any reasonable usecases for
Daiki Ueno writes:
> I have a slight feeling that the current API is not easy to use, as the
> caller needs to instantiate both hash and HMAC contexts, as there are no
> correlations between the two:
On a more abstract level, are there any reasonable usecases for having
one hash function for pro
Niels Möller writes:
> Daiki Ueno writes:
>
>> The attached patch adds support for the deterministic DSA and ECDSA, as
>> defined in RFC 6979, which enables us to use the signing function
>> without randomness.
>
> Thanks, I've had a first read, and added some comments on your MR
> (https://git.
Daiki Ueno writes:
> The attached patch adds support for the deterministic DSA and ECDSA, as
> defined in RFC 6979, which enables us to use the signing function
> without randomness.
Thanks, I've had a first read, and added some comments on your MR
(https://git.lysator.liu.se/nettle/nettle/-/mer
