fix sodium constant type (size_t instead of ulong_long)

[paddor]

It seems like libsodium exposes all constants as size_t (I checked at least the files src/libsodium/crypto_box/curve25519xsalsa20poly1305/box_curve25519xsalsa20poly1305_api.c and src/libsodium/crypto_generichash/blake2/generichash_blake2_api.c of libsodium). So this FFI declaration seems wrong and is probably the reason for issue #112.

I haven't actually tested this. @patte Could you test this on your Raspberry Pi?

@tarcieri Does this sound plausible? I don't know a lot about C.

[jedisct1]

unsigned long long is used for plaintext & ciphertext lengths. This is utterly annoying, but required to retain binary compatibility with NaCl.
size_t is used everywhere else to represent the size of an object.

[Asmod4n]

For me it looks like ulong_long is used where something can come from a external source and size_t is used when it happens on the local machine.

[paddor]

@jedisct1 I don't get it. The libsodium source says size_t in this case. See https://github.com/jedisct1/libsodium/blob/master/src/libsodium/crypto_box/curve25519xsalsa20poly1305/box_curve25519xsalsa20poly1305_api.c#L8.

Why does rbnacl have to use ulong_long here?

[patte]

@paddor
I tested your fork on the raspberry and I can confirm that it works! nicely done!
Here the versions I used:
zmq (4.0.4)
celluloid (0.16.0 e42a6b3) (paddor/celluloid)
celluloid-io (0.16.0 567b769) (paddor/celluloid-io)
celluloid-zmq-zap (0.0.1)
rbnacl (3.1.2 00de2f7)
rbnacl-libsodium (1.0.0)

[paddor]

@tarcieri @jedisct1 Any updates here?

[tarcieri]

@paddor I haven't had time to investigate this in-depth but it would seem this change doesn't actually honor the libsodium type signatures and changing it to :size_t across the board could cause (potentially invisible) breakages.

This seems like something that needs to be handled with care.

[Asmod4n]

All constants in NaCl and libsodium are of type size_t @tarcieri
Von einem mobilen Gerät gesendet

Am 08.10.2014 um 03:56 schrieb Tony Arcieri notifications@github.com:

@paddor I haven't had time to investigate this in-depth but it would seem this change doesn't actually honor the libsodium type signatures and changing it to :size_t across the board could cause (potentially invisible) breakages.

This seems like something that needs to be handled with care.

—
Reply to this email directly or view it on GitHub.

[paddor]

@tarcieri Thanks for the answer. Your concerns make sense, of course.

I just logged the usage of the method #sodium_constant to see for what constants it's used. I ended up with this list:

crypto_box_curve25519xsalsa20poly1305_noncebytes
crypto_box_curve25519xsalsa20poly1305_zerobytes
crypto_box_curve25519xsalsa20poly1305_boxzerobytes
crypto_box_curve25519xsalsa20poly1305_beforenmbytes
crypto_box_curve25519xsalsa20poly1305_publickeybytes
crypto_box_curve25519xsalsa20poly1305_secretkeybytes
crypto_secretbox_xsalsa20poly1305_keybytes
crypto_secretbox_xsalsa20poly1305_noncebytes
crypto_secretbox_xsalsa20poly1305_zerobytes
crypto_secretbox_xsalsa20poly1305_boxzerobytes
crypto_sign_ed25519_seedbytes
crypto_sign_ed25519_publickeybytes
crypto_sign_ed25519_secretkeybytes
crypto_sign_ed25519_bytes
crypto_onetimeauth_poly1305_bytes
crypto_onetimeauth_poly1305_keybytes
crypto_hash_sha256_bytes
crypto_hash_sha512_bytes
crypto_generichash_blake2b_bytes_min
crypto_generichash_blake2b_bytes_max
crypto_generichash_blake2b_keybytes_min
crypto_generichash_blake2b_keybytes_max
crypto_pwhash_scryptsalsa208sha256_saltbytes
crypto_auth_hmacsha256_bytes
crypto_auth_hmacsha256_keybytes
crypto_auth_hmacsha512256_bytes
crypto_auth_hmacsha512256_keybytes

I just git grep -B1'd all of them in the libsodium sources and can confirm that they're all of type size_t.

[tarcieri]

@paddor thanks for doing that! @jedisct1 I'm confused what you were talking about then.

Going to go ahead and merge this...

[paddor]

@tarcieri No problem, and thanks!