This should start a good arg...., sorry, discussion going! :-)
I currently store various bits of sensitive information in files encrypted using my editor's (my editor is vile) 'crypt' option. This uses the system's crypt() function to encrypt/decrypt the files. The big advantage is simplicity, I simply do:- vi -k <password> file and the file is automatically decrypted and encrypted for me.
There are some weaknesses though, crypt() isn't very secure (but see below, it's not *that* bad) and the password floats around in RAM and the environment. So I have been looking for improvements but I want to keep a simple interface. So what I have found so far (including the existing scheme) are as follows:-
Existing Scheme ===============
The vile editor using the -k command line option. The password is possibly visible to someone who has access to my machine while I'm using it but that's a fairly unlikely scenario. In addition the non-alphanumeric characters I have in my passwords mess up the dispay somewhat. The crypt() encryption isn't very secure *but* it's actually not easy to brute force. I tried encryption breaking tools like unixcrypt-breaker and they only work if the 'statistics' files have stuff quite similar to what you're decrypting. Since the files I have encrypted are fairly random (very few actual words in there) the encryption breaking generally produces rubbish. The only case where it came up with one approximate hit was where I had put a password string repeatedly in the statistics files which was also on the file to decrypt (thinks, vary my passwords more!).
Use an encfs file system ========================
This is fairly simple, I already use it for some other storage, it wouldn't be too difficult to write a wrapper script for my editor to simplify usage. It uses the AES cipher, 192 or 256 bits. There are some reports that it needs updating to be really secure in the modern environment but it's probably 'good enough'.
Use 'pass' with a GnuPG key ===========================
The 'pass' program is effectively a wrapper script that makes it easy to use a GPG key for encrypting files. I've played with it a bit and (once I'd worked out how to generate my GPG key) it was pretty simple to use and provides me with the sort of interface I want. This thus gives a choice of key types and sizes.
The object of the exercise (encrypted files) is to keep important, confidential things safe but easy to access. In particular I have electronic banking details and such in one file, that's probably the most sensitive one. Ease of access is important, as is portability, I need to use this on more than one computer. A USB stick is *not* the answer for me, I'll lose the stick! The big advantage of the 'existing scheme' is simple portability as it's just part of the editor I use everywhere. It's to protect against people finding out my passwords etc., the computers with the files on are reasonably secure (as in unlikely to be stolen). I guess the most likely thing to happen is someone getting access to the files so the most important thing is to be sure that the encryption is difficult to break.
So - what to choose?
I think my feeling is that the choice is between 'do nothing' (vi plus crypt()) and 'pass' with a GnuPG key. What does the team think?
On Friday 16 Jan 2015 19:32:20 Chris Green wrote:
The big advantage is simplicity, I simply do:- vi -k <password> file and the file is automatically decrypted and encrypted for me.
If you are using Vim, then you could try the gpg plugin: https://github.com/jamessan/vim-gnupg
This plugin transparently en/decrypts files ending in .gpg, .pgp or .asc with GnuPG. Also, together with gpg-agent you won't have to type in the password every time you open the file (within a certain time limit).
Just a thought. Th
On Fri, Jan 16, 2015 at 07:51:52PM +0000, tehpeh-alug@tty1.net wrote:
On Friday 16 Jan 2015 19:32:20 Chris Green wrote:
The big advantage is simplicity, I simply do:- vi -k <password> file and the file is automatically decrypted and encrypted for me.
If you are using Vim, then you could try the gpg plugin: https://github.com/jamessan/vim-gnupg
This plugin transparently en/decrypts files ending in .gpg, .pgp or .asc with GnuPG. Also, together with gpg-agent you won't have to type in the password every time you open the file (within a certain time limit).
Sorry, I don't use vim, as I said I use vile.
On Fri, Jan 16, 2015 at 07:32:20PM +0000, Chris Green wrote:
Use 'pass' with a GnuPG key
The 'pass' program is effectively a wrapper script that makes it easy to use a GPG key for encrypting files. I've played with it a bit and (once I'd worked out how to generate my GPG key) it was pretty simple to use and provides me with the sort of interface I want. This thus gives a choice of key types and sizes.
I've just realised that the (much hyped?) security of using a GPG Key is totally pointless in my usage. The key itself is *way* weaker than the encryption it provides. So, there's no chance of anyone cracking one of the files, but *much* more chance of someone cracking the encrypted key itself. A GPG Key makes sense where the key itself is kept safe and separate from the things it's used to protect but when they're together it's just another layer of useless complexity. I may as well encode the files themselves with the same algorithm that's used for the pass-phrase on the key.
On Sat, Jan 17, 2015 at 12:24:01PM +0000, Chris Green wrote:
On Fri, Jan 16, 2015 at 07:32:20PM +0000, Chris Green wrote:
Use 'pass' with a GnuPG key
The 'pass' program is effectively a wrapper script that makes it easy to use a GPG key for encrypting files. I've played with it a bit and (once I'd worked out how to generate my GPG key) it was pretty simple to use and provides me with the sort of interface I want. This thus gives a choice of key types and sizes.
I've just realised that the (much hyped?) security of using a GPG Key is totally pointless in my usage. The key itself is *way* weaker than the encryption it provides. So, there's no chance of anyone cracking one of the files, but *much* more chance of someone cracking the encrypted key itself. A GPG Key makes sense where the key itself is kept safe and separate from the things it's used to protect but when they're together it's just another layer of useless complexity. I may as well encode the files themselves with the same algorithm that's used for the pass-phrase on the key.
Using 'gpg --symmetric <filename>' makes *much* more sense for encrypting files that you're going to keep on a machine where you probably have your keyring as well. You can specify the cipher you want to use and there's nothing to brute-force to get at the password, it isn't stored anywhere. With the separate key protected by a passphrase there's an obvious thing to attack.
-
Chris Green -
tehpeh-alug＠tty1.net