Talk:Comparison of disk encryption software

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the Comparison of disk encryption software article.
Article policies
WikiProject on Cryptography This article is part of WikiProject Cryptography, an attempt to build a comprehensive and detailed guide to cryptography on Wikipedia. If you would like to participate, you can choose to edit the article attached to this page, or visit the project page, where you can join the project and see a list of open tasks.

Contents

[edit] Plain CBC

I don't think using the term plain CBC without explanation is a good idea. Normally CBC implies the IV is random. To the best of my knowledge no storage encryption does exactly that. I think storage encryption is the only area where this reduced security variant of CBC is being used. People who knows CBC, but does not know storage encrytion, should be able to read the article and understand that the mode differs from real CBC. Kasperd 07:52, 27 December 2006 (UTC)

Thank you for your input. I added a footnote to the column. Is this what you had in mind?
""Plain CBC" means that the CBC initialization vectors are statically derived from the sector number and and not secret; that is, they are re-used when overwriting a sector and can easily be guessed by an attacker."
-- intgr 11:22, 27 December 2006 (UTC)
I think that description is good. Maybe there is a better name, but I can't come up with one right now. But as long as it is described what it means, I think it is OK. Kasperd 13:48, 27 December 2006 (UTC)

I have had a look at this table and I think that a slight restructuring of the terms would help us communicate the important information in a more clear manner. There are 3 CBC modes listed and in reality there are many distinct variants of CBC based on how it was decided to generate the initialization vector. I propose that we cut the table up with columns: CBC, insecure IV, secure IV, random keys, LRW. I'll take a stab at it, now. Elric imrryr.org 21:06, 15 January 2007 (UTC)

Sorry to reply to my own post, but I was lead to this thought because the table seems to imply that generating IVs with ESSIV is the only way to avoid watermarking attacks. In fact, to my knowledge the only open source cryptographic disk which was vulnerable to watermarking attacks was Linux's cryptoloop. Might also be an idea to adjust the note about how ESSIV was developed to avoid watermarking attacks in the disk encryption theory page. ESSIV was developed to avoid watermarking attacks in cryptoloop not generally.
-- Elric imrryr.org 21:11, 15 January 2007 (UTC)
Plain (public/predictable) IVs are inherently vulnerable to watermarking attacks. Per [1] for example.
I had indeed incorrectly classified CGD under plain CBC by misunderstanding the paper, as this approach has not been documented anywhere else that I've read. The encrypted sector number IV mode probably warrants another column.
However, I disagree with the CBC and "secure IVs" distinction in this particular table – in my view, the table ought to compare the available modes of operation in the software, and not the features of these modes. Though it was not my intention to imply that ESSIV was the only approach to defeat watermarking.
As Kasperd pointed out, while CBC typically implies that the IVs are random and never re-used, this approach is not used in any of the compared tools. Instead, disk encryption software typically implements (1) CBC with per-sector public IVs, called "plain CBC" here; (2) sector-specific hashed and salted IVs (ESSIV); (3) encrypted sector-number IVs (as in CGD); (4) CBC with per-sector random keys (as in CGDE); or other, disk encryption-specific modes (such as LRW). All of these are different modes of operation, and exhibit different properties, despite that many rely on CBC for each sector alone. Some software, such as dm-crypt, implements several modes that can be chosen by the user; the current reorganized table fails to reflect that. And the "CBC" column is now useless, as all tools (where information is available) have "yes" in that column.
As for cryptoloop, did it ever implement ESSIV? I thought it was deprecated for good, and ESSIV was implemented much later in dm-crypt.
In response to the edit comment "For corroboration of the date, why not use FreeBSD's CVS tree?" – you're welcome to cite CVS if you can link to it; I agree that its date is more likely to be accurate. -- intgr 01:08, 16 January 2007 (UTC)


Yes, I started to think that Secure IVs was not an appropriate column heading a few hours after I put that in. The problem is that there are many different ways to generate IVs rather than just two or three. So, I think that it might be worthwhile to try an encapsulate and group them for analysis, right? How about "IV prevents watermark attacks" or some such. Otherwise the table will end up become more complicated for no good reason. I don't think that in the general case until a weakness is discovered in either ESSIV or encrypted block number that there's really much noticeable difference between them in practice.
Now, granted that the CBC column has all yesses in it but it is distinct from LRW. Maybe this calls for two tables as we're conflating modes with how IVs are generated in one of the modes?
So, I'm not convinced that my edits are optimal, but hopefully we can chat for a bit and tease out a much better layout than either?
I don't think that cryptoloop ever did anything but use the sector number as an IV.
Roland Dowdeswell 02:14, 16 January 2007 (UTC)
I personally would still consider different approaches to CBC IV generation conceptually separate modes (are there any good reasons not to?).
For example, in CBDE's case, the fact that they're relying on CBC is actually irrelevant in the first place – as their "mode" (random keys that are not re-used) guarantees that watermarking attacks, as well as content leaks and data modification leaks, are impossible across sectors, and CBC guards each sector alone. Other CBC-based modes, however, tend to weaken the traditional CBC mode, since the assumption of CBC that (IV, key) pairs would never be re-used, is violated.
Maybe ESSIV and CGD-like IV generation can be grouped into the same column, as in both cases, the IV is a function of the crypto key (salt) and sector number alone, and the IV is not known to the attacker? And distinguish that from CBC with sector-specific public IVs, as well as some very different alternatives, such as plumb IV? (Plumb IV is not actually implemented in any of these AFAIK). Besides these, are there really any more IV generation methods?
So, taking this approach, the distinctions would be "CBC with public IVs", "CBC with secret sector number-specific IVs", "plumb IV", "LRW" and "random one-time per-sector keys". What do you think about this organization? -- intgr 10:13, 16 January 2007 (UTC)
That sounds great. In hindsight, I was trying to make the headings more about the security properties of the system. Perhaps, we should just add a table labeled "Security Properties" with headings like "Prevents offline dictionary attack", "Prevents online dictionary attack", "Prevents watermarking attack", etc. etc.?
Roland Dowdeswell 03:36, 17 January 2007 (UTC)
I have somehow missed your response here earlier. Yeah, that sounds like a good idea – although "preventing dictionary attacks" sounds rather impossible. :) -- intgr 04:54, 26 January 2007 (UTC)

[edit] Per sector keys

Currently I only know of GBDE using per sector keys. Calling these pseudorandom might not be accurate enough. Two different keys are used for each sector. One key is used for encrypting the actual data, this key is generated every time the sector is written. There is nothing inherent in the GBDE design requiring these keys to be pseudorandom. On hardware supporting it, they could be truly random bits, which would also be the most secure. The one time key used fot the data is then encrypted under a per sector pseudorandom key, which remains fixed for the life time of the container. Kasperd 08:08, 27 December 2006 (UTC)

Right, GBDE probably supports hardware random generators. Changed it to say "random per-sector keys". Or do you think that's not clear enough? -- intgr 11:22, 27 December 2006 (UTC)
Maybe add a footnote saying something like: "GBDE use two keys for each sector, a fixed pseudo random key and a one time key" with a reference to the paper. Kasperd 13:50, 27 December 2006 (UTC)
I added annotations for all the columns now, including this one; they're more visible now than footnotes ever were. -- intgr 16:55, 27 December 2006 (UTC)

There's also the fact that the pseudo-random keys are used in conjuction with a zero IV CBC mode that should be properly communicated by the table. Given that the per-sector keys are pseudo-random, one doesn't actually need to bother with an IV (which is why I put N/A in the column about secure IV's for GBDE.) Elric imrryr.org 21:41, 15 January 2007 (UTC)

Each sector actually have two keys. A pseudorandom key, which is fixed for the volumes lifetime, and a one time key, which changes every time the sector is written. The new key is generated using the systems random number generator. I don't know the details of the random number generator BSD uses, but I'd guess it use a combination of pseudorandomness and real randomness. If the pseudorandom number generator used to generate the fixed keys had been strong, the encryption would have been secure even with a fixed IV. Unfortunately that pseudorandom generator is a nonstandard one designed specifically for GBDE, and it has known weaknesses. Kasperd 20:28, 2 October 2007 (UTC)

[edit] Ordering

Does anyone have ideas about how to sort the table entries? When I initially wrote the article, I figured that ordering by date might be a good idea since it gives at least some visual information, and has a precedent on comparison of file systems; however, I'm not too sure about that now, as exact release dates are not very easy to find for some software and tend to be ambiguous. Ideas? -- intgr 07:17, 2 January 2007 (UTC)

I find the ordering by date to be confusing (esp. with dmcrypt not being side by side). A more similar article, Disk encryption software, is sorted alphabetically which is easier to read. -Etienne 19:47, 1 April 2007 (UTC)
I agree - that it would make more sense. I'll start work on reordering it (though it's a big list!); if anyone wants to view it in a different order, they can always use the sort buttons H8gaR 18:58, 18 July 2007 (UTC)

[edit] Custom authentication

It would be nice to add some information if the encryption setup is tied to passwords only, or if other forms can be used as well, for example smart cards. But I don't have much clue about that - except that dm-crypt/LUKS doesn't allow smart cards, while using dm-crypt plain (shell script to set up the table via dmsetup) can be easily tied to smart cards e.g. with opensc. (Comment by Andreas Jellinghaus, opensc co-developer and smart card fan :). —Preceding unsigned comment added by 212.202.71.136 (talk)

Thank you for your suggestion. The "Custom authentication" column in the features table is already supposed to reflect that.
And in fact, LUKS does support custom authentication; quoting the man page:
      luksOpen <device> <name>

             opens  the  LUKS  partition <device> and sets up a mapping
             <name> after successful verification of the  supplied  key
             material  (either  via  key  file  by  --key-file,  or via
             prompting).  <options> can be [--key-file, --readonly].
By the way, please add new comments to the bottom of talk pages; see talk page guidelines. -- intgr 22:39, 4 February 2007 (UTC)
Are keyfiles considered "Custom authentication" or does it specifially refer to some sort of API/SDK? If keyfiles meet the test, then TrueCrypt can be changed from 'no' to 'yes'. Just want some clarity before I change it... thanks. -68.196.104.31 (talk) 22:45, 6 February 2008 (UTC)
I'd say no - How could keyfiles be considered custom authentication?! Nuwewsco (talk) 23:10, 6 February 2008 (UTC)
The idea of the custom authentication column is indeed whether one can programatically pass in arbitrary bytestrings as key material, as this is as custom as it gets with symmetric crypto. Correct me if I'm wrong, but the problem with keyfiles on systems like Windows is that anything written to the file system seems to always end up on the physical disk. And as we all know, getting rid of data is complicated after that point — with journaling file systems, sector reallocaton, flash wear levelling, and storage media pelicularities.
All of this means that keyfiles are not a robust method for implementing custom auth on Windows. In contrast, Linux (and other Unix-likes) have places like /dev/shm that only exist in RAM, can be prevented from entering swap with mmap+mlock, and can be reliably wiped afterwards; and Unix-ish disk crypto frontends also support key input from stdin or a special file descriptor. -- intgr [talk] 02:15, 7 February 2008 (UTC)

[edit] Missing

loop-AES <http://loop-aes.sf.net> is missing, please whoever has the knowlegde about it please include. —Preceding unsigned comment added by 84.176.118.76 (talk)

other important crypt software that is missed in this comparision is CompuSEC (freeware)

I have added loop-AES now. -- intgr 15:43, 23 April 2007 (UTC)

[edit] Other criteria for the features table

I would like to add several new entries to the comparison table: Private Disk [2], and Private Disk Multifactor [3]


Both programs provide options that are not available elsewhere, for instance:

  • Disk Firewall, which acts as an application level filter [4]
  • Private Disk Multifactor can be used with biometric scanners (besides smart cards or tokens)


If I add these new columns to the table, then most of the other entries will have a 'no' or '?' in the respective cell of the grid. There are multiple unique features, such as "Autorun", "Autofinish", "Password quality meter" etc - so the table will not look properly.

What is the standard procedure to deal with this? Perhaps a generic "additional features" column should be added, which would contain a list of comma-separated entries?

Here is a quick list of yes/no features that are specific to programs discussed here, yet are not reflected by the current tables:

  • 64-bit platform support
  • disk size can grow (for volume based encryption tools)
  • requires administrative rights
  • presence of an anti-keylogger, or an alternative passphrase input mechanism
  • built-in file wipe mechanism
  • available encryption/hashing algorithms
  • list of certifications for the implemented algorithms (if any)
  • portability (i.e. the ability to run from a removable drive)


Gr8dude 09:19, 27 March 2007 (UTC)

Sorry for not finding the time to respond earlier. This is going to be a bit long-winded, but here goes.
I am not trying to imply that I own the article, but I initially intended it to be a comparison of technical features of different software, and ignored user interfaces (password "strength" meters, mouse-operated password entry) and non-encryption related features (autorun, included file wipe tools).
I would also dislike a checklist of ciphers and hash functions, since there are simply so many of them (see Category:Cryptographic hash functions, Category:Block ciphers), and they provide little information for the reader. Many disk encryption solutions support essentially all popular block ciphers, with a couple that are limited to just one. Hash functions are used for widely different purposes, or may not be used at all, so such a checklist comparison would be simply flawed.
The problem with these is that free (libre) operating systems generally deal with disk encryption as a part of the system, and not a separate application, and thus rely on other parts of the system for tasks such as file wiping, passphrase input, hardware architecture support, mount privileges and even cryptography routines — because they're loosely, if at all, related to disk encryption per se. Although I guess it could be said that I'm simply biased towards free software.
I am not opposed to adding certifications, but I am skeptical of its usefulness — do they merely certify that the cipher algorithms perform as designed, or do they review the system as a whole? Are certification reports made public?
Also, I find myself grinding my teeth every time another commercial entry creeps into this article, because:
  1. With the exception of BestCrypt, they simply don't reveal any important details of the implementation, e.g., whether they employ PBKDF2 for key strengthening, which modes of operation are used or supported, etc — features that are critical for their primary function: encryption. If they insist on security through obscurity then that means that it's simply not content for Wikipedia — it violates the concept of verifiability.
  2. These entries are normally added for plain and simple advertisement, and the author's agenda is making it look as good as possible, not technical accuracy.
That said, I have not yet removed any entries so far. I have, however, fixed several additions that provided misinformation (contradicting with even the official web site). However, the fact that you decided to bring it up here is a sign of good faith, I appreciate that.
My two cents. -- intgr 14:49, 27 March 2007 (UTC)


I totally agree with your points, and I understand that the current state of the tables is pretty much the best thing that can be done without ruining the whole thing. I am absolutely against the trend to turn Wikipedia into a free advertising platform, so I am not yet updating anything; still thinking about a better solution.
The certification reports are made public, but I am not sure it applies to every algorithm out there. I do know that NIST keeps an index of parties that have certified their AES implementations [5], and another page related to SHA [6]. The problem is that NIST is not the only authority, so if others were certified elsewhere, we won't know about that; also, I haven't found any resources related to cryptographic algorithms other than AES and SHA.
The importance of certification cannot be neglected, because there are many factors involved, such as the quality of the randomly generated data. Also, end-users can have more trust in the software, being sure that their files won't become corrupt because of a subtle error in the code (as a student, I have implemented various algorithms with my colleagues, and we've seen ourselves that a program that behaves sort of right in some cases, may behave sort of wrong in other ones :-) Another argument is that people from government organizations who are looking for a solution for their infrastructure are only allowed to choose certified software, so such information will be useful to them.
As far as I know, they only test the libraries that do the actual cryptographic processing (i.e. something that for a given input, will generate the specified output); testing the other, high-level functionality of a program is very unlikely, because it can misbehave due to inconsistencies in other parts of the code (such as GUI related modules, or file-system related functions).
Gr8dude 18:19, 8 April 2007 (UTC)
"I haven't found any resources related to cryptographic algorithms other than AES and SHA."
"because there are many factors involved, such as the quality of the randomly generated data."
That was part of my point — they only seem to certify the (relatively) straightforward cipher/hash algorithms, but neglect random number generation, key derivation/strengthening, block cipher modes of operation, key escrow and whatnot — all equally critical in disk encryption software.
And data corruption is a secondary concern here IMO, as hard disks fail so often that backups are necessary one way or the other. :)
On the one hand, certification does establish some minimum standards for the software, but OTOH, it appears to be just something that companies can pay money for to receive an apparent "industry recognition" label.
-- intgr 19:39, 8 April 2007 (UTC)

[edit] Modes of operation table

The "modes of operation" table has been converted from a yes/no grid to a flat list in this edit; however, I think it dramatically reduces the readability and overview of the table. The edit comment states "Made the Modes of Operation chart more scalable (if a product supports 100 modes, there needs to be 100 columns, which is impractical)."; however, I don't think that's going to happen soon. If we ever do find such a product, I would rather decide then, and not hinder readability now.

In another edit, the previous column headers are removed, pointing to the modes of operation article. While indeed we cannot explain the values in depth on this article, I'd think that a brief explanation of what the values mean is very important for reference, just like all other tables have a column key.

I would like to revert both of these edits. I note that these edits were made to accommodate the addition of the CFB mode of operation whose properties are equivalent to CBC for the purposes of disk encryption; given this, I think we can put them both under a common column, the question relevant to disk encryption is whether PGPDisk uses public or private IVs -- e.g., whether it's susceptible to watermarking attacks. Can we come up with a good column title that would describe both CBC and CFB (and preferably also other "classic" modes)? -- intgr #%@! 22:43, 19 August 2007 (UTC)

[edit] EncFS

I just switched to EncFS from loobback, has the great advantage of not having to preallocate space for encrypted partition. http://arg0.net/wiki/encfs —Preceding unsigned comment added by Savuporo (talk • contribs) 07:44, 10 September 2007 (UTC)

[edit] TrueCrypt

FYI--TrueCrypt now apparently supports encryption of the hibernation file. http://www.truecrypt.org/docs/?s=version-history 134.253.26.11 (talk) 13:15, 6 May 2008 (UTC)

The table says TrueCrypt supports "CBC w/ secret IVs". But the IVs used by TrueCrypt are not really secret. They are computed by XORing a single secret value with the sector number. That means the difference between two IVs is known to an adversary. That will give you all the weaknesses of public IVs. So TrueCrypt is better described as having "CBC w/ public IVs". (I don't know if the same applies to any of the other encryptions listed as having secret IVs). Kasperd 20:35, 2 October 2007 (UTC)

Thanks, I'll change this. The heading "public IVs" is going to be misleading then, though; any suggestions for a better one?
Per the comment by Ronald Dowdeswell above, though, this is not a problem with CGD at least, so there have been some who got this right. -- intgr [talk] 23:13, 11 January 2008 (UTC)
I changed the column header to "predictable IVs" now; this should be clearer. -- intgr [talk] 23:17, 11 January 2008 (UTC)

[edit] RAID/OS support

Is it possible to add information about supported OS and Hardware-RAID? 12:12, 12 October 2007 (UTC)

[edit] AlertBoot Full Disk Encryption

I've just changed the "layering" section entries for "AlertBoot Full Disk Encryption" to reflect that it's not clear what it does.

From their WWW site, it's not actually possible to determine conclusively what this program offers technically. From it's name and description, it seems like a pretty fair bet it's a full disk encryption system - but as for file and partition encryption? Not certain. It suggests it may offer a file based system via operation as SAN, but it's not clear how.

Please note: This product hasn't been launched yet! I'd suggest leaving the change I've put in place in place until it's released (apparently planned for sometime in Feb 2008). Better still, remove AlertBoot from the comparison completely; there's no reason to suggest it's in any way notable. Hell - they haven't even finished it yet! IMHO, its entry here just looks like spam Nuwewsco (talk) 22:17, 3 January 2008 (UTC)

Right. I second your suggestion to simply remove it and will do so, as no reliable information can be found on this product (let alone independent or neutral). -- intgr [talk] 23:08, 11 January 2008 (UTC)

[edit] Development status

Whats the diff beteween "activly developed" and "maintained"? XFireRaidX (talk) 02:31, 12 January 2008 (UTC)

Actively developed means that new features are being added; maintained means that bugs would be fixed, but otherwise no development is going on.
Thanks for pointing this out, though, because it looks like it's time to retire this column anyway. Back when I started this page, it mainly listed well-known open source projects whose development status was pretty obvious from mailing list activity/etc; but now it's mostly commercial products whose actual status is anyone's best guess — and certainly not verifiable. -- intgr [talk] 23:03, 14 January 2008 (UTC)

[edit] Portability

None of these columns compare the portability of this software. This is one of the most important functions for a traveler. I know TrueCrypt is portable so long as you have admin rights on the windows host computer, its also portable under linux if the kernel is correctly installed. I have no idea on others. —Preceding unsigned comment added by Porco-esphino (talk • contribs) 05:44, 4 March 2008 (UTC)

[edit] Whole disk encryption

How does one boot a system that allegedly does whole disk encryption - off an external USB device? Or is this a false claim by various products? Socrates2008 (Talk) 11:48, 14 March 2008 (UTC)

[edit] Encryption of the hibernation file

Some vendors are listed as supporting this feature. I seriously doubt however that Microsoft ever shared the internals of the boot process with any third parties to allow a machine running their encryption softwareto be resumed from hibernation when the hibneration file is encryted. In the best case scenario, the hibernation file is encrypted when going into standby, but the machine cannot resume from it. Please provide a reference if you think I'm wrong, or if this feature is supported under a non-Microsoft OS. Thanks Socrates2008 (Talk) 12:00, 6 April 2008 (UTC)

Statement from TrueCrypt: "Remark: As Microsoft does not provide any API for handling hibernation, all non-Microsoft developers of disk encryption software are forced to modify undocumented components of Windows in order to allow users to encrypt hibernation files. Therefore, no disk encryption software (except for Microsoft's BitLocker) can guarantee that hibernation files will always be encrypted. At anytime, Microsoft can arbitrarily modify components of Windows (using the auto-update feature of Windows) that are not publicly documented or accessible via a public API. Any such change, or the use of an untypical or custom storage device driver, may cause any non-Microsoft disk encryption software to fail to encrypt the hibernation file. We plan to file a complaint with Microsoft (and if rejected, with the European Commission) about this issue, also due to the fact that Microsoft's disk encryption software, BitLocker, is not disadvantaged by this.
[Update 2008-04-02: Although we have not filed any complaint with Microsoft yet, we were contacted (on March 27) by Scott Field, a lead Architect in the Windows Client Operating System Division at Microsoft, who stated that he would like to investigate our requirements and look at possible solutions. We responded on March 31 providing details of the issues and suggested solutions.]" Morphh (talk) 13:00, 09 April 2008 (UTC)

[edit] PGP Disk vs PGP Whole Disk Encryption

This article seems to confuse the two products. Also the OS support is out of date, but difficult to update as PGPDisk is bundled as part of other packages and is not a separate product. Socrates2008 (Talk) 01:44, 24 April 2008 (UTC)

[edit] Definition of "whole disk encryption"

The comparison in the layering section is very misleading, as it's comparing software that protects physical disks, logical volumes (partitions) as well as software that creates new file-backed encrypted virtual volumes. Socrates2008 (Talk) 01:44, 24 April 2008 (UTC)