-
Notifications
You must be signed in to change notification settings - Fork 232
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
Secret key in Aead and/or SecretBox #833
Comments
Mind me asking what do you mean by provide back the secret key? You probably should not transmit the secret key for symmetric encryption to the receiver. Anyone intercepting that would have the means to decrypt. It is technically possible, though, encoding with base64 like this ->
If you are trying to encrypt something to be decrypted by the receiver, and the receiver to receive the means to compute a key for decryption, you should look into public key encryption. You would only share the public keys and never the secret keys. And both sides would compute the same shared key. HTH. |
Thank you very much! |
I would personally never share a secret key. Not even over tls. There are better ways. With libsodium I would do Curve25519 and use a safe established key exchange method. The easiest way for that is the nacl.public.Box() wrapper. You could use the low level bindings too, but I would recommend the high level wrapper to avoid any nonce reuse accidents. With this, the public keys are exchanged (transmitted) and each side's secret key with the remote public key compute the same secret key. So no private key nor secret shared key is ever transmitted. If a public key is compromised, it will not allow you to encrypt nor decrypt (computing the shared secret key requires a private key). Another option is using nacl.public.SealedBox. This way there's only one key pair. The receiver has a private key and public key. The sender of the encrypted message uses the receiver's public key for the encryption of the message and the receiver uses its private key for the decryption. Once again, if the public key is compromised, it will not allow you to decrypt the ciphertext. You can only do that having the private key, which was never shared. Anyone with that public key could encrypt a new message. Both examples are posted in the link I shared. Happy coding. |
Again thank you very much for this information and the detailed answer! I would look into this and try to see if I can use them but maybe is better to discuss how I am using the current method currently. The point is to provide user with the possibility to encrypt a long url while I give them back a short url (yeap it's just a url shortener with encryption). I will try to see if there is a way for pke but for now I haven't though/found something else. |
I would like to use pynacl in a project in which I want to encrypt a url.
I would like to provide back the key of the encryption but I see that it cannot be decoded back with utf-8.
How is it possible to decode the key in a "readable" format that can be copy pasted easily?
Maybe my approach is not correct and I should be using something different?
The text was updated successfully, but these errors were encountered: