-
Notifications
You must be signed in to change notification settings - Fork 30
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
Added in xkeys support, which are encoded x25519 keys. #37
Conversation
Pull Request Test Coverage Report for Build 162
💛 - Coveralls |
Pull Request Test Coverage Report for Build 152
💛 - Coveralls |
73c33d0
to
9f69aec
Compare
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.
LGTM
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.
Beware that there are attacks when supplied with private keys and public keys which don't actually correspond to them, and until now we've been resilient because we've always used the seed to generate both at the same time.
Beware that the seed is not the private key, but the rand source for generating the keypair.
Not following this comment..
|
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.
My mistake. I thought our "seeds" were seeds for initializing a CSPRNG to read some number of octets from it, not the private key and a replacement source for reading from. Okay, LGTM. (Obligatory: I am not a cryptographer)
Also added in support for nacl.Box compatibility for Seal and Open. We pick a random nonce for the user via a random source. We may add in other ways to encrypt data for larger messages and multiple recipients in the future. Signed-off-by: Derek Collison <derek@nats.io>
Signed-off-by: Derek Collison <derek@nats.io>
Squashed, once green will merge. |
Also added in support for nacl.Box compatibility for Seal and Open, but we pick a random nonce for the user via a random source and append for the user to avoid any bad practices.
Nacl is not the most modern approach, but has broad adoption which was a factor regarding encrypted external authorization callouts.
We may add in other ways to encrypt data for larger messages and multiple recipients in the future.
Signed-off-by: Derek Collison derek@nats.io