Add with WitSigner()/WithVeriier() options to jws.Sign()/jws.Verify()

[dtoubelis]

Problem statement:

• We have custom implementations of Signer/Verifier for HSM base crypto for few algorithms (HS256 and ES26 in particular).
• In order to use them we need to register them in global context.
• Using global context is not ideal since it has global effect. In particular, I want to have test cases when sample is signed by our HSM based implementation -> verified by HSM implementation -> ...and then verified by the default implementation.
• Currently, there is no mechanism to either use Signer/Verifier directly or reset registration to the default implementation.

The proposed solution:

• Instead of registering Signers/Verifiers in a global context allow passing them as an option, ie WithSigner() and with.Verifier() to the corresponding methods.

Alternative/Additional solution:

• Add a method to reset Signer/Verifier registration to a default methods.

[lestrrat]

@dtoubelis When you say signer/verifier, especially in a HSM context, aren't you going to be using crypto.Signer? If so, you can already do it on a per-Sign/Verify basis

https://github.com/lestrrat-go/jwx/blob/develop/v3/docs/02-jws.md#using-cloud-kms-services

[dtoubelis]

Makes sense, than you for the explanation. One last question - how do you go about signature verification with crypto.Signer. My guess would be that since crypto.Signer exposes a public key then, it can be used for signature validation... but it also means that it can only be used with asymmetric keys... and something like HS256 cannot be used with the crypto.Signer... is this the correct assumption?

[lestrrat]

Well, I definitely have not tried it myself, but I'm pretty sure it can. But I don't know why you would want to.

crypto.Signer is used for cases when you want to store the key outside of your main Go process, be it in hardware or over the network; This is typically done to harden security. Using symmetric keys kind of defeats this purpose.

There are a few points of concern, but here are some random points off the top of my head:

• With a symmetric key, you don't know who signed the message: With asymmetric algorithms, you know that only the private key holder can sign the message. For symmetric algorithms, anyone with the key can sign, so you have no trust boundaries.
• Similarly, because anybody with the key can sign a message using symmetric keys, a malicious actor can forge fake signatures if your signature consumers (not the producers!) are compromised. With an asymmetric algorithm, you can't sign unless you obtain the private key.
• Key rotation: because all symmetric keys are by definition as important as private keys in asymmetric algorithms, you can't (well, you should avoid it, at least) publish them via JWKS or some such. So you have to resort to setting them up somewhere safe in your program, maybe from an environment variable. That means when you want to rotate the keys, you need to change them everywhere all at once. If you are using JWKS with asymmetric algorithms, you can do this semi lazily by updating the JWKS with a new public key, and then updating the private key to sign new messages.

---

Having said that, if you still want to use a symmetric algorithm with crypto.Signer, you just need to treat public key == private key, and it would still work. In concrete terms, it just means you need to return a []byte field or similar with the key from Public(), and just let your Sign() method do what you want it to. Of course, the actual key will be visible for all to see from within the go process because of the Public() method, but that's really not going to change as long as you are using a symmetric algorithm. Of course, if there's some trick with HashiCorp products that I don't know, there could be a way, but TBH I kind of doubt that.

Also, as you kind of expected it, crypto.Signer is designed for asymmetric signatures, so it's kind of misleading to use it for symmetric signatures; Readers of your code later might think it's doing asymmetric stuff when you are actually just doing symmetric operations.

---

To summarize:

• Can crypto.Signer be used for HS256? Pretty sure it could.
• Is it a good idea to do so? Probably not
• Is it a good idea to use symmetric algorithms in general? Erm, depends on your situation, but the general answer would be: "No, just use an asymmetric algorithm."

[dtoubelis]

Thanks again for the reply. Here are few bits of info that you may find helpful ;-)

• One of the reasons for using HS256 signatures is quantum safety. Asymmetric algorithms are not quantum safe, so some applications require use of quantum safe encryption. And even though using symmetric keys is very impractical, sometimes it is a hard requirement.
• A sensible application for HS256 would be signing of JWT access tokens as they expected to be verified by the app that created it... even though this application does not benefit from quantum safety - one may need it for compliance reasons.
• Key managers normally never expose private key - either symmetric or asymmetric, so that is why I'm questioning whether HS256 signatures can be validated with crypto.Signer but I will experiment with it later if I have time. ...I could potentially pass some sort of key ID as a public key and then pass it to KMS or something like that.

KMSes usually also take care of key rotations, and they may have multiple versions of the same key. So they sign/encrypt with the latest version of a key but allow verify/decrypt with certain number of previous versions of the key depending on the policy. For this reason crypto.Signer may not always work since there may be more than one public key required for verification. ...It can be addresses by passing key ID instead but resorting to these workarounds feels dirty ;-)

---

One other consideration and it is related to JWE is generation of CEK... from what I currently see your code seems using internal golang facilities and this is perfectly fine for general application. However, some regulated industries have specific requirement for RNG properties, especially for key generation. It would be nice to have integration point for external RNGs in your library as well. Typically , external RNGs are either hardware modules or KMSes and there is no standardization, so virtually every individual case will require a custom implementation.

---

BTW, your library is the only one I could find that provides decent integration options with external key managers and I thank you for that :-) ...and if you are interested I can contribute my code for HashiCorp Vault to one of your repos... just let me know.

[lestrrat]

I don't agree that using symmetric algorithms for quantum attack safety outweighs the drawbacks that they cause on the operation. I think the messier operation poses more security risks than the algorithm itself. IMHO you might be better off trying to incorporate dilithium or whatever to this library instead and use that -- but I'm not from whatever your industry is, so what do I know. Anyway, that's my take (sorry, I don't wish to discuss the plausibility of using either types of algorithms, so let's stop at that)

re: CEK generation / Hashicorp vault stuff

I have no such need, but if you want to take a shot it, you don't need my permission. FIY I care about the maintainability/compatibility and understandability of the public facing API, so if you want stuff merged to my repo, please be careful to consider these points. Thanks.

[dtoubelis]

No worries. I'm grateful for your help.

[lestrrat]

Also, this post doesn't sound like a discussion topic. Please use issues in the future for concrete bugs/issues (you don't have to do anything for this particular post, no biggie)

[dtoubelis]

I thought this section for feature request... but I can use Issues, not a problem.

[lestrrat]

FWIW, I don't get notifications for new discussions -- I get them if they are replies, but not if they are top posts. So there's a good chance your posts will not be noticed for a long time.