On 2018-03-06, pet...@riseup.net wrote:
> On 2018-03-06 10:01, Truls Becken wrote:
>> Some libraries to look at are; libressl, libtomcrypt, nacl.cr.yp.to,
>> libsodium, nettle, libgcrypt and libmcrypt.
>
> Hello Truls,
>
> thank you for this list. I was hoping there would be a publicly
> available
On 2018-03-06 10:01, Truls Becken wrote:
> Some libraries to look at are; libressl, libtomcrypt, nacl.cr.yp.to,
> libsodium, nettle, libgcrypt and libmcrypt.
Hello Truls,
thank you for this list. I was hoping there would be a publicly
available algo that could be inlined in the source since I rea
Hi Thomas,
On 2018-03-06 00:57, Thomas Levine wrote:
> If you copy (vendor) an encryption/decryption algorithm into your source
> code, then you are relying on more than libc. So perhaps you could
> expand your dependencies to libraries with acceptable licensing or
> to libraries that are widely a
> So yes, the entire password store should be kept in one encrypted file
> and so it can be opened and closed.
And then merges become a total pain. You might as well use Keepass.
Some libraries to look at are; libressl, libtomcrypt, nacl.cr.yp.to,
libsodium, nettle, libgcrypt and libmcrypt.
