Skip to content
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

Merged
merged 1 commit into from
Aug 3, 2021
Merged

add v3.local, v3.public, and v4.public #19

merged 1 commit into from
Aug 3, 2021

Conversation

panva
Copy link
Owner

@panva panva commented Jul 19, 2021

See paragonie/paseto#127

This PR will be updated as the draft evolves.

Similar to v2.local - the new v4.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.

@panva panva force-pushed the new-versions branch 3 times, most recently from 967f7c0 to ed06283 Compare July 19, 2021 17:09
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.

Copy link
Owner Author

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' ]

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 excellent, thank you!

Copy link
Owner Author

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'

Copy link
Owner Author

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'

Copy link
Owner Author

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'

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?

Copy link
Owner Author

@panva panva Jul 19, 2021

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.

@panva panva force-pushed the new-versions branch 7 times, most recently from 30e1520 to 0f8eab6 Compare July 21, 2021 14:56
@paragonie-security
Copy link

If you need test vectors, I created some in the PHP implementation: paragonie/paseto#128

@panva
Copy link
Owner Author

panva commented Jul 22, 2021

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

"pem-public-key": "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyaTgTt53ph3p5GHgwoGW\nwz5hRfWXSQA08NCOwe0FEgALWos9GCjNFCd723nCHxBtN1qd74MSh/uN88JPIbwx\nKheDp4kxo4YMN5trPaF0e9G6Bj1N02HnanxFLW+gmLbgYO/SZYfWF/M8yLBcu5Y1\nOt0ZxDDDXS9wIQTtBE0ne3YbxgZJAZTU5XqyQ1DxdzYyC5lF6yBaR5UQtCYTnXAA\npVRuUI2Sd6L1E2vl9bSBumZ5IpNxkRnAwIMjeTJB/0AIELh0mE5vwdihOCbdV6al\nUyhKC1+1w/FW6HWcp/JG1kKC8DPIidZ78Bbqv9YFzkAbNni5eSBOsXVBKG78Zsc8\nowIDAQAB\n-----END PUBLIC KEY-----",
"pem-private-key": "-----BEGIN PRIVATE KEY-----\nMIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDJpOBO3nemHenk\nYeDCgZbDPmFF9ZdJADTw0I7B7QUSAAtaiz0YKM0UJ3vbecIfEG03Wp3vgxKH+43z\nwk8hvDEqF4OniTGjhgw3m2s9oXR70boGPU3TYedqfEUtb6CYtuBg79Jlh9YX8zzI\nsFy7ljU63RnEMMNdL3AhBO0ETSd7dhvGBkkBlNTlerJDUPF3NjILmUXrIFpHlRC0\nJhOdcAClVG5QjZJ3ovUTa+X1tIG6Znkik3GRGcDAgyN5MkH/QAgQuHSYTm/B2KE4\nJt1XpqVTKEoLX7XD8VbodZyn8kbWQoLwM8iJ1nvwFuq/1gXOQBs2eLl5IE6xdUEo\nbvxmxzyjAgMBAAECggEAXbaMsNrfjIp2ezep93u2j4LcPmFHMBwyfoDO9/2pz5XJ\nsQjpGeNMfENlYrkRqNI/j+xDXl7yK9STQmhZ0nnd94v6GdC/CxpvbyCCFKCGvEza\nQbAYDVeA75JVrCom3xKO8T5D7//TVkorQ7IDRwMmNfcv1Gg9Q3+agx4A8XDSGqQU\nSGbvYZJUIRjV5j5w5eYveJzGeyeVQP/9JL2rfdHEXbLmiJbV52pxGqFb/svXJgxv\nEcVRzFaHxZTCOfUACGgI5TMXxkH7Rf88+H7WdiirrHCovRkoPCtDxIOFb+s0Mt47\n2CJzmuXsR61FBFsW+xnjQB2xfbBT6VYVSQHjYCO6gQKBgQDnP8JeoMV9nwxcI8A5\n66LzLkc0O27fRpH4c5ewEOdEjyG5ewY0PTgV+ZdHueSCGvTx8VUOYTg94pSTzXRg\nlv4gAmjzCs5nTrzafrIQw7nyiaoqKf6IhRWs9ctIujkIKGurDYni+DOiXM/Dc3kj\nwUl0uiZv0WStXzgf4i+I8jKXIQKBgQDfOfAAbb1BfoBMR8WkZU5yiCiscKe13ieJ\npYKrmd7mwUv4TAt5VzXMP3KPVrFwN6UgINnEJnKdTuQOetBwWRPRuMf+ALwmTe/t\ndP2XVQMOoLVvuub9fnAUhn+uY1rWtVmEvWj+0rHm28zazInWr3m/s13KAUgQhb6p\nsgptzpbPQwKBgGxRl1AP6rH/ECEQtffrgjZ6lOvIcxSuz60bKBBWup2Ilfl1wOAz\nVNQmR1BXqMuwqM+zhW3o6BlEyue4syyTTZHczyAZDbmiTh/ifLIRnEYZadW6Ofnk\nrNSJhaEZaaGCnXxQKShhrn39D2yz6ChxX2EH2P1Dje8PzRBSOIXjPQNBAoGALtdB\nfVWJuQyKb3dACdcYNwBLSKP7DTaopUGNweRv2YwGHPwYDEY4i7tklp9ibGHAzJUY\nHQjUVB4RzNgIlQqcFg3oKWyODpucFP/PlsnH8nHWoLNfdSHq8uOmNzmx/gvf1PLJ\n7W7Y1dCZk/AHnH0F1ywUKidKr+zgrUsm1RPcoXECgYEA0ZxDyc5uLebjBE7IquQJ\nZxbEUUyenDG/Slbvbsef3C5o6zhRt6wKfCalwxN/MZQO7NhcK0CrakmXrgcbrCx2\nRaaMFMkSmbpv2Js4E3eoVXbNDQfLIqUxbEi5VKP2A6jrWEXtQf1cHpHgdF2WkE64\nhuABZnjp2SP38cz2i90/QjI=\n-----END PRIVATE KEY-----\n",

v2, v4

"pem-public-key": "-----BEGIN PUBLIC KEY-----\nMCowBQYDK2VwAyEAHrnbu7wEfAP9cGBOAHHwmH4Wsot1ciXBHwBBXQ4gsaI=\n-----END PUBLIC KEY-----",
"pem-private-key": "-----BEGIN PRIVATE KEY-----\nMC4CAQAwBQYDK2VwBCIEILTL+0PfTOIQcn2VPkpxMwf6Gbt9n4UEFDjZ4RuUKjd0\n-----END PRIVATE KEY-----",

v3

"pem-public-key": "-----BEGIN PUBLIC KEY-----\nMEYwEAYHKoZIzj0CAQYFK4EEACIDMgAC+8t8ae4cYFeb56M0E0h42cXFvzXVUtq2\nPAFAOX7RTO9jfXcgklxEaZ6jDnKHTHL7\n-----END PUBLIC KEY-----",
"pem-private-key": "????"

Could you let me know the v3 private key used to generate the vectors?

@panva panva force-pushed the new-versions branch 4 times, most recently from 7eae404 to f19fd3b Compare July 22, 2021 09:45
@paragonie-security
Copy link

paragonie-security commented Jul 22, 2021

If you want the -pem suffix, it will only be made available in v3 because it doesn't make sense for v2/v4 and v1 is RSA so it's already PEM encoded.

EDIT: paragonie/paseto@bdcd113 :)

@panva
Copy link
Owner Author

panva commented Jul 22, 2021

doesn't make sense for v2/v4

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?

  • paseto.V2.importSodiumPrivateKey
  • paseto.V3.importSodiumPrivateKey
  • paseto.V4.importSodiumPrivateKey
  • paseto.V2.importSodiumPublicKey
  • paseto.V3.importSodiumPublicKey
  • paseto.V4.importSodiumPublicKey

@paragonie-security
Copy link

There were people for whom the conversion between spki/pkcs8 and the raw bytes format that sodium uses was a problem.

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.

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.

No, they're in the JSON. secret-key-pem.

@paragonie-security
Copy link

paragonie/paseto@bdcd113 has the PEM-encoded keys.

@panva panva force-pushed the new-versions branch 6 times, most recently from dbbff66 to 8181fa4 Compare July 22, 2021 15:49
@panva
Copy link
Owner Author

panva commented Jul 22, 2021

@paragonie-security the v2/v4 pem private keys in your vector files fail to pass openssl as valid.

the valid value would be

"-----BEGIN PRIVATE KEY-----\nMC4CAQAwBQYDK2VwBCIEILTL+0PfTOIQcn2VPkpxMwf6Gbt9n4UEFDjZ4RuUKjd0\n-----END PRIVATE KEY-----"

@panva
Copy link
Owner Author

panva commented Jul 26, 2021

@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.

@paragonie-security
Copy link

These helper functions look good to us.

paragonie-security added a commit to paragonie/paseto that referenced this pull request Jul 28, 2021
paragonie-security added a commit to paragonie/paseto that referenced this pull request Jul 28, 2021
@panva panva force-pushed the new-versions branch 2 times, most recently from 68a9132 to aaf78ec Compare July 28, 2021 17:30
paragonie-security added a commit to paragonie/paseto that referenced this pull request Jul 28, 2021
paragonie-security added a commit to paragonie/paseto that referenced this pull request Jul 29, 2021
paragonie-security added a commit to paragonie/paseto that referenced this pull request Jul 29, 2021
paragonie-security added a commit to paragonie/paseto that referenced this pull request Jul 29, 2021
paragonie-security added a commit to paragonie/paseto that referenced this pull request Jul 29, 2021
paragonie-security added a commit to paragonie/paseto that referenced this pull request Jul 29, 2021
@panva panva force-pushed the new-versions branch 2 times, most recently from 05262df to d7b0199 Compare July 29, 2021 19:13
paragonie-security added a commit to paragonie/paseto that referenced this pull request Jul 29, 2021
paragonie-security added a commit to paragonie/paseto that referenced this pull request Jul 29, 2021
@panva panva force-pushed the new-versions branch 5 times, most recently from ea32ad8 to 4afa5d9 Compare July 30, 2021 11:47
@paragonie-security
Copy link

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
@panva
Copy link
Owner Author

panva commented Jul 30, 2021

Sorry, we just realized Github is sending a notification here every time we rebase and force push in our repository.

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.

@panva
Copy link
Owner Author

panva commented Jul 30, 2021

@paragonie-security even with the inclusion of the only viable libsodium bundle for javascript (libsodium-wrappers) I could not get Version 4 implemented. crypto_stream_xchacha20_xor is not available, see the only available methods:

Screenshot 2021-07-30 at 14 53 41

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.

@panva panva merged commit bc9298e into main Aug 3, 2021
@panva panva deleted the new-versions branch August 20, 2021 15:53
@github-actions github-actions bot locked and limited conversation to collaborators Nov 19, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants