crypto-api
crypto-api copied to clipboard
Signature preparation
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.
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.
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))
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 :)