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
Misuse of libsodium::randombytes_close() #4634
Comments
I don't think
But the use of randombytes_close is wrong in multiple ways:
which is not the case when looking at the implementation.
So calling ZMQ_LIBSODIUM_RANDOMBYTES_CLOSE is enabled by default in configure.ac/CMake when available. |
This is a recent regression: ff47aeb (Problem: no permission to relicense tweetnacl integration, 2023-02-18) |
What needs to be counted are the calls to manage_random. I did it in my fork like this: axelriet@2700a87 |
When built with ENABLE_LIBSODIUM_RANDOMBYTES_CLOSE zmq::random_close() calls zmq::manage_random(false) which in turn calls randombytes_close() which deinitializes the RNG in the crypto library.
zmq::random_close() is called from zmq::ctx_t::~ctx_t() as well as from zmq::zmq_curve_keypair() and zmq_curve_public(), however nothing says that randombytes_close() is idempotent, and calling either of zmq::zmq_curve_keypair() and zmq_curve_public() or destroying a (secondary) context - for example - will happily deinitialize the RNG multiple times and regardless of the existence of an active context, which might keep using it.
The calls to sodium_init() and randombytes_close() must be protected by a refcount, and the former must only called once on the first invocation of zmq::manage_random(true), while the latter must only be called once on the last invocation of zmq::manage_random(false).
The text was updated successfully, but these errors were encountered: