Re: [dev] securiy guidance

From: Thomas Levine <>
Date: Mon, 05 Mar 2018 23:57:16 +0000

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 available. For example, OpenBSD 6.2
provides blowfish. Also, GnuPG libgcrypt is far more involved than you
require, but it is still appropriately licensed.

I can't help myself from adding to the distracting tangents.

pw by Dashamir Hoxha has some of the features of present discussion.

It is derived from password-store.

It stores passwords in an encrypted tarball instead of inside the normal
filesystem. Like pass-tomb, this has the effect that file hierarchy
doesn't show up in the filesystem.

It still uses gpg, but it forces a particular simplified style of usage
that should be very easy for many people to learn: Only gpg symmetric
encryption is allowed, so you do not need to understand the concept of
asymmetric cryptography; also, it includes in a shell that remembers
the decryption password, so you can have it remember your password
without relying on gpg-agent being properly installed, and you can
easily have it forget your password without understanding that gpg-agent
exists. This is technically still gpg, but the encryption software could
easily be replaced by something else, like encrypted zip files, the user
doesn't need to know that it is gpg.

Another alternative is to rely on filesystem encryption. For example,
you could use tomb without password-store. I once used used normal,
cleartext files in an encrypted vnd device (You could use tomb for that
as well.) that I mounted and umounted. The point is that you wouldn't
need gpg. You might write some utilities that mount and umount the
device and ensure correct permissions.
Received on Tue Mar 06 2018 - 00:57:16 CET

This archive was generated by hypermail 2.3.0 : Tue Mar 06 2018 - 01:00:23 CET