Talk:Comparison of disk encryption software

Missing the most important disk encryption tools!

Despite its considerable length, this article appears to be missing the most widely used contemporary disk encryption tools, including iOS device encryption, iCloud Keychain, and the Android built-in device encryption before and after changes in Android 5.0. Will try to downgrade quality from B to C until these are covered. -- pde (talk) 18:55, 10 April 2015 (UTC)

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)

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)

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)

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)

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) http://en.wikipedia.org/w/index.php?title=Talk:Comparison_of_disk_encryption_software&action=edit&section=5

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

Check Point products are missing: http://www.checkpoint.com/products/datasecurity/pc/index.html http://www.checkpoint.com/products/datasecurity/protector/index.html (80.221.7.180 (talk) 00:51, 15 July 2008 (UTC))

I worked on one of the first mainstream commercail ones (or so I thought): Norton Disklock. Not apply? — Preceding unsigned comment added by 99.14.204.242 (talk) 02:12, 21 July 2011 (UTC)

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:

• 4kb alignment for newer disks —Preceding unsigned comment added by 24.16.202.240 (talk) 02:32, 23 November 2010 (UTC)
• 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)

I believe that some sort of category like "Manageability" and/or "Recovery" should be taken into account as they are important factors in corporate environments. --194.107.24.57 (talk) 09:20, 29 March 2010 (UTC)

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)

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)

Please add http://www.arg0.net/encfs to the table. It works well and has an PAM module as well.--188.118.242.227 (talk) 01:55, 21 March 2014 (UTC)

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)

DragonFlyBSD now has a fully bsd-licensed Truecrypt implementation: http://leaf.dragonflybsd.org/mailarchive/kernel/2011-07/msg00028.html Can you update thst in the tables? — Preceding unsigned comment added by 130.243.230.189 (talk) 14:37, 15 August 2011 (UTC)

I can't find any information about that TrueCrypt's license version 3.0 is considered open source or free software, as it's not listed on http://opensource.org/licenses/alphabetical nor http://www.gnu.org/licenses/license-list.html#SoftwareLicenses. It is listed under BAD licenses on Fedoras site, https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Bad_Licenses, and listed as proprietary on it's Wikipedia page, http://en.wikipedia.org/wiki/TrueCrypt. Shouldn't TrueCrypt be marked proprietary? -- Exry 00:28, 26 November 2012

RAID/OS support

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

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)

Alertboot is an ASP offering of the SafeBoot Device Encryption platform. SafeBoot (talk) 16:34, 7 August 2008 (UTC)

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)

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)

f-OTFE has a Windows-CE PDA edition...I think Android phones can now use ext2/3/4, so anything labeled in this article as "works on Linux" and "works on any FS (filesystem) that is installed in the Operating System" SHOULD work with those smartphones... That last sentence illustrates a potential problem, but let's think this thru logically: with so many tablet/smartphone/PDA operating systems, how do you accurately list what encryption program works with what...iPad, Symbian, Blackberry, too!? Most ppl use the standard FAT32 on sd-cards, and nearly all portables use sd-cards (except laptop/netbooks, which typ use one of the Op Systems already listed), so just finding what encryption software works with FAT32 could simplify this & negate that problem...except that the world will be moving toward exFat, not FAT32, for the next 5 years. ;-) Since MS owns exFAT, any program listed in this article as "works with Windows" and "works with any filesystem that the OS supports" should support your FAT32 & exFAT SD cards...so not much info is missing from this article, i.e. only the few encryptors that don't work w/Windoze AND don't work with "all filesystems that the OS supports" will MAYBE not be able to encrypt your USB-drive. "The encrypted partition can then be accessed on any computer running the correct operating system, although it may require the user to have administrative rights on the host computer to access data. Some vendors have produced USB flash drives which use hardware based encryption as part of the design, thus removing the need for third-party encryption software."

~from USB_flash_drive#Encryption

24.155.105.79 (talk) 08:42, 3 January 2011 (UTC)

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)

Whole Disk, or Full Disk products usually interleave a micro OS somewhere on the user disk which becomes the boot environment – after successfully authenticating this then boots the real OS, decrypting the drive on the fly as needed. Some products (such as Bitlocker) require repartitioning of the drive to support the boot OS, others (like SafeBoot) interleave the pre-boot environment on the user disk without requiring any modifications. SafeBoot (talk) 15:34, 12 August 2008 (UTC)

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)

Actually there is official support for encryption of the Hibernation file under Vista, and there are some official docs available under NDA (but actually technically incorrect). Though complex, it's possible to hook the hibernation stack under XP quite successfully, and in an absolutly guarenteed way which is resistant to any predicted Microsoft changes. SafeBoot (talk) 16:38, 7 August 2008 (UTC)

Stating that it is so without providing a (public) reference does not meet Wikipedia's requirements for veriability. I venture too that if, as it appears, you are a representative of SafeBoot that you may have a conflict of interest in editing this article, so suggest that you refrain from doing so. Socrates2008 (Talk) 00:05, 10 August 2008 (UTC)

SafeBoot (talk) 15:11, 12 August 2008 (UTC) I appreciate that I am not impartial here, which is why I have kept my edits to fact only rather than promotion. I will as you suggest though add a reference to Hibernation support in the SafeBoot product (forgive me if I do it wrong). Re the official docs, Microsoft hold the keys to those and I cannot provide any evidence unfortunately. You should be comforted though to know that the leading commercial product vendors (McAfee, Checkpoint, Symantec) all provide protection during hibernation.

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)

Also the PGP suite of software seem to have become somewhat changed since Symantec bought them, anyone could bring some clarity to that? CarlJohanSveningsson (talk) 12:44, 15 August 2011 (UTC)

I think PGP Disk was part of PGP Desktop which was renamed "Symantec Encryption Desktop", but seems to have been already discontinued in the meantime - in any case one does not seem to be able to buy it anymore. Instead, there is only "Symantec Endpoint Encryption", which seems to be full disk encryption only unlike PGP Disk / Symantec Encryption Desktop which mounts an encrypted file as virtual volume. Kellerpm (talk) 10:55, 13 February 2015 (UTC)

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)

Yes, that's the point of the section; many products offer several of these options. Why is it misleading? -- intgr [talk] 18:10, 19 September 2008 (UTC)

Conflict of interest

Vendors of the software mentioned this article are encourage to note conflict of interest as well as suggestions for COI compliance. Socrates2008 (Talk) 21:54, 18 September 2008 (UTC)

Whatsis?

"Swap space: Whether the swap space (called a "pagefile" on Windows) can be encrypted individually/explicitly." What does this mean in English? Does it mean "Is the swap space encrypted?". If so, then it should be yes for freeCompusec. 75.91.99.108 (talk) 03:03, 15 February 2009 (UTC)

DataArmor / MobileArmor

Mobile Armor has a product called Data Armor that should be included perhaps?

--Risacher (talk) 20:52, 6 April 2009 (UTC)

Hardware tokens

I've done some work with evaluating encryption software, and it's very very frustrating how difficult it is to find out if tokens are actually supported. As for level of security, PKCS#11 would seem to be the only relevant standard, and then proper keys, not objects like those Truecrypt supports.

Truecrypt has for a long time now obfuscated that they do not in fact (correct me if I'm wrong) support non-stealable keys over PKCS#11, but still use those "keyfiles". At least partially defeating the main purpose of a token. I'd appreciate if someone with insight, possibly together with me, could help fix the matter at least in this table, to the very least with a footnote regarding Truecrypt token support.

Oh and PS, if someone could direct me to a simple and good software to do my file/archive encryption (not full disk) using PKCS#11 tokens, I'd be most grateful! :-D CarlJohanSveningsson (talk) 12:51, 15 August 2011 (UTC)

Doxbox says it supports PKCS#11 but dont know if it supports it fully L33tgirl (talk) 18:21, 15 February 2015 (UTC)

Symantec Endpoint Encryption for Mac

There's no evidence I can find that this product exists, though the table lists it. Symantec's client compatibility page makes no mention of any OS X compatibility: http://www.symantec.com/products/sysreq.jsp?pcid=pcat_info_risk_comp&pvid=endpt_encryption_1 As such, I'm changing this to a "No". Edrarsoric (talk) 03:07, 15 March 2012 (UTC)

It looks as Symantec have bought-out PGP.com, as PGP.com now redirects to Symantec. I'm going to go out on a limb and say that Symantec retired Endpoint Encryption for Mac and replaced it with PGP Whole Disk Encryption, as that _is_ Mac-compatible (though only to 10.6 ATM, according to the site). As such I've gone ahead and changed "PGP Whole Disk Encryption" to "PGP Whole Disk Encryption (Symantec)". Edrarsoric (talk) 03:10, 15 March 2012 (UTC)

Footnotes not linking correctly

In the article clicking footnote 71 correctly goes to footnote 71. Clicking 74 incorrectly goes to 72.

And uses of footnotes 72 and 73 cannot be found in the article but do exist as footnotes. Ftgoodoa (talk) 19:58, 3 May 2012 (UTC)

Many other footnotes seem to be incorrectly linked. There are 131 footnotes, but references to footnotes through 135. Specifically, it looks like references to 133, 134, and 135 should be to 129, 130, 131. Also, references to 123, 124, and 125 should be to 119, 120, and 121 respectively. 207.170.210.34 (talk) 20:56, 6 January 2015 (UTC) xrc 6 Jan 2015

Add RealCrypt

RedHat has RealCrypt. Search the web for it. — Preceding unsigned comment added by 89.235.246.98 (talk) 15:18, 4 November 2012 (UTC)

Whole disk including the partition tables

'Yes' to what does not encrypt partition table. --211.127.228.179 (talk) 13:52, 1 June 2014 (UTC)

Add VeraCrypt

Designed to look identical to Truecrypt. — Preceding unsigned comment added by Gary84 (talk • contribs) 16:51, 26 July 2014 (UTC)

DoxBox

Can someone please update this article to add a reference to DoxBox (https://t-d-k.github.io/doxbox/ ) which is a relaunch of FreeOTFE. I am the maintainer of DoxBox. — Preceding unsigned comment added by Squte (talk • contribs) 00:01, 31 August 2014 (UTC)

FREEOTFE hardware acceleration

I am changing the entry for freeotfe to say it supports hardere acceleration, the freeotfe manual says it uses libtomcrypt 1.17 and libtomcrypt says it uses hardware acceleration http://www.libtom.org/?page=changes — Preceding unsigned comment added by L33tgirl (talk • contribs) 15:14, 20 September 2014 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Comparison of disk encryption software. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20050302202315/http://www.infoworld.com:80/cgi-bin/displayArchive.pl?/99/25/c05-25.48.htm to http://www.infoworld.com/cgi-bin/displayArchive.pl?/99/25/c05-25.48.htm

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 20:37, 18 January 2016 (UTC)

TCnext - Please add and vet

Since the fall of TrueCrypt, a project called TCnext was quick to claim themselves as a TrueCrypt alternative. Their website is truecrypt.ch. I visited this page to learn more but I see they are not mentioned. 67.0.34.219 (talk) 23:06, 10 August 2016 (UTC)

From their site: We offer the product as is, and do not claim any rights to the name TrueCrypt or TrueCrypt.org – this is not a fork but the distribution of the product under Section II of the TrueCrypt license.

So why should they be added? 2A03:8600:1001:4013:0:0:0:100A (talk) 17:15, 8 January 2017 (UTC)

DiskCryptor is no longer maintained

DiskCryptor was last updated about 3 and a half years ago and their forum has gone dead silent. No response from anyone behind the project at all. Maybe it's time to change "Maintained: Yes" to "Maintained: No"? 2A03:8600:1001:4013:0:0:0:100A (talk) 17:14, 8 January 2017 (UTC)