crypto-api icon indicating copy to clipboard operation
crypto-api copied to clipboard

Signature preparation

Open singpolyma opened this issue 13 years ago • 4 comments
trafficstars

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.

singpolyma avatar Apr 26 '12 16:04 singpolyma

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.

TomMD avatar Apr 26 '12 16:04 TomMD

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))

singpolyma avatar Apr 26 '12 16:04 singpolyma

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?

TomMD avatar Apr 26 '12 18:04 TomMD

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

singpolyma avatar Apr 26 '12 20:04 singpolyma