Hi, I’m looking for a way to encrypt files on my Fedora 40 KDE system but at the same time have easy access to them, I tried encrypting my files with cryptomator (flatpak) but because I found several bugs I stopped using it, I’m looking for a good replacement, I’d like to know what you recommend.
1 Like
Añadido f40
GPG ?
Probably the best solution for individual files outside of using .7z or others ?
I don’t want to be decrypting each file 1 by 1 with its key and redirecting them to an output file
1 Like
gpg --decrypt yourfile.gpg
if you have a bunch, you can write a for loop.
#!/bin/bash
for file in *.gpg; do
gpg --decrypt "$file"
done
Make it executable, place it in ~/.local/bin/ call it from the dir you need it. . .
1 Like
Try plasma-vault. You can create an encrypted folder with easy access to it.
1 Like
What would be different from using GPG, without the need for a 3rd party solution? What type of Encryption does it use?
Vault is not ‘3rd party’, it’s native plasma application. With vault you can create encryption folder, mount it and just drag-n-drop files to it, edit it and so on. You can use encfs, cryfs, gocryptfs as encryption engines. As I remember with GPG you can encrypt only 1 file at a time.
Plasma Vault has a possible security issue, as mentioned in Baloo - ArchWiki. I tested this issue a while back. If you plan to use Plasma Vault, please verify whether this issue has been fixed. If not, it is better to use the workaround mentioned in Arch Wiki.
1 Like
I use full-disk-encryption on all my critical systems.
At boot I unlock the disks with a pass phrase.
You would need to reinstall your kde to set this up.
If you do not want to reinstall to set this up you could add a loop back file system that is encrypted to your existing setup.
2 Likes
Oh Really 
Plasma Vault Files are indexed and available even when vault is closed
This is a major security bug not yet fixed. Any file inside vault is by
default indexed and available through file manager search,
Krunner and Kickoff.
I mean, if the user really needs a vault for files on a system, You could even create a .bin file of the size you need with dd and encrypt it using cryptsetup then add a file system to it once you open the vault so you have a portable encrypted container for you files.
But with cryptsetup you have to preallocate it’s size and you’ll be not able expand it in the future.
As alternative user can use encfs/gocryptfs/cryfs and mount/dismount it via terminal with just ‘encfs source destination’ or ‘gocryptfs source destination’ or ‘cryfs source destination’ and don’t worry about about free space in the container.
I would also suggest cryptsetup, if command-line tools are acceptable:
- create the vault file with
dd if=/dev/zero bs=1M count=1024 of=~/vault-image.img. Replace thecount=1024argument so that the file size would suit your medium-term needs. - format the image file with
sudo cryptsetup --verify-passphrase luksFormat ~/vault-image.img - associate the image file to a device file:
sudo cryptsetup luksOpen ~/vault-image.img vault-device - create a filesystem for the device file:
sudo mkfs.ext4 /dev/mapper/vault-device - create your mount point:
mkdir ~/vault-mount - mount the vault with
sudo mount /dev/mapper/vault-device ~/vault-mount - use the vault as needed, with
mount/umountandcryptsetup luksOpen/luksClosecommands.
In case the vault becomes low in space, you can resize the vault image file with truncate command and the device file with resize2fs command. I just don’t know if such an action would reduce the security of the encrypted file. 
3 Likes
I wrote a simple for loop above to solve that problem.
It’s not like i don’t have a script running in the background as a systemd.service to gpg some backup directories 
IMO this is not a problem. If you are constantly adding things to this style vault, then your solution is wrong. if you know ahead of time you have 10,00 files to encrypt you can total those up and give yourself some space to work with.
If you are continually adding file to it, figure out a different solution altogether.
I still prefer gpg for files. the for loop is simple enough. The encrypt/decrypt will work anywhere you can use your keys.
1 Like
I didn’t read the topic in total, but maybe fscrypt from the kernel provides some useful incentives for you:
Filesystem-level encryption (fscrypt) — The Linux Kernel documentation
GitHub - google/fscrypt: Go tool for managing Linux filesystem encryption
→ you find much on the Internet about it
It is extremely fast as it is processed in the kernel: much code that is called in fscrypt is shared with dm-crypt (our kernel’s disk encryption), but unlike the block-level/disk-encryption of dm-crypt, fscrypt is intended to provide directory- and file-level encryption.
Yet, the file system has to be compatible, and here you might experience an issue: I am not sure if btrfs is supported. You might check that first. If that is not the case, fscrypt might be only interesting for you if you use ext4 (or something else that is compatible) for the file system on which you want to use fscrypt.
Not 100% sure if that is for you, but it might be mentioned to allow you to consider it, just in case 
3 Likes
Wow 
That’s interesting. . .
But, GPG can be OS agnostic. . . Can it 
Yes, GPG is a tool that is to be installed, it does not depend on the kernel (with all pros and cons of that fact) and it is available for most OS I think.
fscrypt should work on any type of Linux as it is in the kernel for long. Technically, it is possible to create tools that map fscrypt in user space, even if a non-Linux kernel is not capable to natively work with it (e.g., in the past, we had something to map ntfs in user space to make it accessible on Linux OS). But I indeed do not know if such means have been developed and if they are reliably maintained. If the author of this topic wants to use fscrypt with non-Linux OS, then they of course need to check that out at first. Of course this would include mapping the respective file system too. Off the cuff, my expectation (I never investigated that!) is that fscrypt is only a reliable option if the user aims to use it only on Linux-kernel-based OS.
This page might be interesting too: fscrypt - ArchWiki
→ it also refers to some further alternatives the author maybe wants to consider.
1 Like
My point is more angled to the use case of say: “Documents, Small files, Pictures” Where the recipient might be on Android/WinX/OSX/GNU+Linux and can decrypt/encrypt without worry of incompatibility.
The OP while did not specify a use case, but one could assume that compatability would be high on the request. Including Good encryption.
1 Like
Just like disk encryption, fscrypt is a measure intended to encrypt data in storage, not to encrypt data in transport. The latter is possible (you can also transport dm-crypt / disk-encrypted devices - everything is a file on Linux), but of course that would be something that is only intended if the sender and recipient have Linux and both know how to handle that. Primarily, this is to locally encrypt stuff, not to transport it encrypted.
Correct, they didn’t specify that. But my expectation of how I read their posts was that they want to encrypt their local files and directories, not find a way to share files/directories in an encrypted way that then shall be decrypted by other people with other systems. Of course I could have misunderstood the author.
2 Likes
It might be useful to describe your use-case @thfedo. Are you trying to create an encrypted vault and sync it to the cloud (what cryptomator seems to be doing) or a local vault? From what/who are you protecting the files? Someone stealing your disk or cloud providers?
If it is cloudproviders I don’t think a cryptsetup image is the way to go because it creates a single giant file which is probably not that great for syncing. If you are trying to protect against someone stealing your disk gpg will not be secure because you would still have unencrypted instances of data on the disk (which could still be recovered after deleting).
For cloud storage cryfs or rclone might be a good option, rclone has some options for encryption. For the disk I would just go with full disk encryption, and if that is not an option a cryptsetup image / gocryptfs.
1 Like