-
Notifications
You must be signed in to change notification settings - Fork 1
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
Secure Memory (Feature Request) #5
Comments
@steamraven I like that idea. A first idea would perhaps be to provide an alternate function that takes mandatory output parameters. The current functions could be changed to use the new ones internally and allocate secure memory by default. A second idea could be to pass an Let me know what you think. |
There are a lot of functions, and I think creating new ones would unnecessarily bloat the API. I do like your idea of allocators though. Similar to the c++ Stdlib. Currently, byte arrays are allocated, passed to libsodium, then converted to bytes. This means two methods. In addition, the key pair functions generate two buffers with very different requirements: a public key and a secret key. So I see three methods for the interface:
Most functions would use .malloc(). The key pair would use malloc for the secret and public_malloc for the public key.
I can mock up some code and you can tell me what you think. FYI, I have a couple more commits coming: |
libsodium provides a mechanism for secure memory. However, they are expensive. They are much slower than a standard malloc. They also allocate 3-4 pages of memory (12kb-16kb) per call. Plus, most os have a limit on the amount of memory that can be locked.
Since secure memory is so expensive, I don't think we can use it for all allocations. One option is to pass output buffers to the functions:
But this would change the current API.
What are your thoughts? Is it worth it?
The text was updated successfully, but these errors were encountered: