-
-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add v3.local, v3.public, and v4.public #19
Conversation
967f7c0
to
ed06283
Compare
README.md
Outdated
#### Why is v2.local and v4.local not supported? | ||
|
||
Because OpenSSL does not (yet) offer support for `XChaCha20-Poly1305` and `XChaCha20`. Once it does, | ||
and is readily available in Node.js, `v2.local` and `v4.local` will be added. |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is present today
> crypto.getHashes().filter(x=>x.includes('blake'))
[ 'blake2b512', 'blake2s256' ]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 excellent, thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
crypto.createHmac('blake2b512', 'panva').update('paseto').digest('hex')
// '045899e51fa51940d91448f3fa72626fd2bfbb25a64a9416d77a296ed962b0354ead6ea20c3c038c834b7d7c45add05c22bdd336758a0626a44c96a956ea4897'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
> crypto.createHash('blake2b512').update('paseto').digest('hex')
// '1787f53c11b9db40f2580af58beb0e72b2e2c25072e1d4636b4c548c615840e32cbcf2e8fbd7a9a09564398fc768c5a111a472c4c5c579d0ccdc824b9fa09713'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Buffer.from(crypto.hkdfSync('blake2b512', 'key', 'salt', 'info', 32)).toString('hex')
// 'b3b27a54dac96f4819e8befbc643bd78b7882208b2e366043cbf47ab44b033a4'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this let you use keyed BLAKE2b directly, or should I consider using HMAC instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What you see above is the full extent of the Node.js exposed API today. crypto.createMac
work (which i think you're asking about?) did not bear fruit yet.
I can use blake2b512
in place of any other generic hash (e.g. sha512
), but no more.
30e1520
to
0f8eab6
Compare
If you need test vectors, I created some in the PHP implementation: paragonie/paseto#128 |
The json files are missing the input nonces. And while having limited use, signed vector corresponding private keys would be nice, as well as PEM key values where applicable. NB: v1
v2, v4
v3
Could you let me know the v3 private key used to generate the vectors? |
7eae404
to
f19fd3b
Compare
If you want the EDIT: paragonie/paseto@bdcd113 :) |
There were people for whom the conversion between spki/pkcs8 and the raw bytes format that sodium uses was a problem. I'd kindly ask that we stop making a big deal out of representing keying material with standard based representations, as such all four versions signed paseto keys CAN be represented with spki public keys as well as pkcs8 private keys. SPKI and PKCS8 even allow for compressed representations for v3 too. For now all I'm lacking is the v3 private key, keep the vectors in any shape you'd like - I have filled in the blanks myself, aside of v3.public. private key. The specs already say that each implementation must make sure the points are actually on their respective curves, that ought to be enough to relax the need to only represent keys the "one way" that libsodium uses. As an aside: I have an implementation of a conversion function between your "raw" keys and Node's KeyObject (which always makes sure points are on their respective curves). Do you have a suggestion for what these should be called?
|
I didn't think an ASN.1 object identifier even existed for Ed25519, but it does, in RFC 8410, so I think I can do that.
No, they're in the JSON. |
paragonie/paseto@bdcd113 has the PEM-encoded keys. |
dbbff66
to
8181fa4
Compare
@paragonie-security the v2/v4 pem private keys in your vector files fail to pass openssl as valid. the valid value would be
|
@paragonie-security can you take a look?
NB: that being said these functions are now purely for optimization because one can pass the raw bytes directly to sign/verify now. |
These helper functions look good to us. |
68a9132
to
aaf78ec
Compare
05262df
to
d7b0199
Compare
ea32ad8
to
4afa5d9
Compare
Sorry, we just realized Github is sending a notification here every time we rebase and force push in our repository. |
Additionally allows raw byte key sequences to be passed in V2, V3, and V4's `.sign()` and `.verify()` methods as the "key" argument. Also adds utility functions to convert raw byte sequences to KeyObject. BREAKING CHANGE: Node.js runtime version v16.0.0 or greater is now required
I also get a notification because of the commit which has @panva in the message ;) But don't worry, I don't mind and we're nearing the end of this process anyway. |
@paragonie-security even with the inclusion of the only viable libsodium bundle for javascript (libsodium-wrappers) I could not get Version 4 implemented. This was merely an exercise on my part, I would not bundle 500kb worth of sodium to this library only to end up with a synchronous execution blocking code anyway. |
See paragonie/paseto#127
This PR will be updated as the draft evolves.
Similar to
v2.local
- the newv4.local
will not be implemented because it is not possible to do so without requiring libsodium. This will be revisited as XChaCha20-Poly1305 and XChaCha20 lands in OpenSSL 3.x and it being bundled with Node.js. Other features may be still be missing then though so at this point it is unlikely to be considered even long-term.This will be a breaking release (v3.0.0). It will require Node.js >= 16.0.0 due to a number of new crypto APIs that simplify the codebase.