Re: [Factor-talk] Security Applications

2017-02-28 Thread Björn Lindqvist
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 a
buffer for it outside the gc-managed heap. But I wonder if that is
sufficient. Freeing doesn't clear the buffer, and if you malloc again,
the buffer can be reused for that allocation. Clearing with memset
could also fail to get rid of the data if the memory system decides to
play optimization tricks.


-- 
mvh/best regards Björn Lindqvist

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk


Re: [Factor-talk] Security Applications

2017-02-25 Thread Alexander Ilin
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 encryption key from a user-supplied password.

  https://en.wikipedia.org/wiki/Argon2

  I'm also planning to use blake2b for hashing, although currently I'm thinking 
about merely calling an external executable, not linking to a library.

  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.

---=--- 
 Александр

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk


Re: [Factor-talk] Security Applications

2017-02-25 Thread Mike Maul
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 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 into a Factor object (like byte-array or
struct), probably that would copy the memory and be subject to GC.  I'd
have to look into it, but maybe struct pointers would allow convenient use
from Factor while also keeping the memory separate.



On Fri, Feb 24, 2017 at 3:12 AM, Alexander Ilin  wrote:

> 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 question is about a piece of memory that's supposed to hold a
> secret key, and I want to make sure it only ever exists in one copy, so
> that if I erase it, it's really gone. AFAIR in Factor we have a copying GC,
> so I'd like to somehow exempt this key from its processing (mark it
> non-moveable, or something). Do we have a provision for such a use case,
> and if not what would be a good way to achieve what I want in Factor?
>
> ---=---
>  Александр
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk


Re: [Factor-talk] Security Applications

2017-02-24 Thread John Benediktsson
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 into a Factor object (like byte-array or
struct), probably that would copy the memory and be subject to GC.  I'd
have to look into it, but maybe struct pointers would allow convenient use
from Factor while also keeping the memory separate.



On Fri, Feb 24, 2017 at 3:12 AM, Alexander Ilin  wrote:

> 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 question is about a piece of memory that's supposed to hold a
> secret key, and I want to make sure it only ever exists in one copy, so
> that if I erase it, it's really gone. AFAIR in Factor we have a copying GC,
> so I'd like to somehow exempt this key from its processing (mark it
> non-moveable, or something). Do we have a provision for such a use case,
> and if not what would be a good way to achieve what I want in Factor?
>
> ---=---
>  Александр
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk


[Factor-talk] Security Applications

2017-02-24 Thread Alexander Ilin
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 question is about a piece of memory that's supposed to hold a 
secret key, and I want to make sure it only ever exists in one copy, so that if 
I erase it, it's really gone. AFAIR in Factor we have a copying GC, so I'd like 
to somehow exempt this key from its processing (mark it non-moveable, or 
something). Do we have a provision for such a use case, and if not what would 
be a good way to achieve what I want in Factor?

---=--- 
 Александр

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk