stef / pysodium

wrapper for libsodium providing high level crypto primitives

This is a very simple wrapper around libsodium masquerading as nacl.

This wrapper requires a pre-installed libsodium from:

https://github.com/jedisct1/libsodium

then it provides access to the following functions:

crypto_aead_aegis128l_decrypt(ciphertext, ad, nonce, key)
crypto_aead_aegis128l_encrypt(message, ad, nonce, key)
crypto_aead_aegis128l_decrypt_detached(ciphertext, mac, ad, nonce, key)
crypto_aead_aegis128l_encrypt_detached(message, ad, nonce, key)
crypto_aead_aegis256_decrypt(ciphertext, ad, nonce, key)
crypto_aead_aegis256_encrypt(message, ad, nonce, key)
crypto_aead_aegis256_decrypt_detached(ciphertext, mac, ad, nonce, key)
crypto_aead_aegis256_encrypt_detached(message, ad, nonce, key)
crypto_aead_chacha20poly1305_decrypt(ciphertext, ad, nonce, key)
crypto_aead_chacha20poly1305_encrypt(message, ad, nonce, key)
crypto_aead_chacha20poly1305_decrypt_detached(ciphertext, mac, ad, nonce, key)
crypto_aead_chacha20poly1305_encrypt_detached(message, ad, nonce, key)
crypto_aead_chacha20poly1305_ietf_decrypt(ciphertext, ad, nonce, key)
crypto_aead_chacha20poly1305_ietf_encrypt(message, ad, nonce, key)
crypto_aead_chacha20poly1305_ietf_decrypt_detached(ciphertext, mac, ad, nonce, key)
crypto_aead_chacha20poly1305_ietf_encrypt_detached(message, ad, nonce, key)
crypto_aead_xchacha20poly1305_ietf_decrypt(ciphertext, ad, nonce, key)
crypto_aead_xchacha20poly1305_ietf_encrypt(message, ad, nonce, key)
crypto_auth(message, key)
crypto_auth_verify(tag, message, key)
crypto_box_afternm(msg, nonce, k)
crypto_box_beforenm(pk, sk)
crypto_box_detached(msg, nonce, pk, sk)
crypto_box_keypair()
crypto_box(msg, nonce, pk, sk)
crypto_box_open_afternm(c, nonce, k)
crypto_box_open(c, nonce, pk, sk)
crypto_box_open_detached(c, mac, nonce, pk, sk)
crypto_box_seal(msg, pk)
crypto_box_seal_open(c, pk, sk)
crypto_box_seed_keypair(seed)
crypto_generichash_blake2b_salt_personal(message, outlen = crypto_generichash_blake2b_BYTES, key = b'', salt = b'', personal = b'')
crypto_generichash_final(state, outlen=crypto_generichash_BYTES)
crypto_generichash_init(outlen=crypto_generichash_BYTES, k=b'')
crypto_generichash(m, k=b'', outlen=crypto_generichash_BYTES)
crypto_generichash_update(state, m)
crypto_hash_sha256(message)
crypto_hash_sha512(message)
crypto_hash_sha512_init()
crypto_hash_sha512_update(state, data)
crypto_hash_sha512_final(state)
crypto_kx_client_session_keys(client_pk, client_sk, server_pk)
crypto_kx_keypair()
crypto_kx_server_session_keys(server_pk, server_sk, client_pk)
crypto_pwhash(outlen, passwd, salt, opslimit, memlimit, alg)
crypto_pwhash_scryptsalsa208sha256(outlen, passwd, salt, opslimit, memlimit)
crypto_pwhash_scryptsalsa208sha256_str(passwd, opslimit, memlimit)
crypto_pwhash_scryptsalsa208sha256_str_verify(stored, passwd)
crypto_pwhash_str(passwd, opslimit, memlimit)
crypto_pwhash_str_verify(pstr, passwd)
crypto_scalarmult_base(n)
crypto_scalarmult_curve25519_base(n)
crypto_scalarmult_curve25519(n, p)
crypto_secretbox(msg, nonce, k)
crypto_secretbox_detached(msg, nonce, k)
crypto_secretbox_open(c, nonce, k)
crypto_secretbox_open_detached(c, mac, nonce, k)
crypto_secretstream_xchacha20poly1305_keygen():
crypto_secretstream_xchacha20poly1305_init_push(key):
crypto_secretstream_xchacha20poly1305_init_pull(header, key):
crypto_secretstream_xchacha20poly1305_rekey(state):
crypto_secretstream_xchacha20poly1305_push(state, message, ad, tag):
crypto_secretstream_xchacha20poly1305_pull(state, ciphertext, ad):
crypto_sign_init()
crypto_sign_update(state, m)
crypto_sign_final_create(state, sk)
crypto_sign_final_verify(state, sig, pk)
crypto_sign_detached(m, sk)
crypto_sign_keypair()
crypto_sign(m, sk)
crypto_sign_open(sm, pk)
crypto_sign_pk_to_box_pk(pk)
crypto_sign_seed_keypair(seed)
crypto_sign_sk_to_box_sk(sk)
crypto_sign_sk_to_pk(sk)
crypto_sign_sk_to_seed(sk)
crypto_sign_verify_detached(sig, msg, pk)
crypto_stream_chacha20_xor(message, nonce, key)
crypto_stream_chacha20_xor_ic(message, nonce, initial_counter, key)
crypto_stream_chacha20_ietf_xor(message, nonce, key)
crypto_stream_chacha20_ietf_xor_ic(message, nonce, initial_counter, key)
crypto_stream_xchacha20_xor(message, nonce, key)
crypto_stream_xchacha20_xor_ic(message, nonce, initial_counter, key)
crypto_stream(cnt, nonce=None, key=None)
crypto_stream_xor(msg, cnt, nonce=None, key=None)
randombytes(size)
sodium_increment(bytes)
crypto_core_ristretto255_is_valid_point(p)
crypto_core_ristretto255_from_hash(r)
crypto_scalarmult_ristretto255(n, p)
crypto_scalarmult_ristretto255_base(n)
crypto_core_ristretto255_scalar_random()
crypto_core_ristretto255_scalar_invert(s)
crypto_core_ristretto255_scalar_reduce(s)
crypto_core_ristretto255_add(p, q)
crypto_core_ristretto255_sub(p,q)
crypto_core_ristretto255_random()
crypto_core_ristretto255_scalar_negate(s)
crypto_core_ristretto255_scalar_complement(s)
crypto_core_ristretto255_scalar_add(x,y)
crypto_core_ristretto255_scalar_sub(x,y)
crypto_core_ristretto255_scalar_mul(x,y)
crypto_auth_hmacsha256_keygen
crypto_auth_hmacsha256
crypto_auth_hmacsha256_verify
crypto_auth_hmacsha512_keygen
crypto_auth_hmacsha512
crypto_auth_hmacsha512_verify
crypto_auth_hmacsha512256_keygen
crypto_auth_hmacsha512256
crypto_auth_hmacsha512256_verify
crypto_kdf_derive_from_key(subkey_len, subkey_id, ctx, key)
crypto_kdf_keygen()
crypto_kdf_hkdf_sha256_extract_init(salt=b'')
crypto_kdf_hkdf_sha256_extract_update(state, ikm=b'')
crypto_kdf_hkdf_sha256_extract_final(state)
crypto_kdf_hkdf_sha256_extract(salt=b'', ikm=b'')
crypto_kdf_hkdf_sha256_keygen()
crypto_kdf_hkdf_sha256_expand(outlen, prk, ctx=b'')
crypto_kdf_hkdf_sha512_extract_init(salt=b'')
crypto_kdf_hkdf_sha512_extract_update(state, ikm=b'')
crypto_kdf_hkdf_sha512_extract_final(state)
crypto_kdf_hkdf_sha512_extract(salt=b'', ikm=b'')
crypto_kdf_hkdf_sha512_keygen()
crypto_kdf_hkdf_sha512_expand(outlen, prk, ctx=b'')

Constants:

crypto_aead_chacha20poly1305_ABYTES
crypto_aead_chacha20poly1305_KEYBYTES
crypto_aead_chacha20poly1305_NPUBBYTES
crypto_aead_chacha20poly1305_ietf_KEYBYTES
crypto_aead_chacha20poly1305_ietf_NPUBBYTES
crypto_aead_chacha20poly1305_ietf_ABYTES
crypto_aead_xchacha20poly1305_ietf_KEYBYTES
crypto_aead_xchacha20poly1305_ietf_NPUBBYTES
crypto_aead_xchacha20poly1305_ietf_ABYTES
crypto_auth_BYTES
crypto_auth_KEYBYTES
crypto_box_BEFORENMBYTES
crypto_box_BOXZEROBYTES
crypto_box_MACBYTES
crypto_box_NONCEBYTES
crypto_box_PUBLICKEYBYTES
crypto_box_SEALBYTES
crypto_box_SECRETKEYBYTES
crypto_box_SEEDBYTES
crypto_box_ZEROBYTES
crypto_generichash_KEYBYTES_MAX
crypto_generichash_BYTES
crypto_generichash_BYTES_MAX
crypto_generichash_BYTES_MIN
crypto_generichash_STATEBYTES
crypto_generichash_blake2b_BYTES
crypto_generichash_blake2b_BYTES_MAX
crypto_generichash_blake2b_BYTES_MIN
crypto_generichash_blake2b_KEYBYTES_MAX
crypto_generichash_blake2b_PERSONALBYTES
crypto_generichash_blake2b_SALTBYTES
crypto_hash_sha256_BYTES
crypto_hash_sha512_BYTES
crypto_hash_sha512_STATEBYTES
crypto_kx_PUBLICKEYBYTES
crypto_kx_SECRETKEYBYTES
crypto_kx_SESSIONKEYBYTES
crypto_pwhash_ALG_DEFAULT
crypto_pwhash_ALG_ARGON2I13
crypto_pwhash_ALG_ARGON2ID13
crypto_pwhash_BYTES_MAX
crypto_pwhash_BYTES_MIN
crypto_pwhash_MEMLIMIT_MAX
crypto_pwhash_MEMLIMIT_MIN
crypto_pwhash_MEMLIMIT_INTERACTIVE
crypto_pwhash_MEMLIMIT_MODERATE
crypto_pwhash_MEMLIMIT_SENSITIVE
crypto_pwhash_OPSLIMIT_MAX
crypto_pwhash_OPSLIMIT_MIN
crypto_pwhash_OPSLIMIT_INTERACTIVE
crypto_pwhash_OPSLIMIT_MODERATE
crypto_pwhash_OPSLIMIT_SENSITIVE
crypto_pwhash_PASSWD_MAX
crypto_pwhash_PASSWD_MIN
crypto_pwhash_argon2i_MEMLIMIT_INTERACTIVE
crypto_pwhash_argon2i_MEMLIMIT_MODERATE
crypto_pwhash_argon2i_MEMLIMIT_SENSITIVE
crypto_pwhash_argon2i_OPSLIMIT_INTERACTIVE
crypto_pwhash_argon2i_OPSLIMIT_MODERATE
crypto_pwhash_argon2i_OPSLIMIT_SENSITIVE
crypto_pwhash_argon2id_MEMLIMIT_INTERACTIVE
crypto_pwhash_argon2id_MEMLIMIT_MODERATE
crypto_pwhash_argon2id_MEMLIMIT_SENSITIVE
crypto_pwhash_argon2id_OPSLIMIT_INTERACTIVE
crypto_pwhash_argon2id_OPSLIMIT_MODERATE
crypto_pwhash_argon2id_OPSLIMIT_SENSITIVE
crypto_pwhash_SALTBYTES
crypto_pwhash_STRBYTES
crypto_pwhash_scryptsalsa208sha256_BYTES_MAX
crypto_pwhash_scryptsalsa208sha256_BYTES_MIN
crypto_pwhash_scryptsalsa208sha256_MEMLIMIT_MAX
crypto_pwhash_scryptsalsa208sha256_MEMLIMIT_MIN
crypto_pwhash_scryptsalsa208sha256_MEMLIMIT_INTERACTIVE
crypto_pwhash_scryptsalsa208sha256_MEMLIMIT_SENSITIVE
crypto_pwhash_scryptsalsa208sha256_OPSLIMIT_MAX
crypto_pwhash_scryptsalsa208sha256_OPSLIMIT_MIN
crypto_pwhash_scryptsalsa208sha256_OPSLIMIT_INTERACTIVE
crypto_pwhash_scryptsalsa208sha256_OPSLIMIT_SENSITIVE
crypto_pwhash_scryptsalsa208sha256_PASSWD_MAX
crypto_pwhash_scryptsalsa208sha256_PASSWD_MIN
crypto_pwhash_scryptsalsa208sha256_SALTBYTES
crypto_pwhash_scryptsalsa208sha256_STRBYTES
crypto_pwhash_scryptsalsa208sha256_STRPREFIX
crypto_scalarmult_BYTES
crypto_scalarmult_SCALARBYTES
crypto_scalarmult_curve25519_BYTES
crypto_secretbox_BOXZEROBYTES
crypto_secretbox_KEYBYTES
crypto_secretbox_KEYBYTES
crypto_secretbox_MACBYTES
crypto_secretbox_NONCEBYTES
crypto_secretbox_ZEROBYTES
crypto_secretstream_xchacha20poly1305_STATEBYTES
crypto_secretstream_xchacha20poly1305_ABYTES
crypto_secretstream_xchacha20poly1305_HEADERBYTES
crypto_secretstream_xchacha20poly1305_KEYBYTES
crypto_secretstream_xchacha20poly1305_MESSAGEBYTES_MAX
crypto_secretstream_xchacha20poly1305_TAG_MESSAGE
crypto_secretstream_xchacha20poly1305_TAG_PUSH
crypto_secretstream_xchacha20poly1305_TAG_REKEY
crypto_secretstream_xchacha20poly1305_TAG_FINAL
crypto_sign_BYTES
crypto_sign_PUBLICKEYBYTES
crypto_sign_SECRETKEYBYTES
crypto_sign_SEEDBYTES
crypto_sign_ed25519_PUBLICKEYBYTES
crypto_sign_ed25519_SECRETKEYBYTES
crypto_stream_KEYBYTES
crypto_stream_NONCEBYTES
crypto_stream_chacha20_NONCEBYTES
crypto_stream_chacha20_KEYBYTES
crypto_stream_chacha20_ietf_NONCEBYTES
crypto_stream_chacha20_ietf_KEYBYTES
crypto_stream_xchacha20_NONCEBYTES
crypto_stream_xchacha20_KEYBYTES
crypto_core_ristretto255_BYTES
crypto_core_ristretto255_HASHBYTES
crypto_core_ristretto255_SCALARBYTES
crypto_core_ristretto255_NONREDUCEDSCALARBYTES
crypto_auth_hmacsha256_BYTES
crypto_auth_hmacsha256_KEYBYTES
crypto_auth_hmacsha512_BYTES
crypto_auth_hmacsha512_KEYBYTES
crypto_auth_hmacsha512256_BYTES
crypto_auth_hmacsha512256_KEYBYTES
crypto_kdf_BYTES_MIN
crypto_kdf_BYTES_MAX
crypto_kdf_CONTEXTBYTES
crypto_kdf_KEYBYTES
crypto_kdf_hkdf_sha256_KEYBYTES
crypto_kdf_hkdf_sha256_BYTES_MIN
crypto_kdf_hkdf_sha256_BYTES_MAX
crypto_kdf_hkdf_sha256_STATEBYTES

Note

most of the the *_easy functions are not implemented as the "non-easy" functions provide already the "easy" interface, which hides the placement of buffers in memory, which makes little sense in python, so this wrapper handles this.

pysodium's Issues

New release for crypto_stream_xchacha20_xor support

Hello! I saw you added support for crypto_stream_xchacha20_xor a few months back, and was hoping you would publish a new version containing it to pypi soon. Any plans around that?

Thank you for your work on this project! It has made working with libsodium much more convenient for my work on pypaseto!

meanings of 'ad' and 'nonce'

Hi,
What are the meanings of 'ad' and 'nonce' in function test_aead_chacha20poly1305?
Thanks！

More places using wrong parameter size on x64

Found some more parameter type discrepancies, link to patch:
https://spideroak.com/storage/OJ2XA33MMU/shared/569346-28-1480/pysodium_parameter_size.patch?730b953742d3894a3bf6dd0a9a9b0f35

crypto_secretbox_detached and crypto_secretbox_open_detached

Hello,
I can not find the "detached" variants of the functions crypto_secretbox_detached and crypto_secretbox_open_detached.
Is it possible to add this two functions?

ability to check version of pysodium in-code missing

Given #111 and the hopeful upcoming fix I wanted to add to my code a version check where I could kludge a value for where pysodium.crypto_secretstream_xchacha20poly1305_MESSAGEBYTES_MAX.value is broken and use it where it is fixed but there appears to be no way to do that programmatically.

Could this be added, please?

Inclusion of libsodium in pysodium

Hi,

Would you consider accepting a PR that makes pysodium an "autonomous" Python package (that would not depend on the presence of libsodium.so/libsodium.dll on the target system) ?

The idea would be to provide a wheel for all platforms and the binary dependency would no longer be required on Windows and OSX. On linux, installing the package would still require an available libsodium on the system (binary wheels are not supported for Linux afaik).

Users would only have to do:

pip install pysodium

To get a fully working pysodium. Checks for the library failure on import would also no longer be a concern for user-code.

Before I put on all the work for that, is this something you'd consider for inclusion ?

Thanks for the amazing work so far !

crypto_box(_open) confusion

I'm trying to use crypto_box and crypto_box_open to let party A encrypt and sign data for party B.
From my understanding, the following code should work:

def test_cross_box():
    pkA, skA = pysodium.crypto_sign_keypair()
    pkB, skB = pysodium.crypto_sign_keypair()
    nonce = pysodium.randombytes(pysodium.crypto_box_NONCEBYTES)
    msg = "foo"
    c = pysodium.crypto_box(msg, nonce, pkB, skA)
    d = pysodium.crypto_box_open(c, nonce, pkA, skB)
    assert msg == d

However, the above code raises a ValueError in
/usr/local/lib/python2.7/site-packages/pysodium/__init__.py:256: in crypto_box_open __check(sodium.crypto_box_open(msg, padded, ctypes.c_ulonglong(len(padded)), nonce, pk, sk))

The unit test only seems to check for cases where the public and secret key are the same when calling crypto_box and crypto_box_open, and indeed the following code works:

def test_self_box():
    pkA, skA = pysodium.crypto_sign_keypair()
    nonce = pysodium.randombytes(pysodium.crypto_box_NONCEBYTES)
    msg = "foo"
    c = pysodium.crypto_box(msg, nonce, pkA, skA)
    d = pysodium.crypto_box_open(c, nonce, pkA, skA)
    assert msg == d

Am I missing something about how crypto_box should be used, or is this a bug?

Using python 2.7, pysodium 0.6.8, libsodium 1.0.9

Include libsodium from non-system path

Hi,

I do not want to install libsodium and pysodium system-wide. Is it possible to include libsodium from a custom path? At the moment I get this error. I guess that libsodium is not found by pysodium.

['/Users/xxx/Projekte/catmail/client', '/Library/Python/2.7/site-packages/pip-1.4.1-py2.7.egg', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages', '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload', '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC', '/Library/Python/2.7/site-packages', '../3rdparty/pysodium-build/lib/python2.7/site-packages/pysodium-0.6.7-py2.7.egg']
Traceback (most recent call last):
  File "main.py", line 6, in <module>
    import pysodium
  File "build/bdist.macosx-10.11-intel/egg/pysodium/__init__.py", line 34, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 378, in __getattr__
    func = self.__getitem__(name)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 383, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: dlsym(RTLD_DEFAULT, crypto_pwhash_scryptsalsa208sha256_strprefix): symbol not found

Thanks in advance!

crypto_secretstream* functions?

Do you intend to support the crypto_secretstream* functions, or is there another straightforward way to encrypt streams and large files without having the whole thing in memory?

IOError when importing pysodium

I have installed pysodium system wide as root, so that it's available to all users. However, when importing pysodium, I'm getting an IOError:

IOError: [Errno 2] No such file or directory: '/usr/lib/python2.7/dist-packages/pysodium/__pycache__/_cffi__x298fef8bx9b9c1209.c'

It seems like the same kind of problem has occurred in PyNaCl:
pyca/pynacl#26

The problem seems to be the ffi.verify() call in sodium.py, which needs the further ext_package parameter according to the CFFI documentation:
http://cffi.readthedocs.org/en/release-0.6/#distributing-modules-using-cffi

The problem should be easy to fix also for pysodium along a similar lilne:
abspoel/pynacl@1262633

support python 3

Hi, 2to3 runs cleanly on current pysodium - please apply it! Thanks!

py3 strings f*ck up generichash

>>> import pysodium
>>> pysodium.crypto_generichash( 'salt0') == pysodium.crypto_generichash( 'salt1')
True
>>> pysodium.crypto_generichash(b'salt0') == pysodium.crypto_generichash(b'salt1')
False
>>>

observe that only the type of the salt[01] input changed from str to byte, and only for bytes it gives the correct output.

may hastur haunt the dreams of those responsible for py3 string "handling"

libsodium version checking ?

Hi,

Yesterday I had the unpleasant surprise to find my app non-working after the update of pysodium to 0.6.9.
After a bit I found that the introduction of the aead* function was the root of the problem.
I'm on FreeBSD and the libsodium package is still 1.0.8 (aead* functions where introduced in 1.0.9).

So we have two possibility :

1. Check the libsodium version at runtime and raise something if we need an upgraded version
2. Only import function from libsodium based on the version

I will happily provide a patch depending on which way you prefer.

Cheers,

Segfault on ARM (RaspberryPi) with Custom Binding

Howdy,

I'm trying to use libsodium with PySodium, but found that there wasn't a binding already for the chacha20_poly1305 algorithm, so I took my first stab at writing one: https://gist.github.com/mojojoseph/9b43bd35a7ab3812d7bd

This code:
https://gist.github.com/mojojoseph/c555110400060bcf99a3

works fine on an AMD64 Linux server, but when I port it over to an ARMv6 (RaspberryPi) I get a nasty trace, and I am guessing somewhere in the FFI calls my stack goes bonkers.

The actual break is at

Program received signal SIGSEGV, Segmentation fault.
chacha_keysetup (x=0xbeffefc4, k=0x0) at crypto_stream/chacha20/ref/stream_chacha20_ref.c:69
69      x->input[4] = U8TO32_LITTLE(k + 0);

with a stacktrace - I notice that after the ffi_call_VFP() things go bonkers. I'm uncertain as to whether my ctypes binding is just wrong for the arguments that are needed or there's something going on with the ARM/FFI combination. Like I said it all works fine on the AMD64 linux server.

#0  chacha_keysetup (x=0xbeffefc4, k=0x0) at crypto_stream/chacha20/ref/stream_chacha20_ref.c:69
#1  0x4059dcbc in crypto_stream_chacha20_ref (c=0xbefff0e4 "\264\335\024", clen=<optimized out>, n=0x0, k=0x0)
    at crypto_stream/chacha20/ref/stream_chacha20_ref.c:241
#2  0x40556f60 in crypto_aead_chacha20poly1305_encrypt (c=0x405385f4 "\206Йt\204\v\336", <incomplete sequence \312>, clen=0x437f44, 
    m=0x0, mlen=4634464344201201140, ad=0xa <Address 0xa out of bounds>, adlen=1079196860, nsec=0xa <Address 0xa out of bounds>, npub=
    0x0, k=0x0) at crypto_aead/chacha20poly1305/sodium/aead_chacha20poly1305.c:49
#3  0x40501368 in ffi_call_VFP () from /usr/lib/python2.7/lib-dynload/_ctypes_d.so
#4  0x40500930 in ffi_call () from /usr/lib/python2.7/lib-dynload/_ctypes_d.so
#5  0x404ecf10 in _call_function_pointer (flags=4353, pProc=0x40556ea8 <crypto_aead_chacha20poly1305_encrypt>, avalues=0xbefff2d8, 
    atypes=0xbefff2a8, restype=0x402a6ed8, resmem=0xbefff308, argcount=9)
    at /build/python2.7-xJctIx/python2.7-2.7.3/Modules/_ctypes/callproc.c:827
#6  0x404edb84 in _ctypes_callproc (pProc=0x40556ea8 <crypto_aead_chacha20poly1305_encrypt>, argtuple=
    (<c_char_Array_26 at remote 0x4054fc68>, <c_ulonglong at remote 0x4054fcd0>, '\x86\xd0\x99t\x84\x0b\xde\xd2\xa5\xca', <c_ulonglong at remote 0x40307fa8>, '\x87\xe2)\xd4P\x08E\xa0y\xc0', <c_ulonglong at remote 0x4054fc00>, None, '\xcd|\xf6{\xe3\x9cyJ', "B\x90\xbc\xb1T\x1751\xf3\x14\xafW\xf3\xbe;P\x06\xda7\x1e\xce'*\xfa\x1b]\xbd\xd1\x10\n\x10\x07"), flags=4353, argtypes=0x0, restype=
    <_ctypes.PyCSimpleType at remote 0x408920>, checker=0x0)
    at /build/python2.7-xJctIx/python2.7-2.7.3/Modules/_ctypes/callproc.c:1174
#7  0x404e5154 in PyCFuncPtr_call (self=0x40518e90, inargs=
    (<c_char_Array_26 at remote 0x4054fc68>, <c_ulonglong at remote 0x4054fcd0>, '\x86\xd0\x99t\x84\x0b\xde\xd2\xa5\xca', <c_ulonglong at remote 0x40307fa8>, '\x87\xe2)\xd4P\x08E\xa0y\xc0', <c_ulonglong at remote 0x4054fc00>, None, '\xcd|\xf6{\xe3\x9cyJ', "B\x90\xbc\xb1T\x1751\xf3\x14\xafW\xf3\xbe;P\x06\xda7\x1e\xce'*\xfa\x1b]\xbd\xd1\x10\n\x10\x07"), kwds=0x0)
    at /build/python2.7-xJctIx/python2.7-2.7.3/Modules/_ctypes/_ctypes.c:3913
#8  0x0002fa08 in PyObject_Call (func=<_FuncPtr(__name__='crypto_aead_chacha20poly1305_encrypt') at remote 0x40518e90>, arg=
    (<c_char_Array_26 at remote 0x4054fc68>, <c_ulonglong at remote 0x4054fcd0>, '\x86\xd0\x99t\x84\x0b\xde\xd2\xa5\xca', <c_ulonglong at remote 0x40307fa8>, '\x87\xe2)\xd4P\x08E\xa0y\xc0', <c_ulonglong at remote 0x4054fc00>, None, '\xcd|\xf6{\xe3\x9cyJ', "B\x90\xbc\xb1T\x1751\xf3\x14\xafW\xf3\xbe;P\x06\xda7\x1e\xce'*\xfa\x1b]\xbd\xd1\x10\n\x10\x07"), kw=0x0) at ../Objects/abstract.c:2529

Missing the beforenm/afternm functions

Is there any reason those are left out? If not, I'd be happy to submit a PR.

Inconsistent copyright for test/

test/init.py is Copyright (c) 2001-2014 Acronis, Author Bulat Gaifullin ([email protected]), no license specified.

test/test_pysodium.py is Copyright (c) 2013-2014, Marsiske Stefan, license BSD-2-Clause.

It appears that both files were originally committed by @bgaifullin in commit 4fc0a48 and that the copyright and license for test/test_pysodium.py was changed to Copyright (c) 2013-2014, Marsiske Stefan, license BSD-2-Clause in commit 6e35c7c, but that the details for test/init.py were left unchanged.

Please could you confirm that test/init.py is licensed under BSD-2-Clause, and perhaps consider making the copyright statements consistent?

Thanks.

Christopher Hoskin

PyPi version number not compliant with PEP 0440?

Hello,

The PyPi package has version 0.7.0_0, whereas this GitHub repository has version 0.7.0. Reading [https://www.python.org/dev/peps/pep-0440/], I'm not convinced that this is a valid version. It says _ can be used as a separator for pre, post, dev and local releases, but the implication seems to be that there should be at least one alphabetic character before the number. In particular, using the VERSION_PATTERN regexp in Appendix B does not produce a match for 0.7.0_0.

(I realise this may sound a bit like mindless pedantry, but I have a reason for asking. I'm the Uploader for the Debian package of pysodium, and the upstream version is used to detect when there is a new upstream release, and to form the Debian version for the package.)

Thanks.

Christopher

crypto_generichash uses wrong type for buffer lengths

The second and fourth parameters are size_t, but they're passed as ctypes.c_uint, causing a crash on 64-bit Windows.

Harmonize the interface of crypto_aead_chacha20poly1305_*

Not all of the crypto_aead_chacha20poly1305_* functions accept None for ad.

Has support:

• crypto_aead_chacha20poly1305_encrypt_detached
• crypto_aead_chacha20poly1305_decrypt_detached

Doesn't have support:

• crypto_aead_chacha20poly1305_encrypt
• crypto_aead_chacha20poly1305_decrypt
• crypto_aead_chacha20poly1305_ietf_encrypt
• crypto_aead_chacha20poly1305_ietf_decrypt

Input range checking

Sodium does not seem to do any range checking on it's inputs, at least in the case of crypto_secretbox. If I pass in an empty key it still returns an encrypted result, which can be decrypted with an empty key. I'd expect an error if the the length of key is not equal to pysodium.crypto_secretbox_KEYBYTES.

nonce = pysodium.randombytes(pysodium.crypto_secretbox_NONCEBYTES)
pysodium.crypto_secretbox(b"some data", nonce, b"")

Additionally, if I pass an arbitrary integer as a nonce, the python interpreter segfaults.

pysodium.crypto_secretbox(b"some data", 0, b"")

Should pysodium be doing these range checks on behalf of sodium?

License?

I don't see a license file here. How is this software licensed?
Thanks!

Python3 support.

There are number of issues with the current implementation that prevent the use of pysodium in python3 applications.

I propose that we detect the python version at runtime and modify the wrapper functions to do the right thing for python2 and python3. Most notably, the message.encode() calls need to be fixed.

crypto_secretbox_open_easy is missing

AttributeError: module 'pysodium' has no attribute 'crypto_secretbox_open_easy'

https://doc.libsodium.org/secret-key_cryptography/secretbox#example

value of crypto_secretstream_xchacha20poly1305_MESSAGEBYTES_MAX bigger than it should be

I need to use pysodium.crypto_secretstream_xchacha20poly1305_MESSAGEBYTES_MAX.value in my code but I found that its value is not quite right.

The libsodium docs say it should be ~256GB and my reading of the libsodium code confirms but pysodium.crypto_secretstream_xchacha20poly1305_MESSAGEBYTES_MAX and pysodium.crypto_secretstream_xchacha20poly1305_MESSAGEBYTES_MAX.value both give me ~18.5EB which is a mite bigger than it should be.

I've got libsodium 1.0.18 (debian flavour) and pysodium 0.7.16 (pypi flavour). Another person confirmed with libsodium/pysodium 1.0.19 / 0.7.16 and a third with pysodium 0.7.16.

[Question] Can this wrapper make use of crypto_secretbox_easy

Sorry if this is a libsodium noob question - According to the libsodium docs crypto_secretbox_easy is the suggested method to use for symmetric encryption.

The _easy and _detached APIs are faster and improve usability by not requiring padding, copying or tricky pointer arithmetic.

Is it possible to use pysodium with crypto_secretbox_easy? Is it intentionally left out or is this something a pull request would be welcome for? If I understand correctly, it's possible to simply not use the _easy functions but it creates a barrier to entry for new users and makes porting code between languages harder without 1 to 1 mappings for libsodium.

hardwiring of struct size causes core dumps

Hey thanks for starting this!

On my box the hash functions cause core dumps. Here's why..

compilers from version to version will compile structures differently, and some types the size of a 'size_t' type might be 4 or 8 bytes.. On my box the

printf("%d\n", sizeof(struct crypto_generichash_blake2b_state));

is 361

I think you have it as 357 or something (hardcoded in python).. python gets very unhappy and core dumps. boo.

I'm not that familiar with ctypes (and sorry you switched from FFI), so I'm not sure if there is a nice way to find the size programmatically. if so use that.. otherwise, making it 361 won't hurt (will just waste a few bytes of space otherwise).

thanks again!

nickg

Expose remaining crypto_core_ ristretto crypto_core_ristretto255_add and crypto_core_ristretto255_sub

Any chance of exposing the remaining crypto_core_ristretto functions from libsoidium in pysodium

crypto_generichash ValueError

# crypto_generichash(m, k=b'', outlen=crypto_generichash_BYTES)
genericHash = pysodium.crypto_generichash(
    m=_password + passwordSalt,
    k=bytes(genericHashKey, 'utf-8'),
    outlen=pysodium.crypto_generichash_BYTES_MAX
)

results in

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3/dist-packages/pysodium/__init__.py", line 441, in crypto_generichash
    __check(sodium.crypto_generichash(buf, ctypes.c_size_t(outlen), m, ctypes.c_ulonglong(len(m)), k, ctypes.c_size_t(len(k))))
  File "/usr/lib/python3/dist-packages/pysodium/__init__.py", line 251, in __check
    raise ValueError
ValueError

how to use a specific algorithm

i'd like to use crypto_box_curve25519xsalsa20poly1305 so i know what i get, but it isn't provided.

crypto_box_seal() request

Could you add wrappers for crypto_box_seal() and crypto_box_seal_open() ?

These were added in libsodium 1.03: https://download.libsodium.org/doc/public-key_cryptography/sealed_boxes.html

/Sune

GIL?

Can you say something about your code and the GIL? Does it release the GIL while doing crypto?

Would be good for multithreaded Python code, so in can use more cores.

test_crypto_generichash fails with libsodium 1.0.13

The test_crypto_generichash test fails when using pysodium with libsodium 1.0.13 (as packaged for Debian Sid):

python -m unittest discover -v
test_AsymCrypto_With_Seeded_Keypair (test.test_pysodium.TestPySodium) ... ok
test_aead_chacha20poly1305 (test.test_pysodium.TestPySodium) ... ok
test_aead_chacha20poly1305_detached (test.test_pysodium.TestPySodium) ... ok
test_aead_chacha20poly1305_ietf (test.test_pysodium.TestPySodium) ... ok
test_crypto_auth (test.test_pysodium.TestPySodium) ... ok
test_crypto_blake2b (test.test_pysodium.TestPySodium) ... ok
test_crypto_box_open (test.test_pysodium.TestPySodium) ... ok
test_crypto_box_open_afternm (test.test_pysodium.TestPySodium) ... ok
test_crypto_box_open_detached (test.test_pysodium.TestPySodium) ... ok
test_crypto_box_pk_from_sk (test.test_pysodium.TestPySodium) ... ok
test_crypto_box_seal (test.test_pysodium.TestPySodium) ... ok
test_crypto_generichash (test.test_pysodium.TestPySodium) ... *** Error in `python': double free or corruption (!prev): 0x0000003da50920b0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x70bfb)[0x7fc7ccd26bfb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76fc6)[0x7fc7ccd2cfc6]
/lib/x86_64-linux-gnu/libc.so.6(+0x7780e)[0x7fc7ccd2d80e]
/usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so(+0x11a03)[0x7fc7cc748a03]
python(+0x138243)[0x3da3a72243]
python(PyEval_EvalFrameEx+0x60c1)[0x3da3a3f671]
python(PyEval_EvalFrameEx+0x5e5f)[0x3da3a3f40f]
python(PyEval_EvalCodeEx+0x255)[0x3da3a37da5]
python(+0x11a5c8)[0x3da3a545c8]
python(PyObject_Call+0x43)[0x3da3a26163]
python(PyEval_EvalFrameEx+0x2eeb)[0x3da3a3c49b]
python(PyEval_EvalCodeEx+0x255)[0x3da3a37da5]
python(+0x11a40e)[0x3da3a5440e]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x12fd7e)[0x3da3a69d7e]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x19071b)[0x3da3aca71b]
python(PyObject_Call+0x43)[0x3da3a26163]
python(PyEval_EvalFrameEx+0x6072)[0x3da3a3f622]
python(PyEval_EvalCodeEx+0x255)[0x3da3a37da5]
python(+0x11a5c8)[0x3da3a545c8]
python(PyObject_Call+0x43)[0x3da3a26163]
python(PyEval_EvalFrameEx+0x2eeb)[0x3da3a3c49b]
python(PyEval_EvalCodeEx+0x255)[0x3da3a37da5]
python(+0x11a40e)[0x3da3a5440e]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x12fd7e)[0x3da3a69d7e]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x19071b)[0x3da3aca71b]
python(PyObject_Call+0x43)[0x3da3a26163]
python(PyEval_EvalFrameEx+0x6072)[0x3da3a3f622]
python(PyEval_EvalCodeEx+0x255)[0x3da3a37da5]
python(+0x11a5c8)[0x3da3a545c8]
python(PyObject_Call+0x43)[0x3da3a26163]
python(PyEval_EvalFrameEx+0x2eeb)[0x3da3a3c49b]
python(PyEval_EvalCodeEx+0x255)[0x3da3a37da5]
python(+0x11a40e)[0x3da3a5440e]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x12fd7e)[0x3da3a69d7e]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x19071b)[0x3da3aca71b]
python(PyObject_Call+0x43)[0x3da3a26163]
python(PyEval_EvalFrameEx+0x6072)[0x3da3a3f622]
python(PyEval_EvalCodeEx+0x255)[0x3da3a37da5]
python(+0x11a5c8)[0x3da3a545c8]
python(PyObject_Call+0x43)[0x3da3a26163]
python(PyEval_EvalFrameEx+0x2eeb)[0x3da3a3c49b]
python(PyEval_EvalCodeEx+0x255)[0x3da3a37da5]
python(+0x11a40e)[0x3da3a5440e]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x12fd7e)[0x3da3a69d7e]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x19071b)[0x3da3aca71b]
python(PyObject_Call+0x43)[0x3da3a26163]
python(PyEval_EvalFrameEx+0x6072)[0x3da3a3f622]
python(PyEval_EvalFrameEx+0x5e5f)[0x3da3a3f40f]
python(PyEval_EvalFrameEx+0x5e5f)[0x3da3a3f40f]
python(PyEval_EvalCodeEx+0x255)[0x3da3a37da5]
python(+0x11a5c8)[0x3da3a545c8]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x12fd7e)[0x3da3a69d7e]
python(PyObject_Call+0x43)[0x3da3a26163]
python(+0x12fac7)[0x3da3a69ac7]
======= Memory map: ========
3da393a000-3da3c55000 r-xp 00000000 fd:01 925115                         /usr/bin/python2.7
3da3e55000-3da3e57000 r--p 0031b000 fd:01 925115                         /usr/bin/python2.7
3da3e57000-3da3ece000 rw-p 0031d000 fd:01 925115                         /usr/bin/python2.7
3da3ece000-3da3ef1000 rw-p 00000000 00:00 0 
3da4ef6000-3da50cb000 rw-p 00000000 00:00 0                              [heap]
7fc7c4000000-7fc7c4021000 rw-p 00000000 00:00 0 
7fc7c4021000-7fc7c8000000 ---p 00000000 00:00 0 
7fc7cb726000-7fc7cb73c000 r-xp 00000000 fd:01 1052156                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7fc7cb73c000-7fc7cb93b000 ---p 00016000 fd:01 1052156                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7fc7cb93b000-7fc7cb93c000 r--p 00015000 fd:01 1052156                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7fc7cb93c000-7fc7cb93d000 rw-p 00016000 fd:01 1052156                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7fc7cb93d000-7fc7cb9aa000 r-xp 00000000 fd:01 920478                     /usr/lib/x86_64-linux-gnu/libsodium.so.18.3.0
7fc7cb9aa000-7fc7cbbaa000 ---p 0006d000 fd:01 920478                     /usr/lib/x86_64-linux-gnu/libsodium.so.18.3.0
7fc7cbbaa000-7fc7cbbab000 r--p 0006d000 fd:01 920478                     /usr/lib/x86_64-linux-gnu/libsodium.so.18.3.0
7fc7cbbab000-7fc7cbbac000 rw-p 0006e000 fd:01 920478                     /usr/lib/x86_64-linux-gnu/libsodium.so.18.3.0
7fc7cbbac000-7fc7cbe0d000 r-xp 00000000 fd:01 920381                     /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
7fc7cbe0d000-7fc7cc00d000 ---p 00261000 fd:01 920381                     /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
7fc7cc00d000-7fc7cc02b000 r--p 00261000 fd:01 920381                     /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
7fc7cc02b000-7fc7cc039000 rw-p 0027f000 fd:01 920381                     /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
7fc7cc039000-7fc7cc03c000 rw-p 00000000 00:00 0 
7fc7cc03c000-7fc7cc09d000 r-xp 00000000 fd:01 920382                     /usr/lib/x86_64-linux-gnu/libssl.so.1.1
7fc7cc09d000-7fc7cc29d000 ---p 00061000 fd:01 920382                     /usr/lib/x86_64-linux-gnu/libssl.so.1.1
7fc7cc29d000-7fc7cc2a1000 r--p 00061000 fd:01 920382                     /usr/lib/x86_64-linux-gnu/libssl.so.1.1
7fc7cc2a1000-7fc7cc2a7000 rw-p 00065000 fd:01 920382                     /usr/lib/x86_64-linux-gnu/libssl.so.1.1
7fc7cc2a7000-7fc7cc2ac000 r-xp 00000000 fd:01 156                        /usr/lib/python2.7/lib-dynload/_hashlib.x86_64-linux-gnu.so
7fc7cc2ac000-7fc7cc4ac000 ---p 00005000 fd:01 156                        /usr/lib/python2.7/lib-dynload/_hashlib.x86_64-linux-gnu.so
7fc7cc4ac000-7fc7cc4ad000 r--p 00005000 fd:01 156                        /usr/lib/python2.7/lib-dynload/_hashlib.x86_64-linux-gnu.so
7fc7cc4ad000-7fc7cc4ae000 rw-p 00006000 fd:01 156                        /usr/lib/python2.7/lib-dynload/_hashlib.x86_64-linux-gnu.so
7fc7cc4ae000-7fc7cc52e000 rw-p 00000000 00:00 0 
7fc7cc52e000-7fc7cc535000 r-xp 00000000 fd:01 921918                     /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4
7fc7cc535000-7fc7cc735000 ---p 00007000 fd:01 921918                     /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4
7fc7cc735000-7fc7cc736000 r--p 00007000 fd:01 921918                     /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4
7fc7cc736000-7fc7cc737000 rw-p 00008000 fd:01 921918                     /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4
7fc7cc737000-7fc7cc756000 r-xp 00000000 fd:01 151                        /usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
7fc7cc756000-7fc7cc955000 ---p 0001f000 fd:01 151                        /usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
7fc7cc955000-7fc7cc956000 r--p 0001e000 fd:01 151                        /usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
7fc7cc956000-7fc7cc95a000 rw-p 0001f000 fd:01 151                        /usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
7fc7cc95a000-7fc7ccb1b000 rw-p 00000000 00:00 0 
7fc7ccb1b000-7fc7cccb6000 r--p 00000000 fd:01 920361                     /usr/lib/locale/locale-archive
7fc7cccb6000-7fc7cce49000 r-xp 00000000 fd:01 1048732                    /lib/x86_64-linux-gnu/libc-2.24.so
7fc7cce49000-7fc7cd049000 ---p 00193000 fd:01 1048732                    /lib/x86_64-linux-gnu/libc-2.24.so
7fc7cd049000-7fc7cd04d000 r--p 00193000 fd:01 1048732                    /lib/x86_64-linux-gnu/libc-2.24.so
7fc7cd04d000-7fc7cd04f000 rw-p 00197000 fd:01 1048732                    /lib/x86_64-linux-gnu/libc-2.24.so
7fc7cd04f000-7fc7cd053000 rw-p 00000000 00:00 0 
7fc7cd053000-7fc7cd156000 r-xp 00000000 fd:01 1048738                    /lib/x86_64-linux-gnu/libm-2.24.so
7fc7cd156000-7fc7cd355000 ---p 00103000 fd:01 1048738                    /lib/x86_64-linux-gnu/libm-2.24.so
7fc7cd355000-7fc7cd356000 r--p 00102000 fd:01 1048738                    /lib/x86_64-linux-gnu/libm-2.24.so
7fc7cd356000-7fc7cd357000 rw-p 00103000 fd:01 1048738                    /lib/x86_64-linux-gnu/libm-2.24.so
7fc7cd357000-7fc7cd370000 r-xp 00000000 fd:01 1048688                    /lib/x86_64-linux-gnu/libz.so.1.2.8
7fc7cd370000-7fc7cd56f000 ---p 00019000 fd:01 1048688                    /lib/x86_64-linux-gnu/libz.so.1.2.8
7fc7cd56f000-7fc7cd570000 r--p 00018000 fd:01 1048688                    /lib/x86_64-linux-gnu/libz.so.1.2.8
7fc7cd570000-7fc7cd571000 rw-p 00019000 fd:01 1048688                    /lib/x86_64-linux-gnu/libz.so.1.2.8
7fc7cd571000-7fc7cd573000 r-xp 00000000 fd:01 1086745                    /lib/x86_64-linux-gnu/libutil-2.24.so
7fc7cd573000-7fc7cd772000 ---p 00002000 fd:01 1086745                    /lib/x86_64-linux-gnu/libutil-2.24.so
7fc7cd772000-7fc7cd773000 r--p 00001000 fd:01 1086745                    /lib/x86_64-linux-gnu/libutil-2.24.so
7fc7cd773000-7fc7cd774000 rw-p 00002000 fd:01 1086745                    /lib/x86_64-linux-gnu/libutil-2.24.so
7fc7cd774000-7fc7cd776000 r-xp 00000000 fd:01 1048736                    /lib/x86_64-linux-gnu/libdl-2.24.so
7fc7cd776000-7fc7cd976000 ---p 00002000 fd:01 1048736                    /lib/x86_64-linux-gnu/libdl-2.24.so
7fc7cd976000-7fc7cd977000 r--p 00002000 fd:01 1048736                    /lib/x86_64-linux-gnu/libdl-2.24.so
7fc7cd977000-7fc7cd978000 rw-p 00003000 fd:01 1048736                    /lib/x86_64-linux-gnu/libdl-2.24.so
7fc7cd978000-7fc7cd990000 r-xp 00000000 fd:01 1086737                    /lib/x86_64-linux-gnu/libpthread-2.24.so
7fc7cd990000-7fc7cdb8f000 ---p 00018000 fd:01 1086737                    /lib/x86_64-linux-gnu/libpthread-2.24.so
7fc7cdb8f000-7fc7cdb90000 r--p 00017000 fd:01 1086737                    /lib/x86_64-linux-gnu/libpthread-2.24.so
7fc7cdb90000-7fc7cdb91000 rw-p 00018000 fd:01 1086737                    /lib/x86_64-linux-gnu/libpthread-2.24.so
7fc7cdb91000-7fc7cdb95000 rw-p 00000000 00:00 0 
7fc7cdb95000-7fc7cdbb8000 r-xp 00000000 fd:01 1048725                    /lib/x86_64-linux-gnu/ld-2.24.so
7fc7cdbdd000-7fc7cdc9d000 rw-p 00000000 00:00 0 
7fc7cdcce000-7fc7cdd92000 rw-p 00000000 00:00 0 
7fc7cddb3000-7fc7cddb4000 rw-p 00000000 00:00 0 
7fc7cddb4000-7fc7cddb5000 rwxp 00000000 00:00 0 
7fc7cddb5000-7fc7cddb8000 rw-p 00000000 00:00 0 
7fc7cddb8000-7fc7cddb9000 r--p 00023000 fd:01 1048725                    /lib/x86_64-linux-gnu/ld-2.24.so
7fc7cddb9000-7fc7cddba000 rw-p 00024000 fd:01 1048725                    /lib/x86_64-linux-gnu/ld-2.24.so
7fc7cddba000-7fc7cddbb000 rw-p 00000000 00:00 0 
7ffe9df70000-7ffe9df91000 rw-p 00000000 00:00 0                          [stack]
7ffe9df9a000-7ffe9df9c000 r--p 00000000 00:00 0                          [vvar]
7ffe9df9c000-7ffe9df9e000 r-xp 00000000 00:00 0                          [vdso]
Aborted

Thanks.

Stale Python Pakcage index (2016-06-02)

Could you update the python package index with the latest from master?

I'd really like to use the crypto_auth functions and it looks like the index hasn't been updated since 2016-06-02 (the functions were merged into master at commit b7e60d8 => Jun 27, 2016)

crypto_aead _NPUBBYTES vs. _NONCEBYTES

The constant added in #78 is crypto_aead_xchacha20poly1305_ietf_NPUBBYTES while the other AEAD variants have _NONCEBYTES. It would be nice if they were consistent. Maybe either rename the new one to be consistent or add _NPUBBYTES copies (to avoid breakage) of the old ones since that is what libsodium uses?

Do you need statealign in generichash?

I'm not familiar with the libsodium API yet, but on my OS the generichash functions fail with a segfault because you're doing a bit of weird pointer math to convert state pointers to statealign? Never seen this, but here's a diff that seems to make it run clean on my OSX system:

--- a/pysodium/__init__.py
+++ b/pysodium/__init__.py
@@ -163,24 +163,18 @@ def crypto_generichash(m, k=b'', outlen=crypto_generichash_BYTES):
 #crypto_generichash_init(crypto_generichash_state *state, const unsigned char *key, const size_t keylen, const size_t outlen);
 def crypto_generichash_init(outlen=crypto_generichash_BYTES, k=b''):
     state = ctypes.create_string_buffer(crypto_generichash_state)
-    statealign = ctypes.addressof(state) + 63
-    statealign ^= statealign & 63
-    sodium.crypto_generichash_init(statealign, k, ctypes.c_size_t(len(k)), ctypes.c_size_t(outlen))
+    sodium.crypto_generichash_init(state, k, ctypes.c_size_t(len(k)), ctypes.c_size_t(outlen))
     return state

 #crypto_generichash_update(crypto_generichash_state *state, const unsigned char *in, unsigned long long inlen);
 def crypto_generichash_update(state, m):
-    statealign = ctypes.addressof(state) + 63
-    statealign ^= statealign & 63
-    sodium.crypto_generichash_update(statealign, m, ctypes.c_ulonglong(len(m)))
+    sodium.crypto_generichash_update(state, m, ctypes.c_ulonglong(len(m)))
     return state

 #crypto_generichash_final(crypto_generichash_state *state, unsigned char *out, const size_t outlen);
 def crypto_generichash_final(state, outlen=crypto_generichash_BYTES):
-    statealign = ctypes.addressof(state) + 63
-    statealign ^= statealign & 63
     buf = ctypes.create_string_buffer(outlen)
-    sodium.crypto_generichash_final(statealign, buf, ctypes.c_size_t(outlen))
+    sodium.crypto_generichash_final(state, buf, ctypes.c_size_t(outlen))
     return buf.raw

 def randombytes(size):

I imagine I'm not familiar with ctypes or libsodium enough to know why you did this, so rather than a pull request I'll just submit this diff and let you figure out the next step.

crypto_aead_chacha20poly1305_decrypt

crypto_aead_chacha20poly1305_decrypt

'ad' can't be 'None'.
When 'ad' is 'None', it crash.
"TypeError: object of type 'NoneType' has no len()"

Newly added functions lack version checks

Some of the constants/functions added in bca3999 do not exist in earlier versions of libsodium, like the one I have from Ubuntu 16.04, which is version 1.0.8. I get an error like:

  File "pysodium/__init__.py", line 144, in <module>
    crypto_pwhash_scryptsalsa208sha256_BYTES_MIN = sodium.crypto_pwhash_scryptsalsa208sha256_bytes_min()
  File "/usr/lib/python2.7/ctypes/__init__.py", line 375, in __getattr__
    func = self.__getitem__(name)
  File "/usr/lib/python2.7/ctypes/__init__.py", line 380, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /usr/lib/x86_64-linux-gnu/libsodium.so.18: undefined symbol: crypto_pwhash_scryptsalsa208sha256_bytes_min

I don't have time to figure out each of them at the moment or I would have tried to make a PR.

scrypt KDF / password hashing not made available in Python

pysodium seems to be missing wrappers for the functions documented at http://doc.libsodium.org/password_hashing/index.html

crypto_auth and crypto_auth_verify use empty byte string as a key by default

I wonder is there a reason why crypto_auth and crypto_auth_verify accept key which is empty byte string by default? Doesn't usage of empty string as a key defeat the purpose of authentication since everyone can make a valid authentication tag for a tampered message?

Official documentation says

The crypto_auth() function computes a tag for the message in, whose length is inlen bytes, and the key k. k should be crypto_auth_KEYBYTES bytes. The function puts the tag into out. The tag is crypto_auth_BYTES bytes long.

(emphasis is mine)

Missing method

Is it possible that keypair derivation (crypto_box_seed_keypair in libsodium) is not implemented yet?
crypto_box is equivalent to crypto_box_easy in libsodium?

Thanks in advance!

cant find libsodium.dll on windows

Hi I was having some trouble using your wrapper on windows. I installed the sodium dll in multiple places but ctypes.cdll.LoadLibrary would always return None. I saw a couple of other people having this problem on windows as well. I added the following few lines to the top of your file to search the system path. Thanks

import ctypes
import ctypes.util
import sys
import os
import platform

if platform.system() == 'Windows':
    if platform.machine() == 'AMD64':
        sodium_dll = 'libsodium-64.dll'
    else:
        sodium_dll = 'libsodium.dll'
    def find_libsodium():
        for path in sys.path:
            filename = os.path.join(path, sodium_dll)
            if os.path.isfile(filename):
                return filename
    sodium_path = find_libsodium()
    if not sodium_path:
        raise ValueError('Unable to find libsodium')
    sodium = ctypes.cdll.LoadLibrary(sodium_path)
else:
    sodium = ctypes.cdll.LoadLibrary(ctypes.util.find_library('sodium') or ctypes.util.find_library('libsodium'))

Python 3 support (revisited)

Python 3 is becoming much more common.

Also the pysodium3 mentioned in ticket #2 does not exist (any more).

I've just given it a try by installing the GitHub master, and it installed just fine via python3 setup install, and the 11 unit tests also ran fine using nosetests3.

Personally, I have only done a very brief test of the module itself, but it did import in the interactive Python3 shell, and getting random numbers has worked as well.

According to the revision history, a commit 5cd2f4a20d72fb31655908d0e6a05c6204abe4ab was supposed to provide some Py3 support.

It would be nice if this package could also be made available to PyPI, which currently only hosts version 0.6.5.1 for Python 2.x.