ereon / csodium Goto Github PK

Asserts may not be the best to catch length mismatches.
Maybe:
Convert length errors to ValueErrors
_raise_on_error raise a more specific error (like SodiumError?)
Possibly a special error for open and verify failures

cffi 1.8.3 cares about the distinction between char and unsigned char and raises a warning now. This seems to be caused by the ffi.from_buffer(). Replacing with the following seems to suprress the warning:
ffi.cast("unsigned char *", ffi.from_buffer())

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?

Hi @ereOn, I'm currently trying to tidy up the bindings linked on the libsodium website. If this library is still maintained, then please let me know; otherwise, the link to this library will likely be removed from the bindings page to help users find up to date and maintained bindings.