Consider changing some httpsig-hyper traits to be non-async + non-default RSA support

[ducaale]

Since computing and verifying content-digest header is done separately from request/response signing and verification, it would be nice to have the methods in MessageSignatureReq and MessageSignatureRes not return futures.

This is mostly helpful when using blocking HTTP client such as reqwest::blocking or ureq.

[junkurihara]

Hi @ducaale, thanks for opening this issue and for the context in ducaale/xh#448.

---

Regarding non-async traits:

I agree that the signing/verification logic itself doesn't inherently need to be async, since it only operates on headers and performs CPU-bound cryptographic operations. I'm considering restructuring the traits so that:

• The core signing/verification traits are sync
• The async versions are thin wrappers that add async content-digest handling on top

This would allow blocking HTTP clients like reqwest::blocking or ureq to use the signing functionality directly without having to work around the async boundary. I'll look into the best way to do this without breaking the existing API too much (though as a 0.0.x crate, a breaking change is acceptable if needed).

---

Regarding RSA support:

I noticed your comment in the xh PR about Mastodon only supporting RSA-SHA256. The reason RSA is currently excluded is that RSA implementations (including the rsa crate) do not provide strong constant-time guarantees, making them potentially vulnerable to timing side-channel attacks compared to Ed25519 or ECDSA. That said, I'm open to adding RSA support as a non-default feature flag (e.g., feature = "rsa"), so users who need it for interoperability (such as with Mastodon/ActivityPub) can opt in while the default remains on the safer side. I'll document the security trade-off accordingly.

---

What do you think of these ideas?

[ducaale]

• The core signing/verification traits are sync
• The async versions are thin wrappers that add async content-digest handling on top

Yeah, that would work for us, thanks.

Regarding the RSA security concerns, I agree with keeping it behind a feature flag. It could even be named in a way that discourages most users from enabling it.

[junkurihara]

@ducaale I've opened a PR for the blocking API (#10). Note that the approach changed a bit from what I initially described — see the PR description for details. What do you think of this change?

If you are fine, I will merge this and release 0.0.21. RSA support will be handled in another PR.

[ducaale]

The approach looks good to me. I have tested the changes locally and it works for us. Thanks!

[junkurihara]

Thanks for checking! I've just published 0.0.21.

This issue remains open, and I will close when RSA non-default feature is supported.

[junkurihara]

Just published 0.0.22 supporting RSA signatures as non-default feature!