encrypting a single directory?

[Spanik]

I have a couple of directories that I'd like to encrypt. Just some very personal stuff that I'd like to keep (and sometimes look through) for sentimental reasons. But things that I prefer not to be seen and read after I pop off.

Now most of the methods I find are for encryption of whole disks that then automatically decrypt when you log on. Which is not exactly what I want. I'd prefer something that needs a key whenever I want to access the directory (even to list the content). I prefer to encrypt single directories so I can keep my organisation scheme of documents: texts, photos, recordings... Also there is lots of materials on this pc that I want to be available to those after me. There are lots of family related documents and photos that I would like them to find.

If there are good ways to do this but only with a complete partition or disk then ok, so be it. Certainly if it is easier to set up and using software available in Gentoo.

[pingtoo]

Spanik,

I don't know if such tool exist, but I have an idea that may help, If you create a single file then loop mount to where you usually access (possible setup automount too).

This way you only need to do one encryption. And it is possible to follow those that do whole disk encryption and possible to use some kind of file manager/browser tool to automate the viewing pleasure.

[pietinger]

Spanik,

I am using fscrypt ... it is encryption for directories and not for blocklevel ... this works not with every filesystem (look into the help in "make menuconfig" for fscrypt) ... I even made a german installation guide:
viewtopic-p-8629644.html#8629644

If you want directories other than your /home it is even easier, because you dont need the whole pam directions ... and of course you choose 2 instead 1 when you where asked:

Code: Select all

The following protector sources are available:
1 - Your login passphrase (pam_passphrase)
2 - A custom passphrase (custom_passphrase)
3 - A raw 256-bit key (raw_key)

[sMueggli]

There is the tool VeraCrypt where you can encrypt specific folders.

[eeckwrk99]

Tomb

Tomb is a 100% free and open source tool that facilitates managing secret files in volumes protected by strong encryption.

Well documented, still maintained.

[Goverp]

Spanik,

I am using fscrypt ... it is encryption for directories and not for blocklevel ...

I also use fscrypt.
While it encrypts directories, they are not containers - that's to say that files within the directory as still separate items (inodes) in the file system (as distinct from say an encrypted zip archive). fscrypt encrypts each file you put in the directory with the same key as the directory, so you get the security you want.
However, you should be aware that the encryption goes with the file, so if you move that file to say a USB key for backup, or to a non-encrypted folder, it remains encrypted, with the same key. Generally this is what you might want, but it can have surprising results. For example, my system has my home directory encrypted, and set to be unlocked by my sign-on password. I created and tested a shell script, and when happy, moved it to /usr/local/bin. I tested it later from a different userid (while I was still signed on with my main userid), no problem. Later, I used the second userid without logging on as the main one; now the script was encrypted, and stayed so until I signed on with the main userid to unlock it!

[Spanik]

Thanks for all the replies. Getting some feedback from experience is great. I'm going to read about those and if needed I'll come back with more questions.

[Spanik]

Ok, so I read a bit about all the provided solutions and so far fscrypt came out the most in line with my wants/needs. Form what I understood, it just encrypts that what is needed, isn't an "hidden disk within a fixed size file", no other files needed, encryption moves with the file and is reasonably well integrated into the whole system. It might not be the most secure but then I'm not encrypting state secrets or illegal things. Just some embarasing writings and photos from my youth.

Only problem it doesn't work with xfs which is what I use throughout my pc (except /boot). So I'll have to put in another disk and move everything around a bit. I'm not looking forward having to go to ext for that. My previous experiences with ext3 (twice data loss) is what made me make switch to xfs which has been flawless for years now. So I'll loose the first safety net of raid as well as I'll move to a single disk and have another disk to back up.

You gain some, you loose some.

[Zucca]

Isn't fscrypt just a fuse mount?
I mean you mount X directory to Y directory.
You put non-ecrypted files into Y directory and those same file appear encrypted on X directory.
That's all user-space. It shouldn't matter what's the fs type is under X directory.
What am I missing here? I too use XFS quite a lot and would like to use fscrypt too.

EDIT: fscrypt wasn't what I thought it was.
I was probably remembering EncFS.

[Hu]

Considering Spanik's inability to use fscrypt due to lack of filesystem support, I will suggest use of a filesystem inside a LUKS container stored in a file on the host filesystem. It lacks the convenience of fscrypt, but it should be compatible with all host filesystems that can do loopback files.

[saturnalia0]

I've used two alternatives:

app-crypt/gnupg:

Code: Select all

tar cf my-files.tar my-files/
gpg --symmetric my-files.tar # enter secret key
# ...
gpg --decrypt my-files.tar.gpg # enter secret key
tar xf my-files.tar

app-crypt/ccrypt:

Code: Select all

ccrypt -r -e my-files/ # enter secret key
# ...
ccrypt -r -d my-files/ # enter secret key

Both use symmetric encryption. gpg let's you select the algorithm, ccrypt is AES256.

Since only ccrypt is in-place, you might want to use shred with gpg to wipe out the unencrypted files (shred -uvz file-or-dir-to-wipe-irrecoverably).

[szatox]

Saving a file on disk, then encrypting it, it's fine when mailing that file or something, but not for storing it securely, which looks like OP's objective, so gpg and similar tools are an inferior option.

I'd just use LUKS for that. If reorganizing the disk is not an option, backing it with a file instead of a device is. It is not the most convenient thing on Earth, but it's not too bad either, and it does actually work.
Once your directory of choice is protected, you only have to worry about leaking data via unencrypted $HOME, /tmp, SWAP, and other locations which may be used by programs operating on your sensitive files. Man, it's just easier to encrypt everything instead. But a luks vault in a file certainly is an option when FDE can't be used.

[pietinger]

Isn't fscrypt just a fuse mount?

No, it is a kernel module and doesnt use FUSE ... it uses the encryption modules of the kernel directly:

Code: Select all

CONFIG_FS_ENCRYPTION
...
Selects: CRYPTO [=y] && CRYPTO_HASH [=y] && CRYPTO_SKCIPHER [=y] && CRYPTO_LIB_SHA256 [=y] && KEYS [=y]

Of course you will need user application for setup, configuring and using such a directory.

[pietinger]

However, you should be aware that the encryption goes with the file, so if you move that file to [...]

Yes, if you move it ... but if you copy it outside it will not be encrypted anymore and is usable without any fscrypt magic ... I like this behaviour.

[saturnalia0]

Saving a file on disk, then encrypting it, it's fine when mailing that file or something, but not for storing it securely, which looks like OP's objective, so gpg and similar tools are an inferior option.

Could you elaborate? Depending on OP's threat model it may be fine?

[szatox]

saturnalia0, creating and accessing individually encrypted files also takes additional work. Certainly much more than opening a container.
And editing individually encrypted files would deserve its own circle of hell.

That's aside of having plain-text copies of sensitive files, which must be deleted (and this is work too, which means user might suffer from fatigue / forget / get distracted / run out of time / fail for any other reason), and even deleted files still leave imprints on the underlying device which can be recovered until overwritten.

[saturnalia0]

Well it can be done at the directory level, which is OP's scenario I think. ccrypt is in place and shred can be used otherwise.

[Spanik]

Considering Spanik's inability to use fscrypt due to lack of filesystem support, I will suggest use of a filesystem inside a LUKS container stored in a file on the host filesystem. It lacks the convenience of fscrypt, but it should be compatible with all host filesystems that can do loopback files.

Well, it would be more "inability" to use it just inside my current oraganisation of disks. I'd prefer to have it otherwise but if I have to choose between putting that data apart on another disk with ext or changing the whole disk to ext then I'll rather just plug in another disk with ext. I don't like the idea of a container of fixed size unless that is a whole disk.

Saving a file on disk, then encrypting it, it's fine when mailing that file or something, but not for storing it securely, which looks like OP's objective, so gpg and similar tools are an inferior option.

Could you elaborate? Depending on OP's threat model it may be fine?

saturnalia0, creating and accessing individually encrypted files also takes additional work. Certainly much more than opening a container.
And editing individually encrypted files would deserve its own circle of hell.

That's aside of having plain-text copies of sensitive files, which must be deleted (and this is work too, which means user might suffer from fatigue / forget / get distracted / run out of time / fail for any other reason), and even deleted files still leave imprints on the underlying device which can be recovered until overwritten.

This isn't highly sensitive data that would mean disaster if lost or accessed. Likewise it isn't very dynamic data either. These are things I find here and there on my disks (and backup cd's) (I rarely delete anything) that have little value other than very personal nostalgia. But they are private and when I'm gone nobody has any business with it. It is not that I'm going to have to do serious editing of large amounts of very sensitive and critical data. More like reading an old email conversation, looking through some old photos from uni, there might even listening to a recording or 2. So encrypting and decrypting individual files could be an option but I do think that having to re-encrypt actively it again after being done with it is not ideal. I would prefer a way of weroking where the file is decrypted (in memory) for the time you use it and when the pc is shut down, it is found in its encrypted form the next time you boot.

That is why I was thinking of having a directory (or more than one) that is encrypted, just sits there and when I'm feeling moody (and have a had a few) can go into it with a password, look a bit at 'the good old days" and then close the pc and go to bed.

But from what I read, I guess that buying a small (usb) HD and putting ext on it and fscrypt looks like the way to go. Not what I thought to do but if that is the solution that gets closest to what I intended with the least trouble and possible side-effects... then that is the solution.

[szatox]

I don't like the idea of a container of fixed size unless that is a whole disk

You can extend it. Gotta be careful with that, but it's not difficult.
Basically close the container, append additional space to the file, open it again and resize the filesystem. There are no other luks-specific operations you need to do, and reopening the container is only needed because that's when luks reads the size of backing device. (Well, you may or may not need to rebind file to loop device for changes to take effect, but this comes from using a loop rather than from luks)
This said, I have no skin in this this game; use whatever you like.

That encfs or whatever Zucca mentioned might be a good option for your use case too.
Additional, encrypted device is probably the cleanest of all the options mentioned so far, but then you have to carry another device. And you have to somehow keep track of it (and it's content)... Which is not ideal as soon as you have more than 1 stick.
Also, pendrives and cards are not as durable as ssd, you can kill them in a matter of hours if you write them hard enough. The last part doesn't seem like a big problem for you, but it's still something worth keeping in mind.

[Spanik]

Additional, encrypted device is probably the cleanest of all the options mentioned so far, but then you have to carry another device. And you have to somehow keep track of it (and it's content)... Which is not ideal as soon as you have more than 1 stick.
Also, pendrives and cards are not as durable as ssd, you can kill them in a matter of hours if you write them hard enough. The last part doesn't seem like a big problem for you, but it's still something worth keeping in mind.

I had one of those USB with a fingerprint reader for testing if that might be something. Used it for a while but the filesystem broke meaning I can't mount it anymore. So I'm not keen on using something similar again. And I do have several usb sticks around... because of the job I'm always surrounded by at least half a dozen and there are always several in my pockets. So adding another one isn't that big a thing. For the job these things are disposable but not for my purpose. So mixing those 2 isn't a good idea for me.

[sabayonino]

Consider EncFS also.

I have my EncFS directory in ~/Vaults

and two aliases in my ~/.bashrc to lock/unlock it
The code check if Vaults folder is (already)-mounted or not.
Something like this :

Code: Select all

alias v-lock='mountpoint -q ~/Vaults && fusermount -u ~/Vaults || echo ' ** Vaults is unmounted. Please run v-unlock ** ' "
alias v-unlock='mountpoint -q ~/Vaults && echo ' ** Vaults is already mounted. ** ' || encfs ~/.Vaults ~/Vaults'

--> ~/Vaults is your plaintext folder contents
--> ~/.Vaults is your encrypted folder contents

[pietinger]

Consider EncFS also.

I have my EncFS directory in ~/Vaults

Yes, I had tested it also with KDE Vaults ... but it was very slow (compared to fscrypt).

Maybe it will become faster with kernel version 6.9+ because you will have then:

Code: Select all

FUSE passthrough operations support (FUSE_PASSTHROUGH) [Y/n/?] (NEW)

(but I have not tested that; I dont use encfs anymore)

[sabayonino]

I used Vaults as example.

I wrote for EncFS . This differs from Vaults-KDE-encrypting tool
but it is very similar