Comments (5)
Please see: https://crypto.stackexchange.com/a/59168/11354
from node-jwa.
Sorry I haven't gotten a response to you yet. Saw it when you posted it, but my off-hours have been busier than usual. It's on my to-do list.
from node-jwa.
No worries. It's better that you take your time and fix this correctly than make changes in a rush and accidentally break over 1M projects that depend on this package 😃 .
from node-jwa.
No mystery here then, just some Node.js code doing Node.js stuff (i.e. doing what it can instead of what you asked for, and hoping for the best
I appreciate the snark in that StackOverflow answser, perhaps it's deserved, perhaps it's not. Hopefully I can explain more of the details here though :).
Ref: #8
Ref: nodejs/node#15024
So, as in the two links above - OpenSSL never gave "SHA256 with ECDSA" and the like a name. There was RSA-SHA256 (and friends) and then later SHA256 (and friends) were added as a more generic name and RSA-SHA256 is there as an alias. nodejs/node#15024 explains it better. A step forward here (and for #8) is to switch to those generalized names, and is something I'll open a PR for and see what the test suite says right now. That's where that issue ended, but suggesting someone else open it. This will at least remove confusion of "why is my ecdsa going to rsa code?".
However, it still isn't going to address what you've noticed. Even though you explicitly specify the RSA algorithm ECDSA keys can be used and vice-versa (as long as you're using the same *256, *384 or *512). That isn't something I can immediately solve. Even after the former adjustment, we're still going into generic signer land (openssl dgst -sha256 -sign some.pem
being the equivalent cli).
So options forward to help address this confusion...
- Switch to JWK only (they specify the type)?
- Switch to some similar key object like JWK?
- Parse PEMs and verify they are the correct type?
- Add a
noVerify
option to skip this step?
- Add a
- Consume some higher-level crypto API that has these abstractions?
tl;dr;
- OpenSSL's signing API is generic to the public/private signature option, decided by the provided key
- Node's crypto API is a thin wrapper on top of OpenSSL
- node-jwa is a thin wrapper on top of Node's crypto API
I hope that was helpful, and hope to continue the discussion.
from node-jwa.
Hi,
I'm not an expert in cryptography, but from the stackexchange comments I understand the following:
- Some algorithms that JWT support have been discovered to be completely flawed and should not be used.
- Other algorithms that JWT support require random data to be included for each signature, which some packages might not implement.
- Some implementation use the algorithm-name that is packed in the token to check the token. This is obviously silly, because a malicious user can use "none" or specify a different algorithm than expected (simpler to break?). Verifying a token should no trust the algorithm-name inside the token. When a token is verified, the user should always specify the algorithm to verify with (just like he specifies the secret/public key). Maybe JWK is the right way to do it, or some other format to pack the key together with the algorithm-name, or just force the user to specify an algorithm-name in the options.
- As for 2018, Ed25519 is recommended for asymmetric signing.
Check out my fork of jsonwebtoken: jsonwebtoken-ed25519.
from node-jwa.
Related Issues (20)
- Not enough JB Van references. HOT 2
- base64url versus base64-url HOT 1
- Signature is generated differently on Node v4 and Node v6 HOT 4
- Wrong curve used in Makefile HOT 1
- Error: PEM_read_bio_PUBKEY failed HOT 1
- build error while using jsonwebtokens in Angular6 HOT 4
- build error while using jsonwebtokens in Angular6 HOT 1
- Insecure dependency base64url < 3.0.0 HOT 4
- It seems that this does not work for ECDSA
- Can't resolve 'crypto' HOT 1
- module ignores b64 in the header HOT 1
- Feat Request: Ed25519 Support HOT 3
- error:0409806E:rsa routines:RSA_padding_add_PKCS1_PSS_mgf1:data too large for key size HOT 1
- Deprecating jwa and jws packages HOT 2
- move from `buffer-equal-constant-time` to `timingSafeEqual` HOT 2
- Enhancement/ tech debt: use Node's built-in toString(base64url)
- Handle RSA passphrase HOT 2
- use ECDSA with SHA256 signers and verifiers for elliptic curve algorithms HOT 8
- Strange algorithms are accepted HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from node-jwa.