square/js-jose

JWS- Verify failed with RSA public key but working with private key

deepan-s opened this issue · 13 comments

I tried one of your example for JWS signing and verification.

I'm able to perform Sign with private key properly.
But I get below issue while Verify with RSA public key

Uncaught (in promise) TypeError: Cannot read property 'then' of undefined
at WebCryptographer.verify (jose-jwe-webcryptographer.js:316)
at jose-jws-verify.js:223
at Array.forEach ()
at JoseJWS.Verifier.verify (jose-jws-verify.js:183)

Code snippet -

var cryptographer = new Jose.WebCryptographer();
cryptographer.setContentSignAlgorithm("RS256");
var signer = new JoseJWS.Signer(cryptographer);
signer.addSigner(signer_rsa_key).then(function() {
        var message = document.getElementById("jws_text").value;
        var verifier = new JoseJWS.Verifier(cryptographer, message);
        verifier.addRecipient(rsa_key1).then(function () {
                verifier.verify().then(function (verified) {
                        document.getElementById("jws_text").value = 'Verified: ' + JSON.stringify(verified, null, 4);
                        }).catch(function (err) {
                            error.textContent = "verification failed: " + err;
                            }) });});

}

var rsa_key1 =
{
"n": "00:c2:4b:af:0f:2d:2b:ad:36:72:a7:91:0f:ee:30:a0:95:d5:3a:46:82:86:96:7e:42:c6:fe:8f:20:97:af:49:f6:48:a3:91:53:ac:2e:e6:ec:9a:9a:e0:0a:fb:1c:db:44:40:5b:8c:fc:d5:1c:cb:b6:9b:60:c0:a8:ac:06:f1:6b:29:5e:2f:7b:09:d9:93:32:da:3f:db:53:9c:2e:ea:3b:41:7f:6b:c9:7b:88:9f:2e:c5:dd:42:1e:7f:8f:04:f6:60:3c:fe:43:6d:32:10:ce:8d:99:cb:76:f7:10:97:05:af:28:1e:39:0f:78:35:50:7b:8e:28:22:a4:7d:11:51:22:d1:0e:ab:6b:6f:96:cb:cf:7d:eb:c6:aa:a2:6a:2e:97:2a:93:af:a5:89:e6:c8:bc:9f:fd:85:2b:0f:b4:c0:e4:ca:b5:a7:9a:01:05:81:93:6b:f5:8d:1c:f7:f3:77:0e:6e:53:34:92:0f:48:21:34:33:44:14:5e:4a:00:41:3a:7d:cb:38:82:c1:65:e0:79:ea:a1:05:84:b2:6e:40:19:77:1a:0e:38:4b:28:1f:34:b5:cb:ac:c5:2f:58:51:d7:ec:a8:08:0e:7c:c0:20:c1:5e:a1:4d:b1:30:17:63:0e:e7:58:8e:7f:6e:9f:a4:77:8b:1e:a2:d2:2e:1b:e9",
"e": 65537
};

rsa_key as per jose-jws-example.html but I have passed only n and e as I get these values only from RSA public key export.

Please guide me if I miss any to make it work.

Are you using a browser or nodejs? Which version?

I'm using browser with latest version.

Which browser? Version?

I tried it in chrome, firefox and edge as well.
chrome - Version 66.0.3359.139
firefox - 59.0.2 (64-bit)
edge - 38.14393.2068.0

I think I can guess what's going on. When you sign the message, the kid is computed using n and d (probably a mistake? I'll have to figure that out). If you then verify with a key which doesn't have a d, you need to set the keyfinder argument (because the kid will mismatch).

We might want to change Jose.WebCryptographer.keyId to use n and e.

@rapropos, @rmhrisk, @csstaub: what do you think?

Thanks for your analysis.

Below the jsfiddle to replicate the issue. Maybe helpful for your further analysis.

https://jsfiddle.net/u0x2e2j8/5/
https://jsfiddle.net/grkz4akw/

https://jsfiddle.net/grkz4akw/1/ shows you a workaround. We should also return a better failure message when the kid isn't found.

Thanks for the workaround. But the patch works only if we perform both sign and verify operation.

patch works only with sign operation https://jsfiddle.net/grkz4akw/3/

patch fails with verify operation https://jsfiddle.net/grkz4akw/2/

Any help, how we can apply this workaround for verify also and any plans on bug fix.

https://jsfiddle.net/grkz4akw/2/ fails because of a trailing newline in message.

I was hoping to hear back from @rapropos or @rmhrisk, who wrote this part of the library. I'll give them a few more days and then roll out a fix.

Thanks. I will wait for the fix.

Just to know, I could not understand "trailing newline in message" which means I can fix this jsfiddle
https://jsfiddle.net/grkz4akw/2/ (I don't see any trailing newline in this example) or it is part of issue in library?

I think I agree with the conclusion, the problem is that this will be a breaking change (as has been pointed out above). I am not sure how large of an issue that will be for folks, maybe providing a helper to get the right kid based on the wrong kid if there was a good programmatic way to detect this wrong kid case?

I plan to write a fix for this issue next week. Sorry it's taken this long, other things have been keeping me busy.