5

I have a single text file I want to encrypt. I can easily do so with any common software. But then, I want to be able to click on it, provide a password, and be able to read, edit, and close it. All from the GUI, which should be KDE-compatible, and possibly the editor should be Kate. Ideally, this should be available in a single KRunner call. Alternative CLI approach are OK but should be contained in a single command/function/alias.

A possibility could be to create an encrypted folder. Then mount the folder only at access-time and unmount immediately after the closure of the text editor, all in a single CLI command. It looks a bit hackish to me tho, and I'd prefer to do the call from KRunner only.

To summarize, following the ArchWiki a bit:

  • I want to protect a single file in case my PC gets stolen. Of course professional data miners will get to it eventually, I accept that.
  • The file should be accessible (read/write access) with a passphrase on-the-fly (on-demand)
  • GUI methods are preferred but CLI methods are OK too, as long as they can be called with a .desktop file (to be accessed via KRunner)
  • I don't have a preferred encryption method, as long as it's decently fast, secure and open-source.
  • Structure and filenames of the encrypted folder (if this is the only way) can be transparent, as long as the content is inaccessible.
  • Any encryption method is accepted, as long as it does not take minutes to verify a key, for example
AF7
  • 790
  • 1
  • 7
  • 19
  • So you want to use EncFS, optionally with a GUI like cryptkeeper (I think that's the name), or eCryptFS? There are lots of guides for those, the ArchWiki you linked is excellent. Why not just use them? – Xen2050 Feb 23 '15 at 04:38
  • 1
    I use `vim` with a `gnupg` plugin. you need to have a GPG key for this. – wurtel Feb 23 '15 at 08:49
  • @Xen2050 : Not necessarily EncFS. Whatever works well is OK. I can generate GPG keys. I have yet to try Cryptkeeper, but by looking at it I'd already say: (1) It is GTK, which won't integrate well with KDE. (2) I'd prefer if the file access was more immediate: with CryptKeeper it looks like I have to click icon, mount, open file, edit, click icon, dismount. Also - I don't use a system tray! At wurtel : I cannot use vim as this has to be available also for people who don't know vim. – AF7 Feb 23 '15 at 11:40
  • @Xen2050 I want to stress the fact that I don't need help in setting up the encryption, but in choosing the encryption method (and commands to call it, call editor and call it again after closure of the editor, all automatically) which will allow me to have a 1-click -> insert password -> edit -> be done with it (and unmount the encryption) approach. – AF7 Feb 23 '15 at 11:54
  • Another possibility would be to use EXT4's FS encryption, which was introduced with kernel 4.1 and in 4.4 should be quite reliable. http://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level-encryption.html https://wiki.archlinux.org/index.php/Ext4#Using_ext4_per_directory_encryption – AF7 Dec 07 '15 at 11:16

2 Answers2

3

For just one file at a time, or the very occasional file, I think a whole encrypted drive or home with EncFS/eCryptFS/dm-crypt/LUKS would be overkill (but would work excellent in case of theft).

A solution using a bash function to decrypt, edit, re-encrypt sounds more like what you're looking for. Using gpg since it's installed by default on almost every linux I've seen, and has been around for decades & should be for decades more so looks suitable for long term archives. Something like this could be put into a .bashrc file & used in a terminal, or incorporated into a file manager's "right-click" menu should work too (I'm not familiar enough with KDE to do that, but if you are it shouldn't be terribly difficult).

These quick little functions will take the first argument $1 as a filename to decrypt to /tmp/gpg-edit.out (can use a tmpfs/ramdisk for better security), edit with gedit (or your favourite editor), and re-encrypt the file when you're done editing. They use a "passphrase-file" where only the first line is read & used as a passphrase, so it should be kept somewhere secure (tmpfs/ramdisk perhaps) but you could omit that & gpg would ask you for the passphrase each time.

edit-gpg() {
gpg -v --no-use-agent --passphrase-file=/path/to/keyfile --output "/tmp/gpg-edit.out" "$1" &&
gedit "/tmp/gpg-edit.out" &&
gpg -v --no-use-agent --cipher-algo AES256 --passphrase-file=/path/to/keyfile --output "$1" -c "/tmp/gpg-edit.out" &&
rm "/tmp/gpg-edit.out"
}

Future To-Do's would include a check if the "/tmp/gpg-edit.out" file already exists (now gpg will ask to overwrite if it does).
Or use a random output file so you could edit multiple files at once. For now, it's one at a time.
Omitting --no-use-agent should have it use gpg's GUI passphrase entry box, but the last time I left out the option it would always use the GUI box and ignore the --passphrase-file option.

Another short function can initially encrypt a file with the same passphrase-file:

crypt-gpg() { 
gpg -v --no-use-agent --cipher-algo AES256 --passphrase-file=/path/to/keyfile -c "$1" &&
rm "$1"
}
Xen2050
  • 2,211
  • 15
  • 15
  • Excellent answer, thanks. I will implement to fit my use case and will probably end up creating a Dolphin service menu. – AF7 Feb 23 '15 at 20:05
  • welcome :) FYI, this uses symmetric gpg encryption (`-c`), can use `-e` for secret key encryption. Be sure to do some testing with your chosen editor (I'm guessing it's not gedit in KDE), if I've already got one gedit running, then start another from the command line, it only opens the file in a new tab of the already running gedit, returning exit code 0 (success/true) and continuing the script/function before any editing has been done. – Xen2050 Feb 23 '15 at 20:50
  • This also happens with Kate, for example. A new Kate call only opens a new tab, and a forcing a new window does NOT execute a new Kate instance. According to Kate's official blog this is probably going to change in the near future (in KF5) by just launching a new instance if a separate window is requested. By the way, Kate already offers this behaviour by using the -n switch, so all should be fine. – AF7 Feb 24 '15 at 08:07
  • If the file is not big, I would consider using /dev/shm (a ramdisk) instead of /tmp, so that way unencrypted file contents are never written to disk. Some distros mount /tmp as a ramdisk, but others don't; if /tmp is part of your root filesystem and your file gets written to disk unencrypted, then your security is toast. – Hitechcomputergeek Jul 24 '19 at 06:46
1

Emacs lets you edit files ending in .gpg transparently.

1) $ emacs yourfile.txt.gpg

2) Edit your file.

3) C-x C-s to save, click [OK] or C-c C-c to select symmetric encryption. Then enter and confirm your password.

4) C-x C-c to close Emacs.

The file is now encrypted. To edit it again, follow the same process as above.

nanny
  • 296
  • 1
  • 7
  • This is also an excellent way to do it. I did not know this capability of Emacs. In my case I want to be able to generalize the procedure to different editors, tho. – AF7 Feb 23 '15 at 20:06