-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change HmacDrbg to support variable output size #243
Conversation
cd62770
to
4b22b57
Compare
Codecov Report
@@ Coverage Diff @@
## master #243 +/- ##
==========================================
+ Coverage 54.51% 55.14% +0.63%
==========================================
Files 8 8
Lines 299 301 +2
==========================================
+ Hits 163 166 +3
+ Misses 136 135 -1
Continue to review full report at Codecov.
|
This is simply a matter of iterating the hashing of self.v until sufficient output bytes have been produced. This is necessary for the upcoming DSA implementation.
4b22b57
to
8ab54d8
Compare
@tarcieri By the way, the next step is splitting this to a separate crate. Would it be acceptable to keep it in the same repository though? It is not a signature algorithm obviously, but it's most easily tested as part of ecdsa / dsa. |
@rvolgers yeah that's fine. I registered the |
RFC6979 is about DSA / ECDSA. Do you propose to move the k generation into this crate as well, then? That probably means adding separate features for DSA and ECDSA. |
Actually, that seems fine. It sidesteps a number of other complicating factors. |
I think everything in the current |
@tarcieri I'm running into some trouble with the |
Can you be more specific? Are you talking about this line? let h1 = Scalar::<C>::from_digest(msg_digest).to_repr(); If so, it corresponds directly to this pseudocode from RFC6979 Section 2.4:
The modular reduction should happen in the This needs to happen anywhere you see anything specific to DSA or ECDSA: the |
I'm talking about refactoring trouble, as in, I move stuff and the compiler yells at me. This is boring work and I'm trying to limit the amount of time I'm spending to figure out random implementation details I don't care about, of which there are a lot (cargo features, large amount of generics etc). In particular, the testcase has a dependency on the |
I'll put up a draft PR soon, it's probably no use talking about it like this. |
Yeah, pushing up some actual code would help.
Unlike DSA, ECDSA needs to support multiple elliptic curves, hence the generics. The In porting over the existing tests, you should operate on the raw output of |
This is simply a matter of iterating the hashing of self.v until
sufficient output bytes have been produced.
This is necessary for the upcoming DSA implementation.