| Name | Last update |
| CFS
by Matt Blaze |
code dates back to 1989, the crypto to 1992. 1.4.1 was released before June 2001 |
| SFS
(1st implementation of the ideas of Anderson, Needham and Shamir, done by Carl van Schaik and Paul Smeddle: vs3fs) updated by Peter Schneider-Kamp |
August 1999 |
| StegFS
by Andrew McDonald and Markus Kuhn |
1.1.4: February 2001 |
| CryptFS by Erez Zadok, Ion Badulescu, and Alex Shender |
paper from 1998 |
| ZIA by Mark Corner and Brian Noble |
paper from September 2002 |
| Ncryptfs by Charles P. Wright, Michael C. Martino, and Erez Zadok |
paper from June 2003 |
| VNcrypt by Andrey Sverdlichenko |
1.1: February 2003 |
| PPDD by Allan Latham, maintained by Sakari Ailus |
2.0: February 2002 |
| Cryptoloop (former Crypto API) |
Cryptoloop was replaced by dm-crypt in 2.6.3-mm1 (February 2004) |
| Rubberhose by Julian Assange, Ralf P. Weinmann and Suelette Dreyfus |
alpha 0.8.3: sometime in 2000 or 2001 (never made it to Beta) |
| Phonebook by ? |
alpha build 011: January 2004 |
| Block-based encryption | Cryptographic File Systems | |
| Advantages | +encrypts an entire
partition +protects metadata |
+no preallocation needed:
can grow to any size without reformatting +backups on a file-by-file basis +layering of trust: allows to store encrypted files on file systems one wouldn't trust otherwise +ease of administrative burden, especially when used on many boxes +per-user keying |
| Disadvantages | (-more administrative work when employed on many machines, e.g. in a company intranet) | -Metadata visible: number
of encrypted files, file permissions, size of files, approximate size
of file name, sometimes even the
plaintext file name, file modification dates etc. |
| Name | Type |
| EncFS by Valient Gough | userspace encrypted file system |
| CryptoFS by Christoph Hohmann | userspace encrypted file system |
| eCryptfs by Michael Halcrow, Michael Thompson and Phillipp Hellewell | stacked cryptographic file system |
| TCFS (9 years old but has recently seen some work) |
network-based file system |
| Parameter | Recommendation | Wikipedia et al. |
| block cipher | Serpent, AES | Cipher Block cipher Block size AES Serpent AES process CRYPTREC NESSIE |
| (symmetric) key size | at least 128 bit | Key
size Computational capacity of the universe by Seth Lloyd |
| cryptographic hash function | SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512), Whirlpool | Hash
function Cryptographic hash function SHA family Whirlpool |
| key generation | password-based key derivation according to PKCS#5 PBKDF2 |
Password-based
cryptography Key derivation function Key strengthening Key (cryptography) Weak key Key management PBKDF2 PKCS Passphrase Password cracking |
| 2-factor authentication | storing the (encrypted) Master Key on an external medium that is unavailable to an attacker can significantly enhance security |
2-factor
authentication Multifactor authentication |
| block cipher mode | also see table below. recommended: LRW. CMC and EME are secure but heavy in performance. not recommended: ECB, CBC-plain IV, CBC-plumb IV Most crypto systems don't support LRW. CBC-ESS-IV or CBC with an encrypted IV are the best one can do. If an attacker has repeated physical access to the hard disk there might be a problem with CBC-ESS-IV/enc-IV. |
Block
cipher modes of operation Disk encryption Initialization Vector Linux hard disk encryption settings by Clemens Fruhwirth LinuxCryptoFS LRW draft proposal |
| Modes | Content Leaks | Watermarking | Malleability | Movability | Replay-Block | Replay-Sector |
| CBC public/plain IV | Yes | Yes | Yes | Yes | Yes | Yes |
| CBC ESSIV/enc IV | Yes | No | Yes | Yes | Yes | Yes |
| CBC plumb IV | Yes | No (?) | Yes | Yes | Yes | Yes |
| LRW (public IV) | No | No | No | No | Yes | Yes |
| CMC (public IV) | No | No | No | No | No | Yes |
| EME (public IV) | No | No | No | No | No | Yes |
| Name | OS | Block ciphers and key sizes |
Cryptographic hash functions | Block cipher mode - IV generation mode |
Key generation |
2-factor authentication |
| dm-crypt
+ dmsetup/ cryptsetup by Christophe Saout |
Linux | AES 256 | RIPEMD-160 SHA-256 SHA-384 SHA-512 |
ECB CBC-plain; CBC-ESSIV since Linux kernel 2.6.10 |
unsalted and uniterated
key generation |
? |
| dm-crypt + LUKS by Clemens Fruhwirth |
Linux | AES Twofish Serpent CAST5 CAST6 |
SHA-1 SHA-256 SHA-512 RIPEMD-160 |
ECB CBC-plain CBC-ESSIV |
PKCS#5 PBKDF2 | Yes (?) |
| Truecrypt by Truecrypt Foundation |
Linux, Windows |
AES Blowfish CAST5 Serpent 3DES Twofish (and cascades) |
SHA-1 RIPEMD-160 Whirlpool |
LRW (CBC only legacy support) |
PKCS#5 PBKDF2 | Yes |
| Loop-AES
by Jari Ruusu |
Linux | AES 128 -> AES 192 -> AES 256 -> |
SHA-256 SHA-384 SHA-512 |
CBC-plain CBC-ESSIV: single-key mode: simple sector IV multi-key-v2: MD5 IV multi-key-v3: like v2 but with extra 65th key for additional input to MD5 IV generation |
PKCS#5 PBKDF2 | Yes |
| CGD
by Roland C. Dowdeswell, John Ioannidis |
NetBSD | AES 128/196/256 Blowfish 128 3DES 192 |
SHA-1 ? |
CBC-enc (block number encrypted under same key as data) |
PKCS#5 PBKDF2, gssapi keyserver, randomkey, storedkey |
Yes (storedkey -> parameters file) |
| geli by Pawel Jakub Dawidek |
FreeBSD | AES 128 Blowfish 128 3DES 192 (key length changeable) |
SHA-1 SHA-512 |
CBC-ESSIV | PKCS#5 PBKDF2, random one-time key |
No? (but backup of Master Key possible) |
| svnd by OpenBSD team |
OpenBSD | Blowfish | ? | ? | unsalted and uniterated
key generation |
? |
| GBDE
(FreeBSD) by Poul-Henning Kamp Unlike most crypto systems which use one single key in conjunction with various block cipher/IV generation modes to encrypt all sectors of a partition (except Loop-AES multi-key-v2/v3), GBDE encrypts all sector data with one-time-use pseudorandom keys. The developer of GBDE, Poul-Henning Kamp, argues: "Protecting a modern disk, typically having a few hundred millions of sectors, with the same single 128 or 256 bits of key material offers an incredibly large amount of data for statistical, differential or probabilistic attacks in the future." Details on the cryptographic design can be found in man pages and the technical paper: http://www.freebsd.org/cgi/man.cgi?query=gbde&sektion=4 http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf The major drawback of this approach is its complexity and inherent difficulty to evaluate its cryptographic strength. Poul-Henning Kamp claims that renowed crypto experts (Lucky Green, David Wagner) reviewed GBDE and agreed that the "cryptographic design is sound and very strong". There has been a vivid discussion on the freebsd-hackers mailinglist: http://lists.freebsd.org/pipermail/freebsd-hackers/2005-March/010584.html In an interview, Roland Dowdeswell (cgd developer) claims that "GBDE is vulnerable to online dictionary attacks if its 2-factor authentication mechanisms are not used or if the second factor is somehow obtained." In the same interview he adds: "Another issue with GBDE is that it violates the atomicity assumptions that filesystems have about disks. When you write a sector to the disk, GBDE actually performs two distinct writes, in between which the disk is in an unrecoverable, indeterminate state. If the power goes out between these two operations, then the sector will be lost and you cannot recover it--at least not without cracking AES. GBDE is not resilient to either power outages or OS crashes of any variety." |
| Name | OS | Multi-key | Encrypted root |
Encrypted swap |
Change password w/o reencryption |
Emergency destruction |
Multi- user |
Crypto hardware support |
| dm-crypt + LUKS |
Linux | No | Yes | Yes | Yes | Yes (8x) |
||
| Truecrypt |
Linux, Windows |
No | No, but home-directory through plugin |
Yes (plugin) |
Yes | |||
| Loop-AES | Linux | single-key mode: one AES
key multi-key-v2: 64 different AES keys; 1st key used for 1st sector, 2nd key for 2nd sector ... multi-key-v3: like v2 but with extra 65th key for additional input to MD5 IV generation |
Yes | Yes | ||||
| CGD | NetBSD | No | No | Yes | Yes | Yes | ||
| geli |
FreeBSD | No | Yes | Yes | Yes (kill command) | Yes (2x) | Yes, crypto(9) framework |