Friedel Ziegelmayer

The api looks pretty good to me. The main question for me is how do we integrate this with the encryption part, as that is kinda needed for getting it...

I worry a bit about this api becoming quite complex, having to create multiple structs for each operation seems like quite a lot of mental overhead for the user of...

Not saying the current API is perfect, not even great, but I am a big advocate of making cryptographic primitives easier to use, not harder.

> where the same key is used for both encryption and signing in the same logic (does this happen?) it does happen sometimes for RSA in my experience

Maybe we could provide wrapper methods, that hide the struct generation? ```rust use signature::DigestSigner; let digest = Sha256::digest(msg); let signature = PrivateKey::from_wherever().sign_pss(digest); fn sign_pss(&self, digest) -> Signature { let signer...

couldn't we have something like ```rust fn sign_pss(&self, digest) -> Signature { .. } ```

> What type are you proposing that's implemented on? My idea was this would be implemented for the `PrivateKey` trait. > Note that in the case of an HSM/KMS/SEP-backed signer,...

So we could actually have something like ```rust let hsm: HSM = get_hsm(); let signature = hsm.sign_pss(digest); // somewhere impl PrivateKey for HSM {} ```

One issue I see with making it generic over the digest type, is that whatever hashing library you choose, gets blessed, and it is really hard to use a different...

> How else would you propose supporting multiple digest backends other than having things be generic over a `Digest` trait? Great question, which I unfortunately don't have a great answer...