I started implementing LuaJIT FFI bindings to Nettle, and I found that
nettle_pbkdf2_hmac_sha1 and nettle_pbkdf2_hmac_sha256
sometimes return longer dst than what was requested. See:
https://github.com/bungle/lua-resty-nettle/blob/master/lib/resty/nettle/pbkd...
I had to put ":sub(1, len)" to overcome that.
Is it by a design or is it a bug (maybe in my code?).
Regards Aapo
Aapo Talvensaari aapo.talvensaari@gmail.com writes:
sometimes return longer dst than what was requested. See:
https://github.com/bungle/lua-resty-nettle/blob/master/lib/resty/nettle/pbkd...
I had to put ":sub(1, len)" to overcome that.
How does ffi_str work? You're aware that the output is binary data, with no NUL-termination?
If it is a bug in nettle, it would help if you could provide a minimal C program that let's me reproduce the problem.
Regards, /Niels
On Tue, Jun 10, 2014 at 11:38 AM, Niels Möller nisse@lysator.liu.se wrote:
Aapo Talvensaari aapo.talvensaari@gmail.com writes:
sometimes return longer dst than what was requested. See:
https://github.com/bungle/lua-resty-nettle/blob/master/lib/resty/nettle/pbkd...
I had to put ":sub(1, len)" to overcome that.
How does ffi_str work? You're aware that the output is binary data, with no NUL-termination?
:-). It was a bug in my code. I have fixed it now (I had used this function in many places correctly but here I happened to get it wrong).
ffi.string (ffi_str) is defined as follows: str = ffi.string(ptr [,len])
If the optional argument len is missing, ptr is converted to a "char *" and the data is assumed to be zero-terminated. The length of the string is computed with strlen().
Thanks for getting me back on a right track.
Regards Aapo
nettle-bugs@lists.lysator.liu.se
-
Aapo Talvensaari -
nisse＠lysator.liu.se