-
Notifications
You must be signed in to change notification settings - Fork 168
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
Scalar arithmetic #54
Comments
I was planning to implement scalar arithmetic myself for |
I'm happy to PR my scalar arithmetic if so desired. In any case, there are decisions to make:
My current signature implementation ("
It's not clear to me what the intended implementation approach for DH and signatures is in |
Neat! How did you implement I'm thinking it probably makes the most sense to implement RFC 6979, but also providing that sort of I think this combination gives you the best of both worlds: avoiding the catastrophic pitfalls of biased ECDSA nonces while also (optionally) hardening it against fault attacks using added entropy.
I've been talking with @str4d a lot about the next steps towards ECDSA. Ideally we'd like to have a set of traits that would allow us to implement ECDSA generically over any All that said, if you'd like to prototype adding an ECDSA implementation directly to the |
You already leak the affine coordinates, e.g. via To me as a mathematician, it's honestly quite weird to suppress the coordinates of an object that is by definition a pair of coordinates. I understand the concern, but maybe this is better handled by offering access but with a long, detailed, illuminating doc comment of when not to use the coordinates and why not? Alternatively/additionally (although I'm usually not a fan of this abuse of "unsafe"), you could offer unsafe accessors? Perhaps I'm tainted by Python's "we're all consenting adults here" philosophy, I think the way to prevent abuse of coordinates is by offering safe implementations of the things library users need, which are easier to use than unsafe implementations they might come up with themselves. |
I think this approach might work well enough in tandem with an |
What we are exposing is an opaque uncompressed encoding that is type-bound to the curve in question (up until
It is a pair of coordinates that lie on a specific elliptic curve. The core problem with exposing the underlying affine coordinates is that you lose this context: you now have a pair of field elements, and are no longer bound by the curve equations for the specific curve the coordinates are for. Encapsulating the coordinates with the curve equation context, and ensuring that the operations performed upon them make sense, is exactly what
I agree, which is why I think we should be providing traits for ECDSA and ECDH, that supported curves (which have the necessary context) can implement. In the example you linked, they would be using an ECDH trait, and the
I am still currently against this, but if we did also have an |
I understand this, which is why |
@str4d some thoughts on my #65 PR (which exposes the affine coordinates). Instead of exposing the affine coordinates, I think we could add some traits for the specific functionality needed for ECDSA, since it seems pretty concrete. I think we really need two things:
EDIT: opened #67 with a WIP implementation of the above as an alternative to #65 |
We have enough scalar arithmetic now to implement at least ECDSA signing/verification. If there's anything else you have in mind, please feel free to reopen, but I'd say at least |
It'd be good to (optionally) expose arithmetic operations on scalars.
@nickray has this for
p256
feature-guarded: nickray@3e45bdeNot sure if it is OK to upstream this?
The text was updated successfully, but these errors were encountered: