Support asymmetric signing with pre-computed digest

[reaperhulk]

As mentioned in #1529 our current asymmetric signing API doesn't support signing a pre-computed digest. Instead we require a hash algorithm and you must process all the data through the signing context so we can generate the hash for you. We should look into adding support for signing without requiring that step.

One of the challenges for this is that the RSA signature blob contains an OID of the hash algorithm, so we still need to know what that algorithm was even if we didn't compute it ourselves.

[public]

What's the use case?

[alex]

Agree with @public -- unless there's some sort of protocol level reason to need this, I think it complicates the API to have two ways to do it.

[reaperhulk]

Off the top of my head I can only come up with hypothetical reasons: A service knows the identity of a remote caller that wants to sign a payload, but the payload is large (or sensitive) and the caller doesn't want to send anything but the precomputed digest.

This is essentially how PKCS11 works (you send the digest to the HSM rather than streaming the data to it to compute the digest), but we don't need to support that model in cryptography since with our existing API we could compute the digest locally and pass it to a PKCS11 backend (which would not alter the public API we have now).

Maybe others have a more concrete use case? I am fine with not adding support until we have more than hypotheticals.

[ronf]

I must admit I hadn't considered the point about still needing to know the algorithm to fill in the right OID value when creating the RSA signature blob. While a precomputed hash might still be useful in some cases, that makes it much less simple from an API perspective than just allowing "None" as the hash algorithm argument.

In practice, I must admit I haven't needed this yet, so I'm fine with leaving it out for now. At one point, I thought I might need it as SSH in one case involves signing and verifying an already hashed value, but when I looked more closely I discovered it actually ends up doing a hash of a hash in that case (computing a second hash of the already hashed value as part of computing the signature).

[reaperhulk]

I'm going to go ahead and close this since we're in agreement that it won't be implemented for now.