-
Notifications
You must be signed in to change notification settings - Fork 11
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
Signature preparation #8
Comments
I'm not sure I see the benefit of this over:
This is even shorter for users than the proposal:
I'll think on it, but most my crypto-api time is going to exploring a move toward making all the classes use Ptr and making a Crypto.ByteString that lifts those class methods to provide the current functionality. |
the advantage is that there may (and indeed are) other things that need to be done. RSA typically has some extra padding that is constant / based on the size of the key. DSA typically has a truncation operation that is based on the size of the key. These things currently need to be known by the user, which breaks the abstraction when the user shouldn't need to know if we're using RSA or DSA, it just gets handled by the polymorphism. Also, to be clear, the proposal is even longer than that:
|
Ahh, I see you're point now. I'll probably do this but in the interest of minimizing major version bumps it might not appear for a little bit - will a delay cause you too many headaches? |
No problem. I can do things less-polymorphically for now. I'm just a big fan of more polymorphism if we can do it :) |
Different algorithms have different preparation requirements for creating signatures (at least, in normal use). Crypto.Classes.Signing currently provides a low-level
sign
which takes just the already-prepared ByteString. The same goes forverify
. This is fine, and definitely should remain.I would like to propose adding a new function to the Signing class
makeSignature
that takes a transformation function (Bytestring -> ByteString
usually will be a hash function), a ByteString of (possible empty) padding, and Either a public key or a private key. And, of course, a ByteString message. So:That's enough information for the preparations commonly associated with RSA and DSA, and I expect most others, though I may be wrong.
The text was updated successfully, but these errors were encountered: