Skip to content
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

Open
singpolyma opened this issue Apr 26, 2012 · 4 comments
Open

Signature preparation #8

singpolyma opened this issue Apr 26, 2012 · 4 comments

Comments

@singpolyma
Copy link
Contributor

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 for verify. 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:

`makeSignature :: (Error e) => (ByteString -> ByteString) -> ByteString -> Either p v -> ByteString -> Either e ByteString

That's enough information for the preparations commonly associated with RSA and DSA, and I expect most others, though I may be wrong.

@TomMD
Copy link
Member

TomMD commented Apr 26, 2012

I'm not sure I see the benefit of this over:

sign g v . (`B.append` B.empty) . hashFor dgst

This is even shorter for users than the proposal:

makeSignature (hashFor dgst) B.empty (Right v)

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.

@singpolyma
Copy link
Contributor Author

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:

sign g v (makeSignature (hashFor dgst) B.empty (Right v))

@TomMD
Copy link
Member

TomMD commented Apr 26, 2012

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?

@singpolyma
Copy link
Contributor Author

No problem. I can do things less-polymorphically for now. I'm just a big fan of more polymorphism if we can do it :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants