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

Secure Memory (Feature Request) #5

Open
steamraven opened this issue Nov 2, 2016 · 2 comments
Open

Secure Memory (Feature Request) #5

steamraven opened this issue Nov 2, 2016 · 2 comments

Comments

@steamraven
Copy link
Contributor

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:

def crypto_box_keypair(pk_out=None, sk_out=None):
    if pk_out is None:
        pk_out = bytearray(crypto_box_PUBLICKEYBYTES)
    else:
        _assert_len('pk_out', pk_out, crypto_box_PUBLICKEYBYTES)

But this would change the current API.

What are your thoughts? Is it worth it?

@ereOn
Copy link
Owner

ereOn commented Nov 3, 2016

@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 allocator of some sort to the function (which would have a default value of bytearray) and use that allocator to create the output buffers.

Let me know what you think.

@steamraven
Copy link
Contributor Author

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:

  • malloc(size)
  • public_malloc(size)
  • binary_type(buffer)

Most functions would use .malloc(). The key pair would use malloc for the secret and public_malloc for the public key.

  • The default allocator would implement the same behavior as current.
  • A secure allocator would allocate secure memory for malloc, bytearray for public_mallloc. For binary_type, it would convert byte array to bytes and leave unchanged secure memory
  • A zero copy allocator, for malloc and public_malloc could allocate using cffi buffers and no-op binary_type

I can mock up some code and you can tell me what you think.

FYI, I have a couple more commits coming:
Documentation for all functions
Helper functions
Key exchange (diffie helman)
Password hashing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants