Difference between revisions of "Disk encryption"

From ArchWiki
Jump to: navigation, search
(+ related article)
(fixed section fragments (interactive))
(Tag: wiki-scripts)
 
(67 intermediate revisions by 22 users not shown)
Line 1: Line 1:
[[Category:Security]]
+
[[Category:Encryption]]
 
[[Category:File systems]]
 
[[Category:File systems]]
[[it:Disk Encryption]]
+
[[es:Disk encryption]]
 +
[[it:Disk encryption]]
 +
[[ja:ディスク暗号化]]
 
{{Related articles start}}
 
{{Related articles start}}
 
{{Related|dm-crypt}}
 
{{Related|dm-crypt}}
Line 8: Line 10:
 
{{Related|EncFS}}
 
{{Related|EncFS}}
 
{{Related|Tomb}}
 
{{Related|Tomb}}
{{Related|Mount encrypted volumes in parallel}}
+
{{Related|tcplay}}
 +
{{Related|GnuPG}}
 +
{{Related|Self-Encrypting Drives}}
 
{{Related articles end}}
 
{{Related articles end}}
 
This article discusses common techniques available in Arch Linux for cryptographically protecting a logical part of a storage disk (folder, partition, whole disk, ...), so that all data that is written to it is automatically encrypted, and decrypted on-the-fly when read again.
 
This article discusses common techniques available in Arch Linux for cryptographically protecting a logical part of a storage disk (folder, partition, whole disk, ...), so that all data that is written to it is automatically encrypted, and decrypted on-the-fly when read again.
Line 21: Line 25:
  
 
For example, this can prevent unauthorized viewing of the data when the computer or hard-disk is:
 
For example, this can prevent unauthorized viewing of the data when the computer or hard-disk is:
* located in a place to which non-trusted people might gain access while you're away
+
* located in a place to which non-trusted people might gain access while you are away
 
* lost or stolen, as with laptops, netbooks or external storage devices
 
* lost or stolen, as with laptops, netbooks or external storage devices
 
* in the repair shop
 
* in the repair shop
 
* discarded after its end-of-life
 
* discarded after its end-of-life
  
In addition, disk encryption can also be used to add some security against unauthorized attempts to tamper with your operating system - for example, the installation of keyloggers or Trojan horses by attackers who can gain physical access to the system while you're away.
+
In addition, disk encryption can also be used to add some security against unauthorized attempts to tamper with your operating system for example, the installation of keyloggers or Trojan horses by attackers who can gain physical access to the system while you are away.
  
 
{{Warning|Disk encryption does '''not''' protect your data from all threats.}}
 
{{Warning|Disk encryption does '''not''' protect your data from all threats.}}
 
You will still be vulnerable to:
 
You will still be vulnerable to:
* Attackers who can break into your system (e.g. over the Internet) while it is running and after you've already unlocked and mounted the encrypted parts of the disk.
+
* Attackers who can break into your system (e.g. over the Internet) while it is running and after you have already unlocked and mounted the encrypted parts of the disk.
 
* Attackers who are able to gain physical access to the computer while it is running (even if you use a screenlocker), or very shortly ''after'' it was running, if they have the resources to perform a [[Wikipedia:Cold boot attack|cold boot attack]].
 
* Attackers who are able to gain physical access to the computer while it is running (even if you use a screenlocker), or very shortly ''after'' it was running, if they have the resources to perform a [[Wikipedia:Cold boot attack|cold boot attack]].
 
* A government entity, which not only has the resources to easily pull off the above attacks, but also may simply force you to give up your keys/passphrases using various techniques of [[Wikipedia:Coercion|coercion]]. In most non-democratic countries around the world, as well as in the USA and UK, it may be legal for law enforcement agencies to do so if they have suspicions that you might be hiding something of interest.
 
* A government entity, which not only has the resources to easily pull off the above attacks, but also may simply force you to give up your keys/passphrases using various techniques of [[Wikipedia:Coercion|coercion]]. In most non-democratic countries around the world, as well as in the USA and UK, it may be legal for law enforcement agencies to do so if they have suspicions that you might be hiding something of interest.
Line 36: Line 40:
 
A very strong disk encryption setup (e.g. full system encryption with authenticity checking and no plaintext boot partition) is required to stand a chance against professional attackers who are able to tamper with your system ''before'' you use it. And even then it is doubtful whether it can really prevent all types of tampering (e.g. hardware keyloggers). The best remedy might be [[Wikipedia:Hardware-based full disk encryption|hardware-based full disk encryption]] and [[Wikipedia:Trusted_Computing|Trusted Computing]].
 
A very strong disk encryption setup (e.g. full system encryption with authenticity checking and no plaintext boot partition) is required to stand a chance against professional attackers who are able to tamper with your system ''before'' you use it. And even then it is doubtful whether it can really prevent all types of tampering (e.g. hardware keyloggers). The best remedy might be [[Wikipedia:Hardware-based full disk encryption|hardware-based full disk encryption]] and [[Wikipedia:Trusted_Computing|Trusted Computing]].
  
{{Warning|Disk encryption also won't protect you against someone simply [[Securely wipe disk|wiping your disk]]. [[Backup Programs|Regular backups]] are recommended to keep your data safe.}}
+
{{Warning|Disk encryption also will not protect you against someone simply [[Securely wipe disk|wiping your disk]]. [[Backup programs|Regular backups]] are recommended to keep your data safe.}}
  
===Data encryption vs system encryption===
+
== Data encryption vs system encryption ==
{{Wikipedia|Disk encryption}}
+
'''Data encryption''', defined as encrypting only the user's data itself (often located within the {{ic|/home}} directory, or on removable media like a data DVD), is the simplest and least intrusive use of disk encryption, but has some significant drawbacks.<br>In modern computing systems, there are many background processes that may cache/store information about user data or parts of the data itself in non-encrypted areas of the hard drive, like:
+
  
* swap partitions
+
; Data encryption
** <span style="color:#555">''(potential remedy: disable swapping)''</span>
+
: Defined as encrypting only the user's data itself (often located within the {{ic|/home}} directory, or on removable media like a data DVD), data encryption is the simplest and least intrusive use of disk encryption, but has some significant drawbacks.
* {{ic|/tmp}} (temporary files created by user applications)
+
: In modern computing systems, there are many background processes that may cache/store information about user data or parts of the data itself in non-encrypted areas of the hard drive, like:
** <span style="color:#555">''(potential remedies: avoid such applications; mount {{ic|/tmp}} inside a [[ramdisk]])''</span>
+
* {{ic|/var}} (log files and databases and such; for example, mlocate stores an index of all file names in {{ic|/var/lib/mlocate/mlocate.db}})
+
  
In addition, mere data encryption will leave you vulnerable to offline system tampering attacks (e.g. someone installing a hidden program that [[Wikipedia:Keystroke_logging|records]] the passphrase you use to unlock the encrypted data, or waits for you to unlock it and then secretly copies/sends some of the data to a location where the attacker can retrieve it).
+
:* swap partitions
 +
:** (potential remedies: disable swapping, or use [[encrypted swap]] as well)
 +
:* {{ic|/tmp}} (temporary files created by user applications)
 +
:** (potential remedies: avoid such applications; mount {{ic|/tmp}} inside a [[ramdisk]])
 +
:* {{ic|/var}} (log files and databases and such; for example, mlocate stores an index of all file names in {{ic|/var/lib/mlocate/mlocate.db}})
  
 +
:In addition, mere data encryption will leave you vulnerable to offline system tampering attacks (e.g. someone installing a hidden program that [[Wikipedia:Keystroke_logging|records]] the passphrase you use to unlock the encrypted data, or waits for you to unlock it and then secretly copies/sends some of the data to a location where the attacker can retrieve it).
  
'''System encryption''', defined as the encryption of the operating system ''and'' user data, helps to address some of the inadequacies of data encryption.
+
; System encryption
 +
: Defined as the encryption of the operating system ''and'' user data, system encryption helps to address some of the inadequacies of data encryption.
  
Benefits:
+
: Benefits:
* prevents unauthorized physical access to (and tampering with) operating system files ''(but see warning above)''
+
:* prevents unauthorized physical access to (and tampering with) operating system files ''(but see warning above)''
* prevents unauthorized physical access to private data that may cached by the system
+
:* prevents unauthorized physical access to private data that may be cached by the system
Disadvantages:
+
: Disadvantages:
* unlocking of the encrypted parts of the disk can no longer happen during or after user login; it must now happen at boot time
+
:* unlocking of the encrypted parts of the disk can no longer happen during or after user login; it must now happen at boot time
  
 
+
In practice, there is not always a clear line between data encryption and system encryption, and many different compromises and customized setups are possible.
In practice, there's not always a clear line between data encryption and system encryption, and many different compromises and customized setups are possible.
+
  
 
In any case, disk encryption should only be viewed as an adjunct to the existing security mechanisms of the operating system - focused on securing offline physical access, while relying on ''other'' parts of the system to provide things like network security and user-based access control.
 
In any case, disk encryption should only be viewed as an adjunct to the existing security mechanisms of the operating system - focused on securing offline physical access, while relying on ''other'' parts of the system to provide things like network security and user-based access control.
 +
 +
See also [[Wikipedia:Disk encryption]].
  
 
==Available methods==
 
==Available methods==
Line 80: Line 87:
 
The way it is implemented, is that to unlock the folder storing the raw encrypted files in the host filesystem ("lower directory"), it is mounted (using a special stacked pseudo-filesystem) onto itself or optionally a different location ("upper directory"), where the same files then appear in readable form - until it is unmounted again, or the system is turned off.
 
The way it is implemented, is that to unlock the folder storing the raw encrypted files in the host filesystem ("lower directory"), it is mounted (using a special stacked pseudo-filesystem) onto itself or optionally a different location ("upper directory"), where the same files then appear in readable form - until it is unmounted again, or the system is turned off.
  
Available solutions in this category are:
+
Available solutions in this category are [[eCryptfs]] and [[EncFS]].
 
+
;eCryptfs: See [[eCryptfs]].
+
 
+
;EncFS: See [[EncFS]].
+
  
 
===Block device encryption===
 
===Block device encryption===
Line 98: Line 101:
 
:* plain dm-crypt mode, being the original kernel functionality, does not employ the convenience layer. It is more difficult to apply the same cryptographic strength with it. When doing so, longer keys (passphrases or keyfiles) are the result. It has, however, other advantages, described in the following.  
 
:* plain dm-crypt mode, being the original kernel functionality, does not employ the convenience layer. It is more difficult to apply the same cryptographic strength with it. When doing so, longer keys (passphrases or keyfiles) are the result. It has, however, other advantages, described in the following.  
  
;TrueCrypt: See [[TrueCrypt]].
+
;TrueCrypt: Note that the developers of [[TrueCrypt]] ended support for it in May 2014.
 +
 
 +
For practical implications of the chosen layer of operation, see the [[#Practical implications|comparison table]] below, as well as the general write up for [http://ksouedu.com/doc/ecryptfs-utils/ecryptfs-faq.html#compare eCryptfs]. See [[:Category:Encryption]] for the available content of the methods compared below, as well as other tools not included in the table.
  
For practical implications of the chosen layer of operation, see the [[#practical_implications|comparison table]] below, as well as the write up at [http://ksouedu.com/doc/ecryptfs-utils/ecryptfs-faq.html#compare].
 
  
 
===Comparison table===
 
===Comparison table===
 +
 
The column "dm-crypt +/- LUKS" denotes features of dm-crypt for both LUKS ("+") and plain ("-") encryption modes. If a specific feature requires using LUKS, this is indicated by "(with LUKS)". Likewise "(without LUKS)" indicates usage of LUKS is counter-productive to achieve the feature and plain mode should be used.
 
The column "dm-crypt +/- LUKS" denotes features of dm-crypt for both LUKS ("+") and plain ("-") encryption modes. If a specific feature requires using LUKS, this is indicated by "(with LUKS)". Likewise "(without LUKS)" indicates usage of LUKS is counter-productive to achieve the feature and plain mode should be used.
  
 
{| class="wikitable" style="text-align:center; cell-padding:100px; "
 
{| class="wikitable" style="text-align:center; cell-padding:100px; "
 +
! style="text-align:left; background:#ddd"|
 +
=====Summary=====
 +
! style="background:#ddd" | Loop-AES
 +
! style="background:#ddd" | dm-crypt +/- LUKS
 +
! style="background:#ddd" | Truecrypt
 +
! style="background:#ddd" | eCryptfs
 +
! style="background:#ddd" | EncFs
 +
|-
 +
! style="text-align:left; font-weight:normal; background:#eee" | Type
 +
| block device encryption
 +
| block device encryption
 +
| block device encryption
 +
| stacked filesystem encryption
 +
| stacked filesystem encryption
 
|-
 
|-
| colspan="3" style="border-left-color:transparent; border-top-color:transparent; text-align:left;" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Main selling points
=====''summary''=====
+
! scope="col" style="background:#E2E2E2" | Loop-AES
+
! scope="col" style="background:#E2E2E2" | dm-crypt +/- LUKS
+
! scope="col" style="background:#E2E2E2" | Truecrypt
+
! scope="col" style="background:#E2E2E2" | eCryptfs
+
! scope="col" style="background:#E2E2E2" | EncFs
+
|- valign="top"
+
| style="border-left-color:transparent; border-bottom-color:transparent; width:20px" |
+
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
type
+
| colspan="3" | block device encryption
+
| colspan="2" | stacked filesystem encryption
+
|- valign="top"
+
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
main selling points
+
 
| longest-existing one; possibly the fastest; works on legacy systems
 
| longest-existing one; possibly the fastest; works on legacy systems
 
| de-facto standard for block device encryption on Linux; very flexible
 
| de-facto standard for block device encryption on Linux; very flexible
Line 129: Line 132:
 
| slightly faster than EncFS; individual encrypted files portable between systems
 
| slightly faster than EncFS; individual encrypted files portable between systems
 
| easiest one to use; supports non-root administration
 
| easiest one to use; supports non-root administration
|- valign="top"
+
|-
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Availability in Arch Linux
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
availability in Arch Linux
+
 
| must manually compile custom kernel
 
| must manually compile custom kernel
 
| ''kernel modules:'' already shipped with default kernel; ''tools:'' {{Pkg|device-mapper}}, {{Pkg|cryptsetup}} [core]
 
| ''kernel modules:'' already shipped with default kernel; ''tools:'' {{Pkg|device-mapper}}, {{Pkg|cryptsetup}} [core]
| {{Pkg|truecrypt}} [extra]
+
| [https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/truecrypt&id=efe03070990f9e3554508bd982b1bd5a654aa095 truecrypt 7.1a-2] [extra] (read-only features in later versions)
 
| ''kernel module:'' already shipped with default kernel; ''tools:'' {{Pkg|ecryptfs-utils}} [community]
 
| ''kernel module:'' already shipped with default kernel; ''tools:'' {{Pkg|ecryptfs-utils}} [community]
 
| {{Pkg|encfs}} [community]
 
| {{Pkg|encfs}} [community]
|- valign="top"
+
|-
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! style="text-align:left; font-weight:normal; background:#eee" | License
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
license
+
 
| GPL
 
| GPL
 
| GPL
 
| GPL
| custom<sup>[[#Notes_.26_References|[1]]]</sup>
+
| custom<br>[[#See also|[1]]]
 
| GPL
 
| GPL
 
| GPL
 
| GPL
 
|-
 
|-
| colspan="3" style="height:20px; border-color:transparent" |
+
! style="text-align:left; background:#ddd"|
| colspan="5" style="border-right-color:transparent" |
+
=====Basic classification=====
 +
! style="background:#ddd" | Loop-AES
 +
! style="background:#ddd" | dm-crypt +/- LUKS
 +
! style="background:#ddd" | Truecrypt
 +
! style="background:#ddd" | eCryptfs
 +
! style="background:#ddd" | EncFs
 
|-
 
|-
| colspan="3" style="border-left-color:transparent; border-top-color:transparent; text-align:left;" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Encrypts
=====''basic classification''=====
+
| whole block devices
! scope="col" style="background:#E2E2E2" | Loop-AES
+
| whole block devices
! scope="col" style="background:#E2E2E2" | dm-crypt +/- LUKS
+
| whole block devices
! scope="col" style="background:#E2E2E2" | Truecrypt
+
| files
! scope="col" style="background:#E2E2E2" | eCryptfs
+
| files
! scope="col" style="background:#E2E2E2" | EncFs
+
|-
|- valign="top"
+
! style="text-align:left; font-weight:normal; background:#eee" | Container for encrypted data may be...
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
| a disk or disk partition / a file acting as a virtual partition
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
| a disk or disk partition / a file acting as a virtual partition
encrypts...
+
| a disk or disk partition / a file acting as a virtual partition
| colspan="3" | whole block devices
+
| a directory in an existing file system
| colspan="2" | files
+
| a directory in an existing file system
|- valign="top"
+
|-
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Relation to filesystem
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
| operates below filesystem layer: does not care whether the content of the encrypted block device is a filesystem, a partition table, a LVM setup, or anything else
container for encrypted data may be...
+
| operates below filesystem layer: does not care whether the content of the encrypted block device is a filesystem, a partition table, a LVM setup, or anything else
| colspan="3" |
+
| operates below filesystem layer: does not care whether the content of the encrypted block device is a filesystem, a partition table, a LVM setup, or anything else
* a disk or disk partition
+
| adds an additional layer to an existing filesystem, to automatically encrypt/decrypt files whenever they are written/read
* a file acting as a virtual partition
+
| adds an additional layer to an existing filesystem, to automatically encrypt/decrypt files whenever they are written/read
| colspan="2" |
+
|-
* a directory in an existing file system
+
! style="text-align:left; font-weight:normal; background:#eee" | Encryption implemented in...
|- valign="top"
+
| kernelspace
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
| kernelspace
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
| kernelspace
relation to filesystem
+
| kernelspace
| colspan="3" | operates below the filesystem layer - doesn't care whether the content of the encrypted block device is a filesystem, a partition table, a LVM setup, or anything else
+
| userspace (using FUSE)
| colspan="2" | adds an additional layer to an existing filesystem, to automatically encrypt/decrypt files whenever they're written/read
+
|-
|- valign="top"
+
! style="text-align:left; font-weight:normal; background:#eee" | Cryptographic metadata stored in...
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
encryption implemented in...
+
| colspan="4" | kernelspace
+
| userspace<br>''(using FUSE)''
+
|- valign="top"
+
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
cryptographic metadata stored in...
+
 
| ?
 
| ?
 
| with LUKS: LUKS Header  
 
| with LUKS: LUKS Header  
| rowspan="2" | begin/end of (decrypted) device ([http://www.truecrypt.org/docs/volume-format-specification format])
+
| begin/end of (decrypted) device ([http://www.truecrypt.org/docs/volume-format-specification format])
 
| header  of  each encrypted file
 
| header  of  each encrypted file
 
| control file at the top level of each EncFs container
 
| control file at the top level of each EncFs container
|- valign="top"
+
|-
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Wrapped encryption key stored in...
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
wrapped encryption key stored in...
+
 
| ?
 
| ?
 
| with LUKS: LUKS header  
 
| with LUKS: LUKS header  
 +
| begin/end of (decrypted) device ([http://www.truecrypt.org/docs/volume-format-specification format])
 
| key file that can be stored anywhere
 
| key file that can be stored anywhere
 
| control file at the top level of each EncFs container
 
| control file at the top level of each EncFs container
 
|-
 
|-
| colspan="3" style="height:20px; border-color:transparent" |
+
! style="text-align:left; background:#ddd"|
| colspan="5" style="border-right-color:transparent" |
+
=====Practical implications=====
 +
! style="background:#ddd" | Loop-AES
 +
! style="background:#ddd" | dm-crypt +/- LUKS
 +
! style="background:#ddd" | Truecrypt
 +
! style="background:#ddd" | eCryptfs
 +
! style="background:#ddd" | EncFs
 +
|-
 +
! style="text-align:left; font-weight:normal; background:#eee" | File metadata (number of files, dir structure, file sizes, permissions, mtimes, etc.) is encrypted
 +
| <span style="color:#080; font-size:2em">✔</span>
 +
| <span style="color:#080; font-size:2em">✔</span>
 +
| <span style="color:#080; font-size:2em">✔</span>
 +
| <span style="color:#f00; font-size:2em">✖</span><br>(file and dir names can be encrypted though)
 +
| <span style="color:#f00; font-size:2em">✖</span><br>(file and dir names can be encrypted though)
 +
|-
 +
! style="text-align:left; font-weight:normal; background:#eee" | Can be used to encrypt whole hard drives (including partition tables)
 +
| <span style="color:#080; font-size:2em">✔</span>
 +
| <span style="color:#080; font-size:2em">✔</span>
 +
| <span style="color:#080; font-size:2em">✔</span>
 +
| <span style="color:#f00; font-size:2em">✖</span>
 +
| <span style="color:#f00; font-size:2em">✖</span>
 +
|-
 +
! style="text-align:left; font-weight:normal; background:#eee" | Can be used to encrypt swap space
 +
| <span style="color:#080; font-size:2em">✔</span>
 +
| <span style="color:#080; font-size:2em">✔</span>
 +
| <span style="color:#080; font-size:2em">✔</span>
 +
| <span style="color:#f00; font-size:2em">✖</span>
 +
| <span style="color:#f00; font-size:2em">✖</span>
 
|-
 
|-
| colspan="3" style="border-left-color:transparent; border-top-color:transparent; text-align:left;" |
 
  
=====''practical implications''=====
+
! style="text-align:left; font-weight:normal; background:#eee" | Can be used without pre-allocating a fixed amount of space for the encrypted data container
! scope="col" style="background:#E2E2E2" | Loop-AES
+
| <span style="color:#f00; font-size:2em">✖</span>
! scope="col" style="background:#E2E2E2" | dm-crypt +/- LUKS
+
| <span style="color:#f00; font-size:2em">✖</span>
! scope="col" style="background:#E2E2E2" | Truecrypt
+
| <span style="color:#f00; font-size:2em">✖</span>
! scope="col" style="background:#E2E2E2" | eCryptfs
+
| <span style="color:#080; font-size:2em">✔</span>
! scope="col" style="background:#E2E2E2" | EncFs
+
| <span style="color:#080; font-size:2em">✔</span>
|- valign="top"
+
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
file metadata (number of files, dir structure, file sizes, permissions, mtimes, etc.) is encrypted
+
| colspan="3" | <span style="font-size:210%; color:#5F9E23;">✔</span>
+
| colspan="2" | <span style="font-size:160%; color:#CF2525;">✖</span><br>''(file and dir names can be encrypted though)''
+
|- valign="top"
+
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
can be used to encrypt whole hard drives (including partition tables)
+
| colspan="3" | <span style="font-size:210%; color:#5F9E23;">✔</span>
+
| colspan="2" | <span style="font-size:160%; color:#CF2525;">✖</span>
+
|- valign="top"
+
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
can be used to encrypt swap space
+
| colspan="3" | <span style="font-size:210%; color:#5F9E23;">✔</span>
+
| colspan="2" | <span style="font-size:160%; color:#CF2525;">✖</span>
+
|- valign="top"
+
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
can be used without pre-allocating a fixed amount of space for the encrypted data container
+
| colspan="3" | <span style="font-size:160%; color:#CF2525;">✖</span>
+
| colspan="2" | <span style="font-size:210%; color:#5F9E23;">✔</span>
+
|- valign="top"
+
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
can be used to protect existing filesystems without block device access, e.g. NFS or Samba shares, cloud storage, etc.
+
| colspan="3" | &nbsp;&nbsp;&nbsp;&nbsp;<span style="font-size:160%; color:#CF2525;">✖</span><sup>[[#Notes_.26_References|[2]]]</sup>
+
| colspan="2" | <span style="font-size:210%; color:#5F9E23;">✔</span>
+
|- valign="top"
+
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
allows offline file-based backups of encrypted files
+
| colspan="3" | <span style="font-size:160%; color:#CF2525;">✖</span>
+
| colspan="2" | <span style="font-size:210%; color:#5F9E23;">✔</span>
+
 
|-
 
|-
| colspan="3" style="height:20px; border-color:transparent" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Can be used to protect existing filesystems without block device access, e.g. NFS or Samba shares, cloud storage, etc.
| colspan="5" style="border-right-color:transparent" |
+
| <span style="color:#f00; font-size:2em">✖</span><br>[[#See also|[2]]]
 +
| <span style="color:#f00; font-size:2em">✖</span>
 +
| <span style="color:#f00; font-size:2em">✖</span>
 +
| <span style="color:#080; font-size:2em">✔</span>
 +
| <span style="color:#080; font-size:2em">✔</span>
 
|-
 
|-
| colspan="3" style="border-left-color:transparent; border-top-color:transparent; text-align:left;" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Allows offline file-based backups of encrypted files
=====''usability features''=====
+
| <span style="color:#f00; font-size:2em">✖</span>
! scope="col" style="background:#E2E2E2" | Loop-AES
+
| <span style="color:#f00; font-size:2em">✖</span>
! scope="col" style="background:#E2E2E2" | dm-crypt +/- LUKS
+
| <span style="color:#f00; font-size:2em">✖</span>
! scope="col" style="background:#E2E2E2" | Truecrypt
+
| <span style="color:#080; font-size:2em">✔</span>
! scope="col" style="background:#E2E2E2" | eCryptfs
+
| <span style="color:#080; font-size:2em">✔</span>
! scope="col" style="background:#E2E2E2" | EncFs
+
|-
|- valign="top"
+
! style="text-align:left; background:#ddd"|
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
=====Usability features=====
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
! style="background:#ddd" | Loop-AES
support for automounting on login
+
! style="background:#ddd" | dm-crypt +/- LUKS
 +
! style="background:#ddd" | Truecrypt
 +
! style="background:#ddd" | eCryptfs
 +
! style="background:#ddd" | EncFs
 +
|-
 +
! style="text-align:left; font-weight:normal; background:#eee" | Support for automounting on login
 
| ?
 
| ?
| <span style="font-size:210%; color:#5F9E23;">✔</span>
+
| <span style="color:#080; font-size:2em">✔</span>
 
| ?
 
| ?
| <span style="font-size:210%; color:#5F9E23;">✔</span>
+
| <span style="color:#080; font-size:2em">✔</span>
| <span style="font-size:210%; color:#5F9E23;">✔</span>
+
| <span style="color:#080; font-size:2em">✔</span>
|- valign="top"
+
|-
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Support for automatic unmounting in case of inactivity
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
support for automatic unmounting in case of inactivity
+
 
| ?
 
| ?
 
| ?
 
| ?
 
| ?
 
| ?
 
| ?
 
| ?
| <span style="font-size:210%; color:#5F9E23;">✔</span>
+
| <span style="color:#080; font-size:2em">✔</span>
|- valign="top"
+
|-
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Non-root users can create/destroy containers for encrypted data
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
| <span style="color:#f00; font-size:2em">✖</span>
non-root users can create/destroy containers for encrypted data
+
| <span style="color:#f00; font-size:2em">✖</span>
| <span style="font-size:160%; color:#CF2525;">✖</span>
+
| <span style="color:#f00; font-size:2em">✖</span>
| <span style="font-size:160%; color:#CF2525;">✖</span>
+
| <span style="font-size:160%; color:#CF2525;">✖</span>
+
 
| limited
 
| limited
| <span style="font-size:210%; color:#5F9E23;">✔</span>
+
| <span style="color:#080; font-size:2em">✔</span>
|- valign="top"
+
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
provides a GUI
+
| <span style="font-size:160%; color:#CF2525;">✖</span>
+
| <span style="font-size:160%; color:#CF2525;">✖</span>
+
| <span style="font-size:210%; color:#5F9E23;">✔</span>
+
| <span style="font-size:160%; color:#CF2525;">✖</span>
+
| <span style="font-size:210%; color:#5F9E23;">✔</span>
+
 
|-
 
|-
| colspan="3" style="height:20px; border-color:transparent" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Provides a GUI
| colspan="5" style="border-right-color:transparent" |
+
| <span style="color:#f00; font-size:2em">✖</span>
 +
| <span style="color:#f00; font-size:2em">✖</span>
 +
| <span style="color:#080; font-size:2em">✔</span>
 +
| <span style="color:#f00; font-size:2em">✖</span>
 +
| <span style="color:#080; font-size:2em">✔</span>
 +
|-
 +
! style="text-align:left; background:#ddd"|
 +
=====Security features=====
 +
! style="background:#ddd" | Loop-AES
 +
! style="background:#ddd" | dm-crypt +/- LUKS
 +
! style="background:#ddd" | Truecrypt
 +
! style="background:#ddd" | eCryptfs
 +
! style="background:#ddd" | EncFs
 
|-
 
|-
| colspan="3" style="border-left-color:transparent; border-top-color:transparent; text-align:left;" |
 
  
=====''security features''=====
+
! style="text-align:left; font-weight:normal; background:#eee" | Supported ciphers
! scope="col" style="background:#E2E2E2" | Loop-AES
+
! scope="col" style="background:#E2E2E2" | dm-crypt +/- LUKS
+
! scope="col" style="background:#E2E2E2" | Truecrypt
+
! scope="col" style="background:#E2E2E2" | eCryptfs
+
! scope="col" style="background:#E2E2E2" | EncFs
+
|- valign="top"
+
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
supported ciphers
+
 
| AES
 
| AES
| AES, Anubis, CAST5/6, Twofish, Serpent, Camellia, Blowfish, … (every cipher the kernel Crypto API offers)
+
| AES, Anubis, CAST5/6, Twofish, Serpent, Camellia, Blowfish,… (every cipher the kernel Crypto API offers)
 
| AES, Twofish, Serpent
 
| AES, Twofish, Serpent
 
| AES, Blowfish, Twofish...
 
| AES, Blowfish, Twofish...
| AES, Twofish
+
| AES, Blowfish
|- valign="top"
+
|-
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Support for salting
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
support for salting
+
 
| ?
 
| ?
| <span style="font-size:210%; color:#5F9E23;">✔</span><br>(with LUKS)
+
| <span style="color:#080; font-size:2em">✔</span><br>(with LUKS)
| <span style="font-size:210%; color:#5F9E23;">✔</span>
+
| <span style="color:#080; font-size:2em">✔</span>
| <span style="font-size:210%; color:#5F9E23;">✔</span>
+
| <span style="color:#080; font-size:2em">✔</span>
 
| ?
 
| ?
|- valign="top"
+
|-
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Support for cascading multiple ciphers
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
support for cascading multiple ciphers
+
 
| ?
 
| ?
 
| Not in one device, but blockdevices can be cascaded
 
| Not in one device, but blockdevices can be cascaded
| <span style="font-size:210%; color:#5F9E23;">✔</span>
+
| <span style="color:#080; font-size:2em">✔</span>
 
| ?
 
| ?
| <span style="font-size:160%; color:#CF2525;">✖</span>
+
| <span style="color:#f00; font-size:2em">✖</span>
|- valign="top"
+
|-
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Support for key-slot diffusion
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
support for key-slot diffusion
+
 
| ?
 
| ?
| <span style="font-size:210%; color:#5F9E23;">✔</span><br>(with LUKS)
+
| <span style="color:#080; font-size:2em">✔</span><br>(with LUKS)
 
| ?
 
| ?
 
| ?
 
| ?
 
| ?
 
| ?
|- valign="top"
+
|-
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Protection against key scrubbing
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
| <span style="color:#080; font-size:2em">✔</span>
protection against key scrubbing
+
| <span style="color:#080; font-size:2em">✔</span><br>(without LUKS)
| <span style="font-size:210%; color:#5F9E23;">✔</span>
+
| <span style="font-size:210%; color:#5F9E23;">✔</span><br>(without LUKS)
+
 
| ?
 
| ?
 
| ?
 
| ?
 
| ?
 
| ?
|- valign="top"
+
|-
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Support for multiple (independently revokable) keys for the same encrypted data
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
support for multiple (independently revokable) keys for the same encrypted data
+
 
| ?
 
| ?
| <span style="font-size:210%; color:#5F9E23;">✔</span><br>(with LUKS)
+
| <span style="color:#080; font-size:2em">✔</span><br>(with LUKS)
 
| ?
 
| ?
 
| ?
 
| ?
| <span style="font-size:160%; color:#CF2525;">✖</span>
+
| <span style="color:#f00; font-size:2em">✖</span>
|- valign="top"
+
| colspan="3" style="height:20px; border-color:transparent" |
+
| colspan="5" style="border-right-color:transparent" |
+
 
|-
 
|-
| colspan="3" style="border-left-color:transparent; border-top-color:transparent; text-align:left;" |
+
! style="text-align:left; background:#ddd"|
 
+
=====Performance features=====
=====''performance features''=====
+
! style="background:#ddd" | Loop-AES
! scope="col" style="background:#E2E2E2" | Loop-AES
+
! style="background:#ddd" | dm-crypt +/- LUKS
! scope="col" style="background:#E2E2E2" | dm-crypt +/- LUKS
+
! style="background:#ddd" | Truecrypt
! scope="col" style="background:#E2E2E2" | Truecrypt
+
! style="background:#ddd" | eCryptfs
! scope="col" style="background:#E2E2E2" | eCryptfs
+
! style="background:#ddd" | EncFs
! scope="col" style="background:#E2E2E2" | EncFs
+
|-
|- valign="top"
+
! style="text-align:left; font-weight:normal; background:#eee" | Multithreading support
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
multithreading support
+
| ?
+
| <span style="font-size:210%; color:#5F9E23;">✔</span><sup>[[#Notes_.26_References|[8]]]</sup>
+
| <span style="font-size:210%; color:#5F9E23;">✔</span>
+
 
| ?
 
| ?
 +
| <span style="color:#080; font-size:2em">✔</span><br>[[#See also|[8]]]
 +
| <span style="color:#080; font-size:2em">✔</span>
 
| ?
 
| ?
|- valign="top"
 
| style="border-left-color:transparent; border-bottom-color:transparent" |
 
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
 
hardware-accelerated encryption support
 
| <span style="font-size:210%; color:#5F9E23;">✔</span>
 
| <span style="font-size:210%; color:#5F9E23;">✔</span>
 
| <span style="font-size:210%; color:#5F9E23;">✔</span>
 
| <span style="font-size:210%; color:#5F9E23;">✔</span>
 
 
| ?
 
| ?
 
|-
 
|-
| colspan="3" style="height:20px; border-color:transparent" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Hardware-accelerated encryption support
| colspan="3" style="border-right-color:transparent" |
+
| <span style="color:#080; font-size:2em">✔</span>
| colspan="2" style="border-color:transparent" |
+
| <span style="color:#080; font-size:2em">✔</span>
 +
| <span style="color:#080; font-size:2em">✔</span>
 +
| <span style="color:#080; font-size:2em">✔</span>
 +
| <span style="color:#080; font-size:2em">✔</span><br>[[#See also|[13]]]
 
|-
 
|-
| colspan="3" style="border-left-color:transparent; border-top-color:transparent; text-align:left;" |
+
! style="text-align:left; background:#ddd"|
 
+
=====Block device encryption specific=====
=====''block device encryption specific''=====
+
! style="background:#ddd" | Loop-AES
! scope="col" style="background:#E2E2E2" | Loop-AES
+
! style="background:#ddd" | dm-crypt +/- LUKS
! scope="col" style="background:#E2E2E2" | dm-crypt +/- LUKS
+
! style="background:#ddd" | Truecrypt
! scope="col" style="background:#E2E2E2" | Truecrypt
+
! style="background:#ddd" |  
| colspan="2" rowspan="2" style="border-color:transparent" |
+
! style="background:#ddd" |  
|- valign="top"
+
|-
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Support for (manually) resizing the encrypted block device in-place
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
support for (manually) resizing the encrypted block device in-place
+
 
| ?
 
| ?
| <span style="font-size:210%; color:#5F9E23;">✔</span>
+
| <span style="color:#080; font-size:2em">✔</span>
| <span style="font-size:160%; color:#CF2525;">✖</span>
+
| <span style="color:#f00; font-size:2em">✖</span>
 +
! style="background:#ddd" |
 +
! style="background:#ddd" |
 
|-
 
|-
| colspan="3" style="height:20px; border-color:transparent" |
+
! style="text-align:left; background:#ddd"|
| colspan="3" style="border-color:transparent" |
+
=====Stacked filesystem encryption specific=====
| colspan="2" style="border-right-color:transparent" |
+
! style="background:#ddd" |
 +
! style="background:#ddd" |
 +
! style="background:#ddd" |
 +
! style="background:#ddd" | eCryptfs
 +
! style="background:#ddd" | EncFs
 
|-
 
|-
| colspan="6" style="border-left-color:transparent; text-align:left;" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Supported file systems
=====''stacked filesystem encryption specific''=====
+
! style="background:#ddd" |
! scope="col" style="background:#E2E2E2" | eCryptfs
+
! style="background:#ddd" |
! scope="col" style="background:#E2E2E2" | EncFs
+
! style="background:#ddd" |
|- valign="top"
+
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! scope="row" colspan="5" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
supported file systems
+
 
| ext3, ext4, xfs (with caveats), jfs, nfs...
 
| ext3, ext4, xfs (with caveats), jfs, nfs...
| ?
 
|- valign="top"
 
| style="border-left-color:transparent; border-bottom-color:transparent" |
 
! scope="row" colspan="5" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
 
ability to encrypt filenames
 
| <span style="font-size:210%; color:#5F9E23;">✔</span>
 
| <span style="font-size:210%; color:#5F9E23;">✔</span>
 
|- valign="top"
 
| style="border-left-color:transparent; border-bottom-color:transparent" |
 
! scope="row" colspan="5" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
 
ability to ''not'' encrypt filenames
 
| <span style="font-size:210%; color:#5F9E23;">✔</span>
 
| <span style="font-size:210%; color:#5F9E23;">✔</span>
 
|- valign="top"
 
| style="border-left-color:transparent; border-bottom-color:transparent" |
 
! scope="row" colspan="5" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
 
optimized handling of sparse files
 
| <span style="font-size:160%; color:#CF2525;">✖</span>
 
 
| ?
 
| ?
 
|-
 
|-
| colspan="3" style="height:20px; border-color:transparent" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Ability to encrypt filenames
| colspan="5" style="border-right-color:transparent" |
+
! style="background:#ddd" |
 +
! style="background:#ddd" |
 +
! style="background:#ddd" |
 +
| <span style="color:#080; font-size:2em">✔</span>
 +
| <span style="color:#080; font-size:2em">✔</span>
 
|-
 
|-
| colspan="3" style="border-left-color:transparent; border-top-color:transparent; text-align:left;" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Ability to ''not'' encrypt filenames
=====''compatibility & prevalence''=====
+
! style="background:#ddd" |
! scope="col" style="background:#E2E2E2" | Loop-AES
+
! style="background:#ddd" |
! scope="col" style="background:#E2E2E2" | dm-crypt +/- LUKS
+
! style="background:#ddd" |
! scope="col" style="background:#E2E2E2" | Truecrypt
+
| <span style="color:#080; font-size:2em">✔</span>
! scope="col" style="background:#E2E2E2" | eCryptfs
+
| <span style="color:#080; font-size:2em">✔</span>
! scope="col" style="background:#E2E2E2" | EncFs
+
|-
|- valign="top"
+
! style="text-align:left; font-weight:normal; background:#eee" | Optimized handling of sparse files
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! style="background:#ddd" |
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
! style="background:#ddd" |
supported Linux kernel versions
+
! style="background:#ddd" |
 +
| <span style="color:#f00; font-size:2em">✖</span>
 +
| <span style="color:#080; font-size:2em">✔</span>
 +
|-
 +
! style="text-align:left; background:#ddd"|
 +
=====Compatibility & prevalence=====
 +
! style="background:#ddd" | Loop-AES
 +
! style="background:#ddd" | dm-crypt +/- LUKS
 +
! style="background:#ddd" | Truecrypt
 +
! style="background:#ddd" | eCryptfs
 +
! style="background:#ddd" | EncFs
 +
|-
 +
! style="text-align:left; font-weight:normal; background:#eee" | Supported Linux kernel versions
 
| 2.0 or newer
 
| 2.0 or newer
| ?
+
| CBC-mode since 2.6.4, ESSIV 2.6.10, LRW 2.6.20, XTS 2.6.24
 
| ?
 
| ?
 
| ?
 
| ?
 
| 2.4 or newer
 
| 2.4 or newer
|- valign="top"
+
|-
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Encrypted data can also be accessed from Windows
! scope="row" rowspan="3" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" | encrypted data can also be accessed from...
+
| <span style="color:#080; font-size:2em">✔</span><br>(with [[#See also|[3]]], [[#See also|[14]]])
! scope="row" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" | Windows
+
| <span style="color:#080; font-size:2em">✔</span><br>(with [[#See also|[4]]], [[#See also|[14]]])
| <span style="font-size:210%; color:#5F9E23;">✔</span> (with <sup>[[#Notes_.26_References|[3]]]</sup>)
+
| <span style="color:#080; font-size:2em">✔</span>
| <span style="font-size:210%; color:#5F9E23;">✔</span> (with <sup>[[#Notes_.26_References|[4]]]</sup>)
+
| <span style="font-size:210%; color:#5F9E23;">✔</span>
+
 
| ?
 
| ?
| &nbsp;&nbsp;&nbsp;&nbsp;<span style="font-size:210%; color:#5F9E23;">✔</span><sup>[[#Notes_.26_References|[9]]]</sup>
+
| ?<br>[[#See also|[9]]]
|- valign="top"
+
|-
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Encrypted data can also be accessed from Mac OS X
! scope="row" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" | Mac OS X
+
 
| ?
 
| ?
 
| ?
 
| ?
| <span style="font-size:210%; color:#5F9E23;">✔</span>
+
| <span style="color:#080; font-size:2em">✔</span>
 
| ?
 
| ?
| &nbsp;&nbsp;&nbsp;&nbsp;<span style="font-size:210%; color:#5F9E23;">✔</span><sup>[[#Notes_.26_References|[5]]]</sup>
+
| <span style="color:#080; font-size:2em">✔</span><br>[[#See also|[5]]]
|- valign="top"
+
|-
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Encrypted data can also be accessed from FreeBSD
! scope="row" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" | FreeBSD
+
 
| ?
 
| ?
 
| ?
 
| ?
| <span style="font-size:160%; color:#CF2525;">✖</span>
+
| <span style="color:#f00; font-size:2em">✖</span>
 
| ?
 
| ?
| &nbsp;&nbsp;&nbsp;&nbsp;<span style="font-size:210%; color:#5F9E23;">✔</span><sup>[[#Notes_.26_References|[6]]]</sup>
+
| <span style="color:#080; font-size:2em">✔</span><br>[[#See also|[6]]]
|- valign="top"
+
|-
| style="border-left-color:transparent; border-bottom-color:transparent" |
+
 
! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+
! style="text-align:left; font-weight:normal; background:#eee" | Used by
used by
+
 
| ?
 
| ?
|  
+
| Debian/Ubuntu installer (system encryption)<br>Fedora installer  
* Debian/Ubuntu installer (system encryption)
+
* Fedora installer  
+
 
| ?
 
| ?
|
+
| Ubuntu installer (home dir encryption)<br>Chromium OS (encryption of cached user data [[#See also|[7]]])
* Ubuntu installer (home dir encryption)
+
* Chromium OS (encryption of cached user data<sup>[[#Notes_.26_References|[7]]]</sup>)
+
 
| ?
 
| ?
 
|}
 
|}
Line 509: Line 457:
 
===Choosing a setup===
 
===Choosing a setup===
  
Which disk encryption setup is appropriate for you will depend on your goals (please read [[#Why_use_encryption?]] above) and system parameters.<br>
+
Which disk encryption setup is appropriate for you will depend on your goals (please read [[#Why use encryption?]] above) and system parameters.
 +
 
 
Among other things, you will need to answer the following questions:
 
Among other things, you will need to answer the following questions:
  
<ul>
+
;What kind of "attacker" do you want to protect against?
<li>What kind of "attacker" do you want to protect against?
+
<ul style="list-style-type:circle;color:#777;font-size:90%;line-height:1em;margin-top:0">
+
<li>Casual computer user snooping around your disk when your system is turned off / stolen / etc.</li>
+
<li>Professional cryptanalyst who can get repeated read/write access to your system before and after you use it</li>
+
<li>anything in between</li>
+
</ul></li>
+
</ul>
+
  
<ul>
+
* Casual computer user snooping around your disk when your system is turned off / stolen / etc.
<li>What encryption strategy shall be employed?
+
* Professional cryptanalyst who can get repeated read/write access to your system before and after you use it
<ul style="list-style-type:circle;color:#777;font-size:90%;line-height:1em;margin-top:0">
+
* Anything in between
<li>data encryption</li>
+
<li>system encryption</li>
+
<li>something in between</li>
+
</ul></li></ul>
+
  
<ul>
+
;What encryption strategy shall be employed?
<li>How should swap, {{ic|/tmp}}, etc. be taken care of?
+
<ul style="list-style-type:circle;color:#777;font-size:90%;line-height:1em;margin-top:0">
+
<li>ignore, and hope no data is leaked</li>
+
<li>disable or mount as ramdisk</li>
+
<li>encrypt ''(as part of full disk encryption, or separately)''</li>
+
</ul></li></ul>
+
  
<ul>
+
* Data encryption
<li>How should encrypted parts of the disk be unlocked?
+
* System encryption
<ul style="list-style-type:circle;color:#777;font-size:90%;line-height:1em;margin-top:0">
+
* Something in between
<li>passphrase ''(same as login password, or separate)''</li>
+
<li>keyfile ''(e.g. on a USB stick, that you keep in a safe place or carry around with yourself)''</li>
+
<li>both</li>
+
</ul></li>
+
</ul>
+
  
<ul>
+
;How should swap, {{ic|/tmp}}, etc. be taken care of?
<li>''When'' should encrypted parts of the disk be unlocked?
+
<ul style="list-style-type:circle;color:#777;font-size:90%;line-height:1em;margin-top:0">
+
<li>before boot</li>
+
<li>during boot</li>
+
<li>at login</li>
+
<li>manually on demand ''(after login)''</li>
+
</ul></li>
+
</ul>
+
  
<ul>
+
* Ignore, and hope no data is leaked
<li>How should multiple users be accomodated?
+
* Disable or mount as ramdisk
<ul style="list-style-type:circle;color:#777;font-size:90%;line-height:1em;margin-top:0">
+
* Encrypt ''(as part of full disk encryption, or separately)''
<li>not at all</li>
+
<li>using a shared passphrase/key</li>
+
<li>idependently issued and revocable passphrases/keys for the same encrypted part of the disk</li>
+
<li>separate encrypted parts of the disk for different users</li>
+
</ul></li>
+
</ul>
+
  
Then you can go on to make the required technical choices (see [[#Available_methods]] above, and [[#How_the_encryption_works]] below), regarding:
+
;How should encrypted parts of the disk be unlocked?
 +
 
 +
* Passphrase ''(same as login password, or separate)''
 +
* Keyfile ''(e.g. on a USB stick, that you keep in a safe place or carry around with yourself)''
 +
* Both
 +
 
 +
;''When'' should encrypted parts of the disk be unlocked?
 +
 
 +
* Before boot
 +
* During boot
 +
* At login
 +
* Manually on demand ''(after login)''
 +
 
 +
;How should multiple users be accomodated?
 +
 
 +
* Not at all
 +
* Using a shared passphrase/key
 +
* Independently issued and revocable passphrases/keys for the same encrypted part of the disk
 +
* Separate encrypted parts of the disk for different users
 +
 
 +
Then you can go on to make the required technical choices (see [[#Available methods]] above, and [[#How the encryption works]] below), regarding:
  
 
* stacked filesystem encryption vs. blockdevice encryption
 
* stacked filesystem encryption vs. blockdevice encryption
Line 573: Line 506:
 
* metadata storage
 
* metadata storage
 
* location of the "lower directory" (in case of stacked filesystem encryption)
 
* location of the "lower directory" (in case of stacked filesystem encryption)
 +
 +
=== Examples ===
  
 
In practice, it could turn out something like:
 
In practice, it could turn out something like:
  
;Example 1: simple data encryption (internal hard drive) using a virtual folder called "~/Private" in the user's home dir encrypted with [[EncFS]]<span style="color:#777"><br>└──> encrypted versions of the files stored on-disk in ~/.Private<br>└──> unlocked on demand with dedicated passphrase</span><br>
+
;Example 1: Simple data encryption (internal hard drive) using a virtual folder called {{ic|~/Private}} in the user's home directory encrypted with [[EncFS]]<br>└──> encrypted versions of the files stored on-disk in {{ic|~/.Private}}<br>└──> unlocked on demand with dedicated passphrase
  
;Example 2: simple data encryption (removable media), an USB drive encrypted with [[TrueCrypt]]<span style="color:#777"><br>└──> unlocked when attached to the computer (using dedicated passphrase + using ~/photos/2006-09-04a.jpg as covert keyfile)</span>
+
;Example 2: Simple data encryption (removable media), an USB drive encrypted with [[TrueCrypt]]<br>└──> unlocked when attached to the computer (using dedicated passphrase plus using a covert keyfile such as {{ic|~/photos/2006-09-04a.jpg}})
  
;Example 3: partial system encryption with each user's '''home directory''' encrypted with [[ECryptfs]]<span style="color:#777"><br>└──> unlocked on respective user login, using login passphrase<br>└──> '''swap''' and '''/tmp''' partitions encrypted with [[dm-crypt|Dm-crypt with LUKS]], using an automatically generated per-session throwaway key<span style="color:#777"><br>└──> indexing/caching of contents of /home by slocate (and similar apps) disabled.
+
;Example 3: Partial system encryption with each user's home directory encrypted with [[ECryptfs]]<br>└──> unlocked on respective user login, using login passphrase<br>└──> {{ic|swap}} and {{ic|/tmp}} partitions encrypted with [[Dm-crypt with LUKS]], using an automatically generated per-session throwaway key<br>└──> indexing/caching of contents of {{ic|/home}} by ''slocate'' (and similar apps) disabled.
  
;Example 4: system encryption - whole hard drive except /boot partition encrypted with [[dm-crypt|Dm-crypt with LUKS]] <span style="color:#777"><br>└──> unlocked during boot, using passphrases or USB stick with keyfiles<br>└──> Maybe different passphrases/keys per user - independently revocable<br>└──> Maybe encryption spanning multiple drives or partition layout flexibility with [[Dm-crypt/Encrypting an Entire System#LUKS on LVM|LUKS on LVM]]</span>
+
;Example 4: System encryption - whole hard drive except {{ic|/boot}} partition (however, {{ic|/boot}} can be encrypted with [[GRUB]]) encrypted with [[Dm-crypt with LUKS]] <br>└──> unlocked during boot, using passphrases or USB stick with keyfiles<br>└──> Maybe different passphrases/keys per user - independently revocable<br>└──> Maybe encryption spanning multiple drives or partition layout flexibility with [[Dm-crypt/Encrypting an entire system#LUKS on LVM|LUKS on LVM]]
  
;Example 5: hidden/plain system encryption - whole hard drive encrypted with [[dm-crypt|plain dm-crypt]] <span style="color:#777"><br>└──> USB-boot, using dedicated passphrase + USB stick with keyfile<br>└──> data integrity checked before mounting<br>└──> /boot partition located on aforementioned USB stick</span>
+
;Example 5: Hidden/plain system encryption - whole hard drive encrypted with [[dm-crypt|plain dm-crypt]] <br>└──> USB-boot, using dedicated passphrase plus USB stick with keyfile<br>└──> data integrity checked before mounting<br>└──> {{ic|/boot}} partition located on aforementioned USB stick
  
 
Many other combinations are of course possible. You should carefully plan what kind of setup will be appropriate for your system.
 
Many other combinations are of course possible. You should carefully plan what kind of setup will be appropriate for your system.
Line 590: Line 525:
 
===Choosing a strong passphrase===
 
===Choosing a strong passphrase===
  
When relying on a passphrase, it must be complex enough to not be easy to guess or break using brute-force attacks. The tenets of strong passphrases are based on ''length'' and ''randomness''. In cryptography the quality of a passphrase is referred to as its [[Wikipedia:Entropic_security]].
+
See [[Security#Passwords]].
 
+
Refer to [http://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] for a detailed discussion, and especially consider the [http://world.std.com/~reinhold/diceware.html Diceware Passphrase] method.
+
Also, you can check entropy level of your chosen passphrase [http://rumkin.com/tools/password/passchk.php here].
+
 
+
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.
+
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} either also ends up on an encrypted partition, or uses a strong hash algorithm (i.e. sha512/bcrypt, not md5) for the stored password hash (see [[SHA_password_hashes]] for more info).
+
  
 
===Preparing the disk===
 
===Preparing the disk===
Line 602: Line 531:
 
Before setting up disk encryption on a (part of a) disk, consider securely wiping it first. This consists of overwriting the entire drive or partition with a stream of zero bytes or random bytes, and is done for one or both of the following reasons:
 
Before setting up disk encryption on a (part of a) disk, consider securely wiping it first. This consists of overwriting the entire drive or partition with a stream of zero bytes or random bytes, and is done for one or both of the following reasons:
  
<ul>
+
;Prevent recovery of previously stored data
<li><p>'''prevent recovery of previously stored data'''</p>
+
 
Disk encryption doesn't change the fact that individual sectors are only overwritten on demand, when the file system creates or modifies the data those particular sectors hold (see [[#How_the_encryption_works]] below). Sectors which the filesystem considers "not currently used" are not touched, and may still contain remnants of data from previous filesystems. The only way to make sure that all data which you previously stored on the drive can not be [[Wikipedia:Data_recovery|recovered]], is to manually erase it.<br>
+
Disk encryption does not change the fact that individual sectors are only overwritten on demand, when the file system creates or modifies the data those particular sectors hold (see [[#How the encryption works]] below). Sectors which the filesystem considers "not currently used" are not touched, and may still contain remnants of data from previous filesystems. The only way to make sure that all data which you previously stored on the drive can not be [[Wikipedia:Data_recovery|recovered]], is to manually erase it.
 
For this purpose it does not matter whether zero bytes or random bytes are used (although wiping with zero bytes will be much faster).
 
For this purpose it does not matter whether zero bytes or random bytes are used (although wiping with zero bytes will be much faster).
</li>
 
  
<li><p>'''prevent disclosure of usage patterns on the encrypted drive'''</p>
+
;Prevent disclosure of usage patterns on the encrypted drive
Ideally, the whole encrypted part of the disk should be indistinguishable from uniformly random data. This way, no unauthorized person can know which and how many sectors actually contain encrypted data - which may be a desirable goal in itself (as part of true confidentiality), and also serves as an additional barrier against attackers trying to break the encryption.<br>
+
 
 +
Ideally, the whole encrypted part of the disk should be indistinguishable from uniformly random data. This way, no unauthorized person can know which and how many sectors actually contain encrypted data - which may be a desirable goal in itself (as part of true confidentiality), and also serves as an additional barrier against attackers trying to break the encryption.
 
In order to satisfy this goal, wiping the disk using high-quality random bytes is crucial.
 
In order to satisfy this goal, wiping the disk using high-quality random bytes is crucial.
</li>
 
</ul>
 
  
 
The second goal only makes sense in combination with block device encryption, because in the case of stacked filesystem encryption the encrypted data can easily be located anyways (in the form of distinct encrypted files in the host filesystem). Also note that even if you only intend to encrypt a particular folder, you will have to erase the whole partition if you want to get rid of files that were previously stored in that folder in unencrypted form (due to [[Wikipedia::File_system_fragmentation|disk fragmentation]]). If there are other folders on the same partition, you will have to back them up and move them back afterwards.
 
The second goal only makes sense in combination with block device encryption, because in the case of stacked filesystem encryption the encrypted data can easily be located anyways (in the form of distinct encrypted files in the host filesystem). Also note that even if you only intend to encrypt a particular folder, you will have to erase the whole partition if you want to get rid of files that were previously stored in that folder in unencrypted form (due to [[Wikipedia::File_system_fragmentation|disk fragmentation]]). If there are other folders on the same partition, you will have to back them up and move them back afterwards.
  
Once you have decided which kind of disk erasure you want to perform, refer to the [[Securely_wipe_disk]] article for technical instructions.
+
Once you have decided which kind of disk erasure you want to perform, refer to the [[Securely wipe disk]] article for technical instructions.
  
 
{{Tip|In deciding which method to use for secure erasure of a hard disk drive, remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}
 
{{Tip|In deciding which method to use for secure erasure of a hard disk drive, remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}
Line 654: Line 581:
 
The entropy of the key is of utmost importance for the security of the encryption. A randomly generated byte string of a certain length, for example 32 bytes (256 bits), has desired properties but is not feasible to remember and apply manually during the mount.  
 
The entropy of the key is of utmost importance for the security of the encryption. A randomly generated byte string of a certain length, for example 32 bytes (256 bits), has desired properties but is not feasible to remember and apply manually during the mount.  
  
For that reason two techniques are used as aides. The first is the application of cryptography to increase the entropic property of the master key, usually involving a separate human-friendly passphrase. For the different types of encryption the [[#Comparison_table]] lists respective features. The second method is to create a keyfile with high entropy and store it on a medium separate from the data drive to be encrypted.  
+
For that reason two techniques are used as aides. The first is the application of cryptography to increase the entropic property of the master key, usually involving a separate human-friendly passphrase. For the different types of encryption the [[#Comparison table]] lists respective features. The second method is to create a keyfile with high entropy and store it on a medium separate from the data drive to be encrypted.  
  
''Further reading:''
+
See also [[Wikipedia:Authenticated encryption]].
* [[Wikipedia:Authenticated_encryption]]
+
  
 
===Keys, keyfiles and passphrases===
 
===Keys, keyfiles and passphrases===
Line 663: Line 589:
 
The following are examples how to store and cryptographically secure a master key with a keyfile:
 
The following are examples how to store and cryptographically secure a master key with a keyfile:
  
<ul>
+
;Stored in a plaintext keyfile
<li><p>'''''stored in a plaintext keyfile'''''</p>
+
  
 
Simply storing the master key in a file (in readable form) is the simplest option. The file - called a "keyfile" - can be placed on a USB stick that you keep in a secure location and only connect to the computer when you want to mount the encrypted parts of the disk (e.g. during boot or login).
 
Simply storing the master key in a file (in readable form) is the simplest option. The file - called a "keyfile" - can be placed on a USB stick that you keep in a secure location and only connect to the computer when you want to mount the encrypted parts of the disk (e.g. during boot or login).
</li>
 
  
<li><p>'''''stored in passphrase-protected form in a keyfile or on the disk itself'''''</p>
+
;Stored in passphrase-protected form in a keyfile or on the disk itself
  
 
The master key (and thus the encrypted data) can be protected with a secret passphrase, which you will have to remember and enter each time you want to mount the encrypted block device or folder. See [[#Cryptographic metadata]] below for details.
 
The master key (and thus the encrypted data) can be protected with a secret passphrase, which you will have to remember and enter each time you want to mount the encrypted block device or folder. See [[#Cryptographic metadata]] below for details.
  
<li><p>'''''randomly generated on-the-fly for each session'''''</p>
+
;Randomly generated on-the-fly for each session
  
 
In some cases, e.g. when encrypting swap space or a {{ic|/tmp}} partition, it is not necessary to keep a persistent master key at all. A new throwaway key can be randomly generated for each session, without requiring any user interaction. This means that once unmounted, all files written to the partition in question can never be decrypted again by ''anyone'' - which in those particular use-cases is perfectly fine.
 
In some cases, e.g. when encrypting swap space or a {{ic|/tmp}} partition, it is not necessary to keep a persistent master key at all. A new throwaway key can be randomly generated for each session, without requiring any user interaction. This means that once unmounted, all files written to the partition in question can never be decrypted again by ''anyone'' - which in those particular use-cases is perfectly fine.
</li>
 
</ul>
 
  
 
===Cryptographic metadata===
 
===Cryptographic metadata===
Line 685: Line 607:
 
A common setup is to apply so-called "key stretching" to the passphrase (via a "key derivation function"), and use the resulting enhanced passphrase as the mount key for decrypting the actual master key (which has been previously stored in encrypted form):
 
A common setup is to apply so-called "key stretching" to the passphrase (via a "key derivation function"), and use the resulting enhanced passphrase as the mount key for decrypting the actual master key (which has been previously stored in encrypted form):
  
<pre>
 
 
  ╭┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╮                        ╭┈┈┈┈┈┈┈┈┈┈┈╮
 
  ╭┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╮                        ╭┈┈┈┈┈┈┈┈┈┈┈╮
 
  ┊ mount passphrase ┊━━━━━⎛key derivation⎞━━━▶┊ mount key ┊
 
  ┊ mount passphrase ┊━━━━━⎛key derivation⎞━━━▶┊ mount key ┊
Line 695: Line 616:
 
  │ encrypted master key│━━━━━━━━━━━━━━━━━━━━━━(decryption)━━━▶┊ master key ┊
 
  │ encrypted master key│━━━━━━━━━━━━━━━━━━━━━━(decryption)━━━▶┊ master key ┊
 
  ╰─────────────────────╯                                      ╰┈┈┈┈┈┈┈┈┈┈┈┈╯
 
  ╰─────────────────────╯                                      ╰┈┈┈┈┈┈┈┈┈┈┈┈╯
</pre>
 
  
 
The '''key derivation function''' (e.g. PBKDF2 or scrypt) is deliberately slow (it applies many iterations of a hash function, e.g. 1000 iterations of HMAC-SHA-512), so that brute-force attacks to find the passphrase are rendered infeasible. For the normal use-case of an authorized user, it will only need to be calculated once per session, so the small slowdown is not a problem.
 
The '''key derivation function''' (e.g. PBKDF2 or scrypt) is deliberately slow (it applies many iterations of a hash function, e.g. 1000 iterations of HMAC-SHA-512), so that brute-force attacks to find the passphrase are rendered infeasible. For the normal use-case of an authorized user, it will only need to be calculated once per session, so the small slowdown is not a problem.
<br>It also takes an additional blob of data, the so-called "'''salt'''", as an argument - this is randomly generated once during set-up of the disk encryption and stored unprotected as part of the cryptographic metadata. Because it will be a different value for each setup, this makes it infeasible for attackers to speed up brute-force attacks using precomputed tables for the key derivation function.
+
It also takes an additional blob of data, the so-called "'''salt'''", as an argument - this is randomly generated once during set-up of the disk encryption and stored unprotected as part of the cryptographic metadata. Because it will be a different value for each setup, this makes it infeasible for attackers to speed up brute-force attacks using precomputed tables for the key derivation function.
  
 
The '''encrypted master key''' can be stored on disk together with the encrypted data. This way, the confidentiality of the encrypted data depends completely on the secret passphrase.  
 
The '''encrypted master key''' can be stored on disk together with the encrypted data. This way, the confidentiality of the encrypted data depends completely on the secret passphrase.  
Line 704: Line 624:
 
Additional security can be attained by instead storing the encrypted master key in a keyfile on e.g. a USB stick. This provides '''two-factor authentication''': Accessing the encrypted data now requires something only you ''know'' (the passphrase), and additionally something only you ''have'' (the keyfile).
 
Additional security can be attained by instead storing the encrypted master key in a keyfile on e.g. a USB stick. This provides '''two-factor authentication''': Accessing the encrypted data now requires something only you ''know'' (the passphrase), and additionally something only you ''have'' (the keyfile).
  
Another way of achieving two-factor authentication is to augment the above key retrieval scheme to mathematically "combine" the passphrase with byte data read from one or more external files (located on a USB stick or similar), before passing it to the key derivation function.<br>The files in question can be anything, e.g. normal JPEG images, which can be beneficial for [[#Plausible deniability]]. They are still called "keyfiles" in this context, though.
+
Another way of achieving two-factor authentication is to augment the above key retrieval scheme to mathematically "combine" the passphrase with byte data read from one or more external files (located on a USB stick or similar), before passing it to the key derivation function.The files in question can be anything, e.g. normal JPEG images, which can be beneficial for [[#Plausible deniability]]. They are still called "keyfiles" in this context, though.
  
 
After it has been derived, the master key is securely stored in memory (e.g. in a kernel keyring), for as long as the encrypted block device or folder is mounted.
 
After it has been derived, the master key is securely stored in memory (e.g. in a kernel keyring), for as long as the encrypted block device or folder is mounted.
Line 730: Line 650:
 
When comparing the parameters used by both modes one notes that dm-crypt plain mode has parameters relating to how to locate the keyfile (e.g. {{ic|--keyfile-size}}, {{ic|--keyfile-offset}}). The dm-crypt LUKS mode does not need these, because each blockdevice contains a header with the cryptographic metadata at the beginning. The header includes the used cipher, the encrypted master-key itself and parameters required for its derivation for decryption. The latter parameters in turn result from options used during initial encryption of the master-key [e.g. {{ic|--iter-time}}, {{ic|--use-random}}).  
 
When comparing the parameters used by both modes one notes that dm-crypt plain mode has parameters relating to how to locate the keyfile (e.g. {{ic|--keyfile-size}}, {{ic|--keyfile-offset}}). The dm-crypt LUKS mode does not need these, because each blockdevice contains a header with the cryptographic metadata at the beginning. The header includes the used cipher, the encrypted master-key itself and parameters required for its derivation for decryption. The latter parameters in turn result from options used during initial encryption of the master-key [e.g. {{ic|--iter-time}}, {{ic|--use-random}}).  
  
For the dis-/advantages of the different techniques, please refer back to [[#Comparison_table]] or browse the specific pages.  
+
For the dis-/advantages of the different techniques, please refer back to [[#Comparison table]] or browse the specific pages.  
  
''Further reading:''
+
See also:
 
* [[Wikipedia:Passphrase]]
 
* [[Wikipedia:Passphrase]]
* [[Wikipedia:Key_(cryptography)]]
+
* [[Wikipedia:Key (cryptography)]]
* [[Wikipedia:Key_management]]
+
* [[Wikipedia:Key management]]
* [[Wikipedia:Key_derivation_function]]
+
* [[Wikipedia:Key derivation function]]
  
 
===Ciphers and modes of operation===
 
===Ciphers and modes of operation===
Line 754: Line 674:
 
| ''approved by the NSA for protecting "SECRET" and "TOP SECRET" classified US-government information (when used with a key size of 192 or 256 bits)''
 
| ''approved by the NSA for protecting "SECRET" and "TOP SECRET" classified US-government information (when used with a key size of 192 or 256 bits)''
 
|-
 
|-
! scope="row" style="text-align:right" | [[Wikipedia:Blowfish_%28cipher%29|Blowfish]]
+
! scope="row" style="text-align:right" | [[wikipedia:Blowfish (cipher)|Blowfish]]
 
| 64 bits
 
| 64 bits
 
| 32–448 bits
 
| 32–448 bits
Line 763: Line 683:
 
| 128, 192 or 256 bits
 
| 128, 192 or 256 bits
 
| ''developed as successor of Blowfish, but has not attained as much widespread usage''
 
| ''developed as successor of Blowfish, but has not attained as much widespread usage''
 +
|-
 +
! scope="row" style="text-align:right" | [[wikipedia:Serpent (cipher)|Serpent]]
 +
| 128 bits
 +
| 128, 192 or 256 bits
 +
| Considered the most secure of the five AES-competition finalists[[#See also|[10]]][[#See also|[11]]][[#See also|[12]]].
 
|}
 
|}
  
Line 794: Line 719:
 
When decrypting, the procedure is reversed analogously.
 
When decrypting, the procedure is reversed analogously.
  
One thing worth noting is the generation of the unique initialization vector for each sector. The simplest choice is to calculate it in a predictable fashion from a readily available value such as the sector number. However, this might allow an attacker with repeated access to the system to perform a so-called [http://en.wikipedia.org/wiki/Watermarking_attack watermarking attack]. To prevent that, a method called "Encrypted salt-sector initialization vector ('''ESSIV''')" can be used to generate the initialization vectors in a way that makes them look completely random to a potential attacker.
+
One thing worth noting is the generation of the unique initialization vector for each sector. The simplest choice is to calculate it in a predictable fashion from a readily available value such as the sector number. However, this might allow an attacker with repeated access to the system to perform a so-called [[wikipedia:Watermarking_attack|watermarking attack]]. To prevent that, a method called "Encrypted salt-sector initialization vector ('''ESSIV''')" can be used to generate the initialization vectors in a way that makes them look completely random to a potential attacker.
  
There are also a number of other, more complicated modes of operation available for disk encryption, which already provide built-in security against such attacks (and hence don't require ESSIV).
+
There are also a number of other, more complicated modes of operation available for disk encryption, which already provide built-in security against such attacks (and hence do not require ESSIV).
 
Some can also additionally guarantee authenticity of the encrypted data (i.e. confirm that it has not been modified/corrupted by someone who does not have access to the key).
 
Some can also additionally guarantee authenticity of the encrypted data (i.e. confirm that it has not been modified/corrupted by someone who does not have access to the key).
  
''Further reading:''
+
See also:
* [[Wikipedia:Disk_encryption_theory]]
+
* [[Wikipedia:Disk encryption theory]]
* [[Wikipedia:Block_cipher]]
+
* [[Wikipedia:Block cipher]]
* [[Wikipedia:Block_cipher_modes_of_operation]]
+
* [[Wikipedia:Block cipher modes of operation]]
  
 
===Plausible deniability===
 
===Plausible deniability===
  
Please refer to [[Wikipedia:Plausible deniability]]
+
See [[Wikipedia:Plausible deniability]].
 +
 
 +
== See also ==
  
==Notes & References==
+
# [[#Summary|^]] see http://www.truecrypt.org/legal/license
<small>
+
# [[#Practical implications|^]] well, a single file in those filesystems could be used as a container (virtual loop-back device!) but then one would not actually be using the filesystem (and the features it provides) anymore
# [[#summary|^]] see http://www.truecrypt.org/legal/license
+
# [[#Compatibility & prevalence|^]] [http://www.scherrer.cc/crypt CrossCrypt] {{Dead link|2015|01|20}} - Open Source AES and TwoFish Linux compatible on the fly encryption for Windows XP and Windows 2000
# [[#practical_implications|^]] well, a single file in those filesystems could be used as a container (virtual loop-back device!) but then one wouldn't actually be using the filesystem (and the features it provides) anymore
+
# [[#Compatibility & prevalence|^]] (1) [http://sourceforge.net/projects/freeotfe.mirror/ FreeOTFE (on sf.net)]  (2) [http://web.archive.org/web/20130531062457/http://freeotfe.org/ FreeOTFE (archived)] - supports Windows 2000 and later (for PC), and Windows Mobile 2003 and later (for PDA)
# [[#compatibility_.26_prevalence|^]] [http://www.scherrer.cc/crypt CrossCrypt] - Open Source AES and TwoFish Linux compatible on the fly encryption for Windows XP and Windows 2000
+
# [[#Compatibility & prevalence|^]] see [http://www.arg0.net/encfs-mac-build EncFs build instructions for Mac]
# [[#compatibility_.26_prevalence|^]] (1) [http://sourceforge.net/projects/freeotfe.mirror/ FreeOTFE (on sf.net)]  (2) [http://web.archive.org/web/20130531062457/http://freeotfe.org/ FreeOTFE (archived)] - supports Windows 2000 and later (for PC), and Windows Mobile 2003 and later (for PDA)
+
# [[#Compatibility & prevalence|^]] see http://www.freshports.org/sysutils/fusefs-encfs/
# [[#compatibility_.26_prevalence|^]] see [http://www.arg0.net/encfs-mac-build EncFs build instructions for Mac]
+
# [[#Compatibility & prevalence|^]] see http://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data
# [[#compatibility_.26_prevalence|^]] see http://www.freshports.org/sysutils/fusefs-encfs/
+
# [[#Compatibility & prevalence|^]] http://kernelnewbies.org/Linux_2_6_38#head-49f5f735853f8cc7c4d89e5c266fe07316b49f4c
# [[#compatibility_.26_prevalence|^]] see http://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data
+
# [[#Compatibility & prevalence|^]] http://members.ferrara.linux.it/freddy77/encfs.html
# [[#compatibility_.26_prevalence|^]] http://kernelnewbies.org/Linux_2_6_38#head-49f5f735853f8cc7c4d89e5c266fe07316b49f4c
+
# [[#Compatibility & prevalence|^]] http://csrc.nist.gov/archive/aes/round2/r2report.pdf
# [[#compatibility_.26_prevalence|^]] http://members.ferrara.linux.it/freddy77/encfs.html
+
# [[#Compatibility & prevalence|^]] https://www.cl.cam.ac.uk/~rja14/Papers/serpentcase.pdf
</small>
+
# [[#Compatibility & prevalence|^]] https://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf
 +
# [[#Performance features|^]] https://github.com/vgough/encfs/issues/118
 +
# [[#Compatibility & prevalence|^]] [https://github.com/t-d-k/doxbox DOXBOX] - support to open dm-crypt / LUKS in newer Windows releases (includes fork from OTFE)

Latest revision as of 13:59, 14 August 2016

This article discusses common techniques available in Arch Linux for cryptographically protecting a logical part of a storage disk (folder, partition, whole disk, ...), so that all data that is written to it is automatically encrypted, and decrypted on-the-fly when read again.

"Storage disks" in this context can be your computer's hard drive(s), external devices like USB flash drives or DVD's, as well as virtual storage disks like loop-back devices or cloud storage (as long as Arch Linux can address it as a block device or filesystem).

If you already know what you want to protect and how you want to encrypt, you are encouraged to directly browse the related how-to articles listed on the right.

Why use encryption?

Disk encryption ensures that files are always stored on disk in an encrypted form. The files only become available to the operating system and applications in readable form while the system is running and unlocked by a trusted user. An unauthorized person looking at the disk contents directly, will only find garbled random-looking data instead of the actual files.

For example, this can prevent unauthorized viewing of the data when the computer or hard-disk is:

  • located in a place to which non-trusted people might gain access while you are away
  • lost or stolen, as with laptops, netbooks or external storage devices
  • in the repair shop
  • discarded after its end-of-life

In addition, disk encryption can also be used to add some security against unauthorized attempts to tamper with your operating system – for example, the installation of keyloggers or Trojan horses by attackers who can gain physical access to the system while you are away.

Warning: Disk encryption does not protect your data from all threats.

You will still be vulnerable to:

  • Attackers who can break into your system (e.g. over the Internet) while it is running and after you have already unlocked and mounted the encrypted parts of the disk.
  • Attackers who are able to gain physical access to the computer while it is running (even if you use a screenlocker), or very shortly after it was running, if they have the resources to perform a cold boot attack.
  • A government entity, which not only has the resources to easily pull off the above attacks, but also may simply force you to give up your keys/passphrases using various techniques of coercion. In most non-democratic countries around the world, as well as in the USA and UK, it may be legal for law enforcement agencies to do so if they have suspicions that you might be hiding something of interest.

A very strong disk encryption setup (e.g. full system encryption with authenticity checking and no plaintext boot partition) is required to stand a chance against professional attackers who are able to tamper with your system before you use it. And even then it is doubtful whether it can really prevent all types of tampering (e.g. hardware keyloggers). The best remedy might be hardware-based full disk encryption and Trusted Computing.

Warning: Disk encryption also will not protect you against someone simply wiping your disk. Regular backups are recommended to keep your data safe.

Data encryption vs system encryption

Data encryption
Defined as encrypting only the user's data itself (often located within the /home directory, or on removable media like a data DVD), data encryption is the simplest and least intrusive use of disk encryption, but has some significant drawbacks.
In modern computing systems, there are many background processes that may cache/store information about user data or parts of the data itself in non-encrypted areas of the hard drive, like:
  • swap partitions
    • (potential remedies: disable swapping, or use encrypted swap as well)
  • /tmp (temporary files created by user applications)
    • (potential remedies: avoid such applications; mount /tmp inside a ramdisk)
  • /var (log files and databases and such; for example, mlocate stores an index of all file names in /var/lib/mlocate/mlocate.db)
In addition, mere data encryption will leave you vulnerable to offline system tampering attacks (e.g. someone installing a hidden program that records the passphrase you use to unlock the encrypted data, or waits for you to unlock it and then secretly copies/sends some of the data to a location where the attacker can retrieve it).
System encryption
Defined as the encryption of the operating system and user data, system encryption helps to address some of the inadequacies of data encryption.
Benefits:
  • prevents unauthorized physical access to (and tampering with) operating system files (but see warning above)
  • prevents unauthorized physical access to private data that may be cached by the system
Disadvantages:
  • unlocking of the encrypted parts of the disk can no longer happen during or after user login; it must now happen at boot time

In practice, there is not always a clear line between data encryption and system encryption, and many different compromises and customized setups are possible.

In any case, disk encryption should only be viewed as an adjunct to the existing security mechanisms of the operating system - focused on securing offline physical access, while relying on other parts of the system to provide things like network security and user-based access control.

See also Wikipedia:Disk encryption.

Available methods

All disk encryption methods operate in such a way that even though the disk actually holds encrypted data, the operating system and applications "see" it as the corresponding normal readable data as long as the cryptographic container (i.e. the logical part of the disk that holds the encrypted data) has been "unlocked" and mounted.

For this to happen, some "secret information" (usually in the form of a keyfile and/or passphrase) needs to be supplied by the user, from which the actual encryption key can be derived (and stored in the kernel keyring for the duration of the session).

If you are completely unfamiliar with this sort of operation, please also read the #How the encryption works section below.

The available disk encryption methods can be separated into two types by their layer of operation:

Stacked filesystem encryption

Stacked filesystem encryption solutions are implemented as a layer that stacks on top of an existing filesystem, causing all files written to an encryption-enabled folder to be encrypted on-the-fly before the underlying filesystem writes them to disk, and decrypted whenever the filesystem reads them from disk. This way, the files are stored in the host filesystem in encrypted form (meaning that their contents, and usually also their file/folder names, are replaced by random-looking data of roughly the same length), but other than that they still exist in that filesystem as they would without encryption, as normal files / symlinks / hardlinks / etc.

The way it is implemented, is that to unlock the folder storing the raw encrypted files in the host filesystem ("lower directory"), it is mounted (using a special stacked pseudo-filesystem) onto itself or optionally a different location ("upper directory"), where the same files then appear in readable form - until it is unmounted again, or the system is turned off.

Available solutions in this category are eCryptfs and EncFS.

Block device encryption

Block device encryption methods, on the other hand, operate below the filesystem layer and make sure that everything written to a certain block device (i.e. a whole disk, or a partition, or a file acting as a virtual loop-back device) is encrypted. This means that while the block device is offline, its whole content looks like a large blob of random data, with no way of determining what kind of filesystem and data it contains. Accessing the data happens, again, by mounting the protected container (in this case the block device) to an arbitrary location in a special way.

The following "block device encryption" solutions are available in Arch Linux:

loop-AES
loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption. However, loop-AES is considered less user-friendly than other options as it requires non-standard kernel support.
dm-crypt
dm-crypt is the standard device-mapper encryption functionality provided by the Linux kernel. It can be used directly by those who like to have full control over all aspects of partition and key management. The management of dm-crypt is done with the cryptsetup userspace utility. It can be used for the following types of block-device encryption: LUKS (default), plain, and has limited features for loopAES and Truecrypt devices.
  • LUKS, used by default, is an additional convenience layer which stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use and cryptographic security.
  • plain dm-crypt mode, being the original kernel functionality, does not employ the convenience layer. It is more difficult to apply the same cryptographic strength with it. When doing so, longer keys (passphrases or keyfiles) are the result. It has, however, other advantages, described in the following.
TrueCrypt
Note that the developers of TrueCrypt ended support for it in May 2014.

For practical implications of the chosen layer of operation, see the comparison table below, as well as the general write up for eCryptfs. See Category:Encryption for the available content of the methods compared below, as well as other tools not included in the table.


Comparison table

The column "dm-crypt +/- LUKS" denotes features of dm-crypt for both LUKS ("+") and plain ("-") encryption modes. If a specific feature requires using LUKS, this is indicated by "(with LUKS)". Likewise "(without LUKS)" indicates usage of LUKS is counter-productive to achieve the feature and plain mode should be used.

Summary
Loop-AES dm-crypt +/- LUKS Truecrypt eCryptfs EncFs
Type block device encryption block device encryption block device encryption stacked filesystem encryption stacked filesystem encryption
Main selling points longest-existing one; possibly the fastest; works on legacy systems de-facto standard for block device encryption on Linux; very flexible very portable, well-polished, self-contained solution slightly faster than EncFS; individual encrypted files portable between systems easiest one to use; supports non-root administration
Availability in Arch Linux must manually compile custom kernel kernel modules: already shipped with default kernel; tools: device-mapper, cryptsetup [core] truecrypt 7.1a-2 [extra] (read-only features in later versions) kernel module: already shipped with default kernel; tools: ecryptfs-utils [community] encfs [community]
License GPL GPL custom
[1]
GPL GPL
Basic classification
Loop-AES dm-crypt +/- LUKS Truecrypt eCryptfs EncFs
Encrypts whole block devices whole block devices whole block devices files files
Container for encrypted data may be... a disk or disk partition / a file acting as a virtual partition a disk or disk partition / a file acting as a virtual partition a disk or disk partition / a file acting as a virtual partition a directory in an existing file system a directory in an existing file system
Relation to filesystem operates below filesystem layer: does not care whether the content of the encrypted block device is a filesystem, a partition table, a LVM setup, or anything else operates below filesystem layer: does not care whether the content of the encrypted block device is a filesystem, a partition table, a LVM setup, or anything else operates below filesystem layer: does not care whether the content of the encrypted block device is a filesystem, a partition table, a LVM setup, or anything else adds an additional layer to an existing filesystem, to automatically encrypt/decrypt files whenever they are written/read adds an additional layer to an existing filesystem, to automatically encrypt/decrypt files whenever they are written/read
Encryption implemented in... kernelspace kernelspace kernelspace kernelspace userspace (using FUSE)
Cryptographic metadata stored in...  ? with LUKS: LUKS Header begin/end of (decrypted) device (format) header of each encrypted file control file at the top level of each EncFs container
Wrapped encryption key stored in...  ? with LUKS: LUKS header begin/end of (decrypted) device (format) key file that can be stored anywhere control file at the top level of each EncFs container
Practical implications
Loop-AES dm-crypt +/- LUKS Truecrypt eCryptfs EncFs
File metadata (number of files, dir structure, file sizes, permissions, mtimes, etc.) is encrypted
(file and dir names can be encrypted though)

(file and dir names can be encrypted though)
Can be used to encrypt whole hard drives (including partition tables)
Can be used to encrypt swap space
Can be used without pre-allocating a fixed amount of space for the encrypted data container
Can be used to protect existing filesystems without block device access, e.g. NFS or Samba shares, cloud storage, etc.
[2]
Allows offline file-based backups of encrypted files
Usability features
Loop-AES dm-crypt +/- LUKS Truecrypt eCryptfs EncFs
Support for automounting on login  ?  ?
Support for automatic unmounting in case of inactivity  ?  ?  ?  ?
Non-root users can create/destroy containers for encrypted data limited
Provides a GUI
Security features
Loop-AES dm-crypt +/- LUKS Truecrypt eCryptfs EncFs
Supported ciphers AES AES, Anubis, CAST5/6, Twofish, Serpent, Camellia, Blowfish,… (every cipher the kernel Crypto API offers) AES, Twofish, Serpent AES, Blowfish, Twofish... AES, Blowfish
Support for salting  ?
(with LUKS)
 ?
Support for cascading multiple ciphers  ? Not in one device, but blockdevices can be cascaded  ?
Support for key-slot diffusion  ?
(with LUKS)
 ?  ?  ?
Protection against key scrubbing
(without LUKS)
 ?  ?  ?
Support for multiple (independently revokable) keys for the same encrypted data  ?
(with LUKS)
 ?  ?
Performance features
Loop-AES dm-crypt +/- LUKS Truecrypt eCryptfs EncFs
Multithreading support  ?
[8]
 ?  ?
Hardware-accelerated encryption support
[13]
Block device encryption specific
Loop-AES dm-crypt +/- LUKS Truecrypt
Support for (manually) resizing the encrypted block device in-place  ?
Stacked filesystem encryption specific
eCryptfs EncFs
Supported file systems ext3, ext4, xfs (with caveats), jfs, nfs...  ?
Ability to encrypt filenames
Ability to not encrypt filenames
Optimized handling of sparse files
Compatibility & prevalence
Loop-AES dm-crypt +/- LUKS Truecrypt eCryptfs EncFs
Supported Linux kernel versions 2.0 or newer CBC-mode since 2.6.4, ESSIV 2.6.10, LRW 2.6.20, XTS 2.6.24  ?  ? 2.4 or newer
Encrypted data can also be accessed from Windows
(with [3], [14])

(with [4], [14])
 ?  ?
[9]
Encrypted data can also be accessed from Mac OS X  ?  ?  ?
[5]
Encrypted data can also be accessed from FreeBSD  ?  ?  ?
[6]
Used by  ? Debian/Ubuntu installer (system encryption)
Fedora installer
 ? Ubuntu installer (home dir encryption)
Chromium OS (encryption of cached user data [7])
 ?

Preparation

Choosing a setup

Which disk encryption setup is appropriate for you will depend on your goals (please read #Why use encryption? above) and system parameters.

Among other things, you will need to answer the following questions:

What kind of "attacker" do you want to protect against?
  • Casual computer user snooping around your disk when your system is turned off / stolen / etc.
  • Professional cryptanalyst who can get repeated read/write access to your system before and after you use it
  • Anything in between
What encryption strategy shall be employed?
  • Data encryption
  • System encryption
  • Something in between
How should swap, /tmp, etc. be taken care of?
  • Ignore, and hope no data is leaked
  • Disable or mount as ramdisk
  • Encrypt (as part of full disk encryption, or separately)
How should encrypted parts of the disk be unlocked?
  • Passphrase (same as login password, or separate)
  • Keyfile (e.g. on a USB stick, that you keep in a safe place or carry around with yourself)
  • Both
When should encrypted parts of the disk be unlocked?
  • Before boot
  • During boot
  • At login
  • Manually on demand (after login)
How should multiple users be accomodated?
  • Not at all
  • Using a shared passphrase/key
  • Independently issued and revocable passphrases/keys for the same encrypted part of the disk
  • Separate encrypted parts of the disk for different users

Then you can go on to make the required technical choices (see #Available methods above, and #How the encryption works below), regarding:

  • stacked filesystem encryption vs. blockdevice encryption
  • key management
  • cipher and mode of operation
  • metadata storage
  • location of the "lower directory" (in case of stacked filesystem encryption)

Examples

In practice, it could turn out something like:

Example 1
Simple data encryption (internal hard drive) using a virtual folder called ~/Private in the user's home directory encrypted with EncFS
└──> encrypted versions of the files stored on-disk in ~/.Private
└──> unlocked on demand with dedicated passphrase
Example 2
Simple data encryption (removable media), an USB drive encrypted with TrueCrypt
└──> unlocked when attached to the computer (using dedicated passphrase plus using a covert keyfile such as ~/photos/2006-09-04a.jpg)
Example 3
Partial system encryption with each user's home directory encrypted with ECryptfs
└──> unlocked on respective user login, using login passphrase
└──> swap and /tmp partitions encrypted with Dm-crypt with LUKS, using an automatically generated per-session throwaway key
└──> indexing/caching of contents of /home by slocate (and similar apps) disabled.
Example 4
System encryption - whole hard drive except /boot partition (however, /boot can be encrypted with GRUB) encrypted with Dm-crypt with LUKS
└──> unlocked during boot, using passphrases or USB stick with keyfiles
└──> Maybe different passphrases/keys per user - independently revocable
└──> Maybe encryption spanning multiple drives or partition layout flexibility with LUKS on LVM
Example 5
Hidden/plain system encryption - whole hard drive encrypted with plain dm-crypt
└──> USB-boot, using dedicated passphrase plus USB stick with keyfile
└──> data integrity checked before mounting
└──> /boot partition located on aforementioned USB stick

Many other combinations are of course possible. You should carefully plan what kind of setup will be appropriate for your system.

Choosing a strong passphrase

See Security#Passwords.

Preparing the disk

Before setting up disk encryption on a (part of a) disk, consider securely wiping it first. This consists of overwriting the entire drive or partition with a stream of zero bytes or random bytes, and is done for one or both of the following reasons:

Prevent recovery of previously stored data

Disk encryption does not change the fact that individual sectors are only overwritten on demand, when the file system creates or modifies the data those particular sectors hold (see #How the encryption works below). Sectors which the filesystem considers "not currently used" are not touched, and may still contain remnants of data from previous filesystems. The only way to make sure that all data which you previously stored on the drive can not be recovered, is to manually erase it. For this purpose it does not matter whether zero bytes or random bytes are used (although wiping with zero bytes will be much faster).

Prevent disclosure of usage patterns on the encrypted drive

Ideally, the whole encrypted part of the disk should be indistinguishable from uniformly random data. This way, no unauthorized person can know which and how many sectors actually contain encrypted data - which may be a desirable goal in itself (as part of true confidentiality), and also serves as an additional barrier against attackers trying to break the encryption. In order to satisfy this goal, wiping the disk using high-quality random bytes is crucial.

The second goal only makes sense in combination with block device encryption, because in the case of stacked filesystem encryption the encrypted data can easily be located anyways (in the form of distinct encrypted files in the host filesystem). Also note that even if you only intend to encrypt a particular folder, you will have to erase the whole partition if you want to get rid of files that were previously stored in that folder in unencrypted form (due to disk fragmentation). If there are other folders on the same partition, you will have to back them up and move them back afterwards.

Once you have decided which kind of disk erasure you want to perform, refer to the Securely wipe disk article for technical instructions.

Tip: In deciding which method to use for secure erasure of a hard disk drive, remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.

How the encryption works

This section is intended as a high-level introduction to the concepts and processes which are at the heart of usual disk encryption setups.

It does not go into technical or mathematical details (consult the appropriate literature for that), but should provide a system administrator with a rough understanding of how different setup choices (especially regarding key management) can affect usability and security.

Basic principle

For the purposes of disk encryption, each blockdevice (or individual file in the case of stacked filesystem encryption) is divided into sectors of equal length, for example 512 bytes (4,096 bits). The encryption/decryption then happens on a per-sector basis, so the n'th sector of the blockdevice/file on disk will store the encrypted version of the n'th sector of the original data.

Whenever the operating system or an application requests a certain fragment of data from the blockdevice/file, the whole sector (or sectors) that contains the data will be read from disk, decrypted on-the-fly, and temporarily stored in memory:

          ╔═══════╗
 sector 1 ║"???.."║
          ╠═══════╣         ╭┈┈┈┈┈╮
 sector 2 ║"???.."║         ┊ key ┊
          ╠═══════╣         ╰┈┈┬┈┈╯
          :       :            │
          ╠═══════╣            ▼             ┣┉┉┉┉┉┉┉┫
 sector n ║"???.."║━━━━━━━(decryption)━━━━━━▶┋"abc.."┋ sector n
          ╠═══════╣                          ┣┉┉┉┉┉┉┉┫
          :       :
          ╚═══════╝
 
          encrypted                          unencrypted
     blockdevice or                          data in RAM
       file on disk

Similarly, on each write operation, all sectors that are affected must be re-encrypted complelety (while the rest of the sectors remain untouched).

In order to be able to de/encrypt data, the disk encryption system needs to know the unique secret "key" associated with it. Whenever the encrypted block device or folder in question is to be mounted, its corresponding key (called henceforth its "master key") must be supplied.

The entropy of the key is of utmost importance for the security of the encryption. A randomly generated byte string of a certain length, for example 32 bytes (256 bits), has desired properties but is not feasible to remember and apply manually during the mount.

For that reason two techniques are used as aides. The first is the application of cryptography to increase the entropic property of the master key, usually involving a separate human-friendly passphrase. For the different types of encryption the #Comparison table lists respective features. The second method is to create a keyfile with high entropy and store it on a medium separate from the data drive to be encrypted.

See also Wikipedia:Authenticated encryption.

Keys, keyfiles and passphrases

The following are examples how to store and cryptographically secure a master key with a keyfile:

Stored in a plaintext keyfile

Simply storing the master key in a file (in readable form) is the simplest option. The file - called a "keyfile" - can be placed on a USB stick that you keep in a secure location and only connect to the computer when you want to mount the encrypted parts of the disk (e.g. during boot or login).

Stored in passphrase-protected form in a keyfile or on the disk itself

The master key (and thus the encrypted data) can be protected with a secret passphrase, which you will have to remember and enter each time you want to mount the encrypted block device or folder. See #Cryptographic metadata below for details.

Randomly generated on-the-fly for each session

In some cases, e.g. when encrypting swap space or a /tmp partition, it is not necessary to keep a persistent master key at all. A new throwaway key can be randomly generated for each session, without requiring any user interaction. This means that once unmounted, all files written to the partition in question can never be decrypted again by anyone - which in those particular use-cases is perfectly fine.

Cryptographic metadata

Frequently the encryption techniques use cryptographic functions to enhance the security of the master key itself. On mount of the encrypted device the passphrase or keyfile is passed through these and only the result can unlock the master key to decrypt the data.

A common setup is to apply so-called "key stretching" to the passphrase (via a "key derivation function"), and use the resulting enhanced passphrase as the mount key for decrypting the actual master key (which has been previously stored in encrypted form):

╭┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╮                         ╭┈┈┈┈┈┈┈┈┈┈┈╮
┊ mount passphrase ┊━━━━━⎛key derivation⎞━━━▶┊ mount key ┊
╰┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╯ ,───⎝   function   ⎠    ╰┈┈┈┈┈┬┈┈┈┈┈╯
╭──────╮            ╱                              │
│ salt │───────────´                               │
╰──────╯                                           │
╭─────────────────────╮                            ▼         ╭┈┈┈┈┈┈┈┈┈┈┈┈╮
│ encrypted master key│━━━━━━━━━━━━━━━━━━━━━━(decryption)━━━▶┊ master key ┊
╰─────────────────────╯                                      ╰┈┈┈┈┈┈┈┈┈┈┈┈╯

The key derivation function (e.g. PBKDF2 or scrypt) is deliberately slow (it applies many iterations of a hash function, e.g. 1000 iterations of HMAC-SHA-512), so that brute-force attacks to find the passphrase are rendered infeasible. For the normal use-case of an authorized user, it will only need to be calculated once per session, so the small slowdown is not a problem. It also takes an additional blob of data, the so-called "salt", as an argument - this is randomly generated once during set-up of the disk encryption and stored unprotected as part of the cryptographic metadata. Because it will be a different value for each setup, this makes it infeasible for attackers to speed up brute-force attacks using precomputed tables for the key derivation function.

The encrypted master key can be stored on disk together with the encrypted data. This way, the confidentiality of the encrypted data depends completely on the secret passphrase.

Additional security can be attained by instead storing the encrypted master key in a keyfile on e.g. a USB stick. This provides two-factor authentication: Accessing the encrypted data now requires something only you know (the passphrase), and additionally something only you have (the keyfile).

Another way of achieving two-factor authentication is to augment the above key retrieval scheme to mathematically "combine" the passphrase with byte data read from one or more external files (located on a USB stick or similar), before passing it to the key derivation function.The files in question can be anything, e.g. normal JPEG images, which can be beneficial for #Plausible deniability. They are still called "keyfiles" in this context, though.

After it has been derived, the master key is securely stored in memory (e.g. in a kernel keyring), for as long as the encrypted block device or folder is mounted.

It is usually not used for de/encrypting the disk data directly, though. For example, in the case of stacked filesystem encryption, each file can be automatically assigned its own encryption key. Whenever the file is to be read/modified, this file key first needs to be decrypted using the main key, before it can itself be used to de/encrypt the file contents:

                          ╭┈┈┈┈┈┈┈┈┈┈┈┈╮
                          ┊ master key ┊
  file on disk:           ╰┈┈┈┈┈┬┈┈┈┈┈┈╯
 ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐        │
 ╎╭───────────────────╮╎        ▼          ╭┈┈┈┈┈┈┈┈┈┈╮
 ╎│ encrypted file key│━━━━(decryption)━━━▶┊ file key ┊
 ╎╰───────────────────╯╎                   ╰┈┈┈┈┬┈┈┈┈┈╯
 ╎┌───────────────────┐╎                        ▼           ┌┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┐
 ╎│ encrypted file    │◀━━━━━━━━━━━━━━━━━(de/encryption)━━━▶┊ readable file ┊
 ╎│ contents          │╎                                    ┊ contents      ┊
 ╎└───────────────────┘╎                                    └┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┘
 └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘

In a similar manner, a separate key (e.g. one per folder) may be used for the encryption of file names in the case of stacked filesystem encryption.

In the case of block device encryption one master key is used per device and, hence, all data. Some methods offer features to assign multiple passphrases/keyfiles for the same device and others not. Some use above mentioned functions to secure the master key and others give the control over the key security fully to the user. Two examples are explained by the cryptographic parameters used by dm-crypt in plain or LUKS modes.

When comparing the parameters used by both modes one notes that dm-crypt plain mode has parameters relating to how to locate the keyfile (e.g. --keyfile-size, --keyfile-offset). The dm-crypt LUKS mode does not need these, because each blockdevice contains a header with the cryptographic metadata at the beginning. The header includes the used cipher, the encrypted master-key itself and parameters required for its derivation for decryption. The latter parameters in turn result from options used during initial encryption of the master-key [e.g. --iter-time, --use-random).

For the dis-/advantages of the different techniques, please refer back to #Comparison table or browse the specific pages.

See also:

Ciphers and modes of operation

The actual algorithm used for translating between pieces of unencrypted and encrypted data (so-called "plaintext" and "ciphertext") which correspond to each other with respect to a given encryption key, is called a "cipher".

Disk encryption employs "block ciphers", which operate on fixed-length blocks of data, e.g. 16 bytes (128 bits). At the time of this writing, the predominantly used ones are:

block size key size comment
AES 128 bits 128, 192 or 256 bits approved by the NSA for protecting "SECRET" and "TOP SECRET" classified US-government information (when used with a key size of 192 or 256 bits)
Blowfish 64 bits 32–448 bits one of the first patent-free secure ciphers that became publicly available, hence very well established on Linux
Twofish 128 bits 128, 192 or 256 bits developed as successor of Blowfish, but has not attained as much widespread usage
Serpent 128 bits 128, 192 or 256 bits Considered the most secure of the five AES-competition finalists[10][11][12].

Encrypting/decrypting a sector (see above) is achieved by dividing it into small blocks matching the cipher's block-size, and following a certain rule-set (a so-called "mode of operation") for how to consecutively apply the cipher to the individual blocks.

Simply applying it to each block separately without modification (dubbed the "electronic codebook (ECB)" mode) would not be secure, because if the same 16 bytes of plaintext always produce the same 16 bytes of ciphertext, an attacker could easily recognize patterns in the ciphertext that is stored on disk.

The most basic (and common) mode of operation used in practice is "cipher-block chaining (CBC)". When encrypting a sector with this mode, each block of plaintext data is combined in a mathematical way with the ciphertext of the previous block, before encrypting it using the cipher. For the first block, since it has no previous ciphertext to use, a special pre-generated data block stored with the sector's cryptographic metadata and called an "initialization vector (IV)" is used:

                                  ╭──────────────╮
                                  │initialization│
                                  │vector        │
                                  ╰────────┬─────╯
          ╭  ╠══════════╣        ╭─key     │      ┣┉┉┉┉┉┉┉┉┉┉┫        
          │  ║          ║        ▼         ▼      ┋          ┋         . START
          ┴  ║"????????"║◀━━━━(cipher)━━━━(+)━━━━━┋"Hello, W"┋ block  ╱╰────┐
    sector n ║          ║                         ┋          ┋ 1      ╲╭────┘
  of file or ║          ║──────────────────╮      ┋          ┋         ' 
 blockdevice ╟──────────╢        ╭─key     │      ┠┈┈┈┈┈┈┈┈┈┈┨
          ┬  ║          ║        ▼         ▼      ┋          ┋
          │  ║"????????"║◀━━━━(cipher)━━━━(+)━━━━━┋"orld !!!"┋ block
          │  ║          ║                         ┋          ┋ 2
          │  ║          ║──────────────────╮      ┋          ┋
          │  ╟──────────╢                  │      ┠┈┈┈┈┈┈┈┈┈┈┨
          │  ║          ║                  ▼      ┋          ┋
          :  :   ...    :        ...      ...     :   ...    : ...
 
               ciphertext                         plaintext
                  on disk                         in RAM

When decrypting, the procedure is reversed analogously.

One thing worth noting is the generation of the unique initialization vector for each sector. The simplest choice is to calculate it in a predictable fashion from a readily available value such as the sector number. However, this might allow an attacker with repeated access to the system to perform a so-called watermarking attack. To prevent that, a method called "Encrypted salt-sector initialization vector (ESSIV)" can be used to generate the initialization vectors in a way that makes them look completely random to a potential attacker.

There are also a number of other, more complicated modes of operation available for disk encryption, which already provide built-in security against such attacks (and hence do not require ESSIV). Some can also additionally guarantee authenticity of the encrypted data (i.e. confirm that it has not been modified/corrupted by someone who does not have access to the key).

See also:

Plausible deniability

See Wikipedia:Plausible deniability.

See also

  1. ^ see http://www.truecrypt.org/legal/license
  2. ^ well, a single file in those filesystems could be used as a container (virtual loop-back device!) but then one would not actually be using the filesystem (and the features it provides) anymore
  3. ^ CrossCrypt [dead link 2015-01-20] - Open Source AES and TwoFish Linux compatible on the fly encryption for Windows XP and Windows 2000
  4. ^ (1) FreeOTFE (on sf.net) (2) FreeOTFE (archived) - supports Windows 2000 and later (for PC), and Windows Mobile 2003 and later (for PDA)
  5. ^ see EncFs build instructions for Mac
  6. ^ see http://www.freshports.org/sysutils/fusefs-encfs/
  7. ^ see http://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data
  8. ^ http://kernelnewbies.org/Linux_2_6_38#head-49f5f735853f8cc7c4d89e5c266fe07316b49f4c
  9. ^ http://members.ferrara.linux.it/freddy77/encfs.html
  10. ^ http://csrc.nist.gov/archive/aes/round2/r2report.pdf
  11. ^ https://www.cl.cam.ac.uk/~rja14/Papers/serpentcase.pdf
  12. ^ https://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf
  13. ^ https://github.com/vgough/encfs/issues/118
  14. ^ DOXBOX - support to open dm-crypt / LUKS in newer Windows releases (includes fork from OTFE)