Home / ubuntu / Questions / 104542
In Process
Gonzoza
Asked: 2012-02-16 12:59:38 +0800 CST

How to encrypt individual folders?

  • 772

Let's say that I have a folder, within my Documents folder, that has files I want no one to access without a password.

Is there a way to lock down that folder so that it's password protected / encrypted?

In fact, is it possible to password-protect any individual folder?

encryption security password directory

8 Answers

  1. Cryptkeeper

    WARNING: CryptKeeper has recently been reported that it has a universal password bug that puts your data at potential risk. This issue may not yet be fixed in Ubuntu, use this solution at your own risk.

    Relevant bug information links:
    Upstream bug: https://github.com/tomm/cryptkeeper/issues/23
    Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852751

     sudo apt-get install cryptkeeper

                                    After installing, go to Applications –> System Tools –> Cryptkeeper.

                                            Cryptkeeper will automatically attach itself to the top panel

                       enter image description here

                         To create an encrypted protected folder, click on Cryptkeeper applet and select                                                                             ‘New encrypted folder’

                       enter image description here

                              Then type the folder name and where to save the folder and click ‘Forward’.

                       enter image description here

                                                                  Type the password and click ‘Forward’.

                       enter image description here

                                                          The folder will be created and ready to be used.

                       enter image description here

                       To access all encrypted folder, click on Cryptkeeper applet on the panel and select                                                                                                each folder.

                       enter image description here

                                                       Type the password before it is mounted to be accessed.

                       enter image description here

                                                           Done

                       enter image description here

                     To delete a folder or change the password, right-click the folder in the panel-applet.

                                                                                          For More Help

    • 57

  2. eCryptfs

    EncryptedPrivateDirectory Method.

    Ubuntu Official Wiki

    Search for and install ‘ecryptfs-utils’ in Ubuntu Software Center:

    enter image description here

    After installing, go to Applications –> Accessories –> Terminal and run the command below:

    ecryptfs-setup-private

    enter image description here

    You’ll be prompted to type your login passphrase (password), and to create one for your private folder:

    enter image description here

    When you’re done creating your password, Log Out and Log back in:

    enter image description here

    Next, go to Places –> Home Folder:

    enter image description here

    And new folder should be created in your home directory called ‘Private’. This folder in encrypted and password-protected. Move all your personal stuff into this folder to secure them:

    enter image description here

    Users without access to the folder will be denied:

    enter image description here

    For More Help

    • 15

  3. You have 2 choices if you want to lock down a folder from other users

    • Encrypt or create a compressed password protect archive of the files. This method (Cryptkeeper) is perfect for this case when you need to be 100% sure no one will ever look at your files without knowing the password used there.

    • Use your computer folder / file permissions to deny access to your folder to other user.

    The first involves making sure that the result cannot be opened by any user without knowing the password used.

    The second will only change the file / folder privileges so that another user without rights cannot open it. The folder still exists, can be accessed by any user with sudo rights in your system or using a LiveCD and reading the partition. It is also simpler to implement and does not require that you type a password all the time you need to open / mount the encrypted folder / archive.

    An easy and fast way to do so is using chmod to change the privileges for a file or folder.

    Open a terminal and navigate to the place where your folder is, lets assume that the folder name is foo and that we are currently located where the folder is.

    chmod 700 foo

    will make foo only available for your eyes, its not encrypted (that is also possible) but only your user (and or a user with sudo privileges) can read or open that file / folder.

    You can also do it graphically by right clicking on a file or folder and changing its permissions manually. In the example below you as owner have all privileges and you deny any other group or user from accessing, reading or modifying that file / folder

    enter image description here

    For more information about file / folder permissions visit the Ubuntu Understanding and Using File Permissions wiki page.

    • 9

  4. Another way, depending on your needs is to archive the folder as a password protected zip file.

    This is similar to another question about password protecting files.

    • 4

  5. Vault

    Last update: Aug 4, 2012

    You can try Vault, recent project by an ubuntu-gr member (greek local community).

    PPA:

    sudo add-apt-repository ppa:vault/ppa
sudo apt-get update
sudo apt-get install vault

    It's a gui utility for encfs (package in repositories). I quote the package description:

    $ apt-cache show encfs
Package: encfs
[...]
Description-en: encrypted virtual filesystem
 EncFS integrates file system encryption into the Unix(TM) file system.
 Encrypted data is stored within the native file system, thus no
 fixed-size loopback image is required.
 .
 EncFS uses the FUSE kernel driver and library as a backend.
Homepage: http://www.arg0.net/encfs

    You create a mountpoint/folder which you can then close or delete. If you close it, you need a password to open it.

    enter image description here

    • 4

  6. CryFS

    You can use CryFS:

    cryfs basedir mountdir

    It is used by default in KDE Vaults and is particularly interesting if you synchronize the encrypted content over Dropbox, Freefilesync, rsync or similar software, because it keeps its data in small encrypted blocks and changing a small file results in only a small amount of data to be re-uploaded.

    • 4

  7. Directory level encryption is a risky thing, prefer block device level encryption whenever possible.

    I think Giles nailed several key points here, which I'll reproduce:

    Use encryption at the block device level. Linux provides this with dm-crypt. You can encrypt either the whole disk (except for a small area for the bootloader), or encrypt /home or some other partition. If you don't encrypt the whole disk, keep in mind that confidential information might end up in other places, especially the swap space (if you have any encrypted data anywhere, you should encrypt your swap). Note that if you go for whole-disk encryption, your computer will not be able to boot unattended, you will have to type your passphrase at the keyboard.

    Since the whole block device is encrypted, the location of file content and metadata cannot be detected by an attacker who steals the disk. Apart from a header at the beginning of the encrypted area, the content is indistinguishable from random noise. An attacker could derive some information from seeing multiple snapshots of the encrypted data and studying how various sectors evolve over time, but even with this it would be hard to find out anything interesting, and this doesn't apply if you stop modifying the data after the attacker has seen the ciphertext (as in the case of a disk theft).

    Also note that if you encrypt something inside your home and not the entire home itself, several common programs can lead to data leaks unless you are hair splittingly careful. E.g.: .bash_history, editor sessions and undo histories, etc.

    Some pointers on how to do this:

    eCryptfs manual setup

    This answer described the Ubuntu helpers for it (e.g. ecryptfs-setup-private), but you can get more control (e.g. separate different mount directories) and understanding by mounting it yourself.

    eCryptfs is already part of the Linux kernel and already enabled by default on Ubuntu via CONFIG_ECRYPT_FS=y, so you can just basically mount it. Being part of the kernel is also generally a positive indicator of quality and stability.

    I have the following helpers:

    export ECRYPTFS_DIR="$HOME/ecryptfs"
export ECRYPTFS_DATA_DIR="$HOME/.ecryptfs-data"

ecry() (
  # Mount ecryptfs.
  if ! mountpoint -q "$ECRYPTFS_DIR"; then
    sudo mount -t ecryptfs \
      -o key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=no,ecryptfs_enable_filename_crypto=yes \
      "$ECRYPTFS_DATA_DIR" \
      "$ECRYPTFS_DIR"
  fi
)
ecryu() (
  # Unmount ecryptfs.
  sudo umount "$ECRYPTFS_DIR"
)

    GitHub upstream.

    Usage is as follows.

    First mount the encrypted directory:

    ecry

    This will now ask you for a passphrase:

    Passphrase:

    Suppose we unwisely choose:

    asdf

    so it will now print:

    Filename Encryption Key (FNEK) Signature [87d04721f6b4fff1]:

    87d04721f6b4fff1 is a type of hash derived from our asdf password. You can now hit enter, and it will say:

    Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_fnek_sig=87d04721f6b4fff1
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=87d04721f6b4fff1
Mounted eCryptfs

    which means that the mount was successful.

    Now let's make some test encrypted files:

    echo AAAA > ~/ecryptfs/aaaa
echo BBBB > ~/ecryptfs/bbbb
dd if=/dev/zero bs=1k count=1k > ~/ecryptfs/zzzz

    If we unmount it:

    ecry

    as expected the directory is empty:

    ls -l ~/ecryptfs

    The eCryptfs data itself is contained in the ~/.ecryptfs-dat directory we passed to the mount command.

    No matter where we mount to, as long as we use that directory as the data directory, the contents of the unencrypted mount point will be the same.

    Let's observe its contents:

    ls -lh ~/.ecryptfs-data

    This shows three encrypted files:

    -rw-rw-r-- 1 ciro ciro  12K Nov 11 17:15 ECRYPTFS_FNEK_ENCRYPTED.FWa5o2QVxfHzwEQ-GALjie5YM3J8aETCQqcZB.pJ2KyM4SRZWVvHGnAYi---
-rw-rw-r-- 1 ciro ciro  12K Nov 11 17:15 ECRYPTFS_FNEK_ENCRYPTED.FWa5o2QVxfHzwEQ-GALjie5YM3J8aETCQqcZMnVJY0WbH6bqRaee1cD5xU--
-rw-rw-r-- 1 ciro ciro 1.1M Nov 11 17:15 ECRYPTFS_FNEK_ENCRYPTED.FWa5o2QVxfHzwEQ-GALjie5YM3J8aETCQqcZf.vz0tLUzh41PwVFAnHc5k--

    So we observe that:

    • we have one unecrypted data file for each file in the main unencrypted mount
    • the filenames are encrypted
    • the minimum size per file is 12KB, even for those small files that contain only 5 bytes we've just created, so we would get a big disk usage increase if there were a lot of such small files
    • for the large 1MB file, the new size is 1.1MB, so there is also a proportional size increase of about 10% inaddition to the 12KB minimum size
    • timestamps are leaked. TODO: how to avoid that?

    We can now check if those files are actually encrypted:

    grep aaaa ~/.ecryptfs-data/*
grep AAAA ~/.ecryptfs-data/*

    which gives no matches, so they likely are encrypted.

    The cool thing about how those encrypted files are stored, is that you can then easily backup the encrypted files anywhere by just copying them over to an unencrypted medium with rsync, and only out-of-date files will be copied. There is no need to even first enter your password in that case!

    The non-cool thing about it, is that an attacker who is trying to prove that you had a known piece of information might be able to prove that by comparing the file sizes and directory structure layout as mentioned by Giles.

    Now let's mount again:

    ecry

    Once again, it asks for the password.

    Suppose you enter the wrong password:

    asdfqwer

    it will now print:

    Filename Encryption Key (FNEK) Signature [c55c6f13e73332d3]:
Attempting to mount with the following options:
  ecryptfs_unlink_sigs
  ecryptfs_fnek_sig=c55c6f13e73332d3
  ecryptfs_key_bytes=16
  ecryptfs_cipher=aes
  ecryptfs_sig=c55c6f13e73332d3
WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key
before. This could mean that you have typed your
passphrase wrong.

Would you like to proceed with the mount (yes/no)? :

    So we observe that the FNEK for asdfqwer is different than that of the correct asdf password: c55c6f13e73332d3.

    If we decide to mount anyways with yes, it then asks:

    Would you like to append sig [c55c6f13e73332d3] to
[/root/.ecryptfs/sig-cache.txt]
in order to avoid this warning in the future (yes/no)? :

    and if we enter yes, it would, as promised add the FNEK to the /root/.ecryptfs/sig-cache.txt. Let's say no for now. We can check what that file contains:

    sudo cat /root/.ecryptfs/sig-cache.txt

    it currently only contains the asdf FNEK:

    87d04721f6b4fff1

    so we understand that it is just a whitelist of known good passwords.

    Now let's see what we get with the wrong password:

    ls -l ~/ecryptfs

    and we see that the directory is empty as you might expect. It seems that each file in the data directory must contain some kind of password check data, and just doesn't get mounted.

    If we umount and move back to the correct password asdf, it wil once again ask for FNEK confirmation which is a bit annoying.

    Filename Encryption Key (FNEK) Signature [87d04721f6b4fff1]:

    We can prevent that from happening every time as mentioned at How to automatically specify the Filename Encryption Key with ecryptfs? by adding:

    -o ecryptfs_fnek_sig=

    to the mount command. TODO would knowing the FNEK help attackers crack the password?

    Finally, when the ecryptfs directory mounted, we can see it under:

    grep ecryptfs /proc/mounts

    which contains a line of type:

    /home/ciro/.ecryptfs-data /home/ciro/ecryptfs ecryptfs rw,relatime,ecryptfs_fnek_sig=d066f6dcf72ad65a,ecryptfs_sig=d066f6dcf72ad65a,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0

    Tested on Ubuntu 20.04, Linux kernel 5.4.

    ecryptfs vs CryFS vs EncFS

    These are all directory-level methods so it would be good to understand their tradeoffs, Some comparisons:

    • https://www.cryfs.org/comparison/

    • https://wiki.archlinux.org/index.php/EncFS#Comparison_to_eCryptFS

      eCryptFS is implemented in kernelspace and therefore a little bit harder to configure. You have to remember various encryption options (used cyphers, key type, etc...). With EncFS this is not the case, because it stores the encryption metadata information in a per-directory configuration file (.encfs6.xml). So you do not have to remember anything (except the passphrase).

      The performance of both depends on the type of disk activity. While eCryptFS can perform faster in some cases because there is less overhead by context switching (between kernel and userspace), EncFS has advantages in other cases because the encryption metadata is centralized and not stored in the individual files' headers. For more information benchmark examples are provided by the EncFS project.

    Full disk encryption at install time (except /boot)

    I can't find "the question" for this, so here goes a QEMU experiment based here with Ubuntu 20.04.1.

    You click:

    • Erase disk and install Ubuntu
    • Advanced features
    • Use LVM with the new Ubuntu installation
    • Encrypt the new Ubuntu installation for security

    screenshot

    Then it asks you for a password on the next step:

    screenshot

    Now, every time you boot, the very first thing you see, (TODO before or after the bootloader?), is a password prompt:

    screenshot

    And after this, if you enter the correct password, it goes into a normal boot.

    After logging in, from inside a shell we do:

    lsblk

    and that gives:

    sda                     8:0    0      1T  0 disk  
├─sda1                  8:1    0    512M  0 part  /boot/efi
├─sda2                  8:2    0      1K  0 part  
├─sda5                  8:5    0    731M  0 part  /boot
└─sda6                  8:6    0 1022.8G  0 part  
  └─sda6_crypt        253:0    0 1022.8G  0 crypt 
    ├─vgubuntu-root   253:1    0 1021.8G  0 lvm   /
    └─vgubuntu-swap_1 253:2    0    976M  0 lvm   [SWAP]

    so it appears that the second stage bootloader under /boot itself is not encrypted, but the root directory and swap are.

    As mentioned at: https://help.ubuntu.com/community/Full_Disk_Encryption_Howto_2019 this opens you to the risk that an attacker would be able to compromise your machine by tampering with the boot folder, without your knowledge, and use that to later extract your decryption keys if you continue to use the machine.

    Full disk encryption at install time (including /boot)

    There doesn't seem to be an automated way of doing it as of 20.04, but hopefully it will get implemented sooner or later, some manual guides:

    Kill switch turned on laptop encryption security

    OK, we are now reaching a CIA/Silk Road level of opsec paranoia topic: how to quickly ensure that your data can't be decrypted if you are caught with the computer turned on and have a second to act.

    First, suspend to RAM does not seem to be good enough, hibernation will be a wiser move:

    Hibernation seems to save data in the swap partition, so as long as your swap is encrypted (Which it obviously should be in an encryption setting, otherwise your RAM will leak there), it should be safe.

    Now, on a laptop, the best method is likely a lid closing action, e.g. this post mentions that:

    HandleLidSwitch=hibernate

    on /etc/systemd/logind.conf should work

    Alternatively should setup a keyboard shortcut or a power button action. How to hibernate from CLI: How can I hibernate on Ubuntu 16.04? mentions:

    sudo systemctl hibernate
    • 1

  8. You could also use gocryptfs. In my experience it is significantly faster than cryfs with big encrypted shares, but does not hide the structure (file sizes and number of files). depending on your threat model this may or may not be a problem.

    To install

    apt install gocryptfs

    To initialize the basedir (once)

    gocryptfs -init basedir

    To mount basedir (the encrypred version) on mountdir (the unencrypted version)

    gocryptfs basedir mountdir
    • 0