Talk:Comparison of disk encryption software

From Wikipedia, the free encyclopedia

Contents 1 Plain CBC 2 Per sector keys 3 Ordering 4 Custom authentication 5 Missing 6 Other criteria for the features table

[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)

[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)

[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 :). —The preceding unsigned comment was 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)

[edit] Missing

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

[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)