Consider changing some httpsig-hyper traits to be non-async + non-default RSA support #9
Description
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.
Activity
junkurihara commentedon Feb 10, 2026
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:
This would allow blocking HTTP clients like
reqwest::blockingorureqto 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
rsacrate) 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 commentedon Feb 10, 2026
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 commentedon Feb 12, 2026
@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 commentedon Feb 12, 2026
The approach looks good to me. I have tested the changes locally and it works for us. Thanks!
[-]Consider changing some httpsig-hyper traits to be non-async[/-][+]Consider changing some httpsig-hyper traits to be non-async + non-default RSA support[/+]junkurihara commentedon Feb 13, 2026
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 commentedon Feb 13, 2026
Just published 0.0.22 supporting RSA signatures as non-default feature!