2017-02-25 20:24 GMT+01:00 Alexander Ilin :
> Thanks for the links to those who replied. I agree that the proper way
> seems to be to store the encryption key in a malloc'd buffer, which would
> take it out of reach of the GC.
That's a very interesting question. Clearly, you need to allocate
Hello!
I have successfully used Argon2 after building it from source
(https://github.com/P-H-C/phc-winner-argon2/releases/tag/20161029).
I'm only interested in one function - argon2i_hash_raw - but I may contribute
it as a stub in case someone wants to expand the FFI.
I use it to derive an
Check this article
http://factor-language.blogspot.com/2009/08/new-tool-for-locating-external-resource.html?m=1
might help managing object lifetimes and clean up.
On Feb 24, 2017 4:21 PM, "John Benediktsson" wrote:
I'm not aware of any libsodium bindings, but that should be pretty easy to
do wit
I'm not aware of any libsodium bindings, but that should be pretty easy to
do with the ``alien`` FFI vocabulary.
Also, related, is you can call any C function you want, and then hold onto
its return result as an alien pointer, so essentially unmanaged memory. If
you were to convert that memory in
Hello!
Two questions:
1 - do we have bindings to the libsodium library?
2 - is it possible to make sure a chunk of memory doesn't get copied by the
GC?
The first question is about this project that's gaining well-deserved
traction: https://download.libsodium.org/doc/
The second questi
