Talk:Disk encryption/Archive 1

Archive 1

Origin

This article was copied verbatim from [1], but it looks like it was done so by the author of that source. It should be merged into disk encryption. --Haakon 16:19, 20 September 2006 (UTC)

Saqib wrote the content for both sources. Disc encryption is a broader technology then Full Disc Encryption. And the disctinction should be made that is why I created this entry. Too many people have misconceptions about File/Folder Encryption and Full Disc Encryption. Hopefully this entry will evolve to clear up these misconceptions. I look fwd to people adding more content to make the distinction clear and pros and cons of each. Saqib 17:57, 20 September 2006 (UTC)

I'm currently collecting ideas for Wikipedia talk:WikiProject Cryptography#Disk encryption reorganization, so that when someone (possibly me) finds the time to clean up what I perceive as a mess, there would already be a solid plan.

I don't think the distinction is very clear at the moment. Your post currently contrasts full disk encryption to filesystem-level encryption. However, how would you classify block device (e.g., "partition") encryption solutions, or solutions that store their encrypted block device on a file system? (I'll refer to these as "block device-level".) While there's indeed a huge ideological difference between filesystem-level and disk-level encryption, I don't think there is a big enough difference between "block device-level" and full disk encryption to warrant separate articles, since it's essentially just a matter of whether the implementation is capable of initializing the disk before launching the operating system. All the approaches used in encrypting the disk in such software solutions are also the same. I can see the need to differentiate between hardware disk encryption and software disk encryption, but not whether it's capable of initializing on boot.

One could even argue that "disk" can be thought of in the abstract sense, meaning anything that can be represented as a block device. With more flexible operating systems (using Linux as an example), it's merely a matter of how the system is configured. Any adequate block device-level encryption solution can also be launched and initialized from the initrd, and subsequently mounted as the root file system. Or if one wishes, they could also encrypt the entire hard disk, including the partition tables, this way. Similarly, one can create a file on an existing file system, set up a loopback block device backed by that file, and use a block device-level encryption solution on it.

My current idea is to have FDE, disk encryption, and OTFE in one "block device-level encryption" article that would document all the variations, and the subtle differences between them. The modes of operation currently on the disk encryption article, I would want to move to a separate one. And then there would be a third article, contrasting block device-level encryption to filesystem-level encryption (and of course a separate article on filesystem-level encryption). Note that I haven't yet figured what the articles should be named. Any ideas and opinions are welcome. -- intgr 22:58, 2 December 2006 (UTC)

Yup I am the author of both source

Saqib 17:57, 20 September 2006 (UTC)

:-)

Removal of keys is not secure data destruction?

Recently, the following paragraph was deleted from the list of benefits:

Data destruction, and disk repurposing is easier. Data destruction merely requires removal of the encryption key, and the all the information stored on the disk is rendered useless. Thus saving money in physical disk destruction or file wiping software.

with the edit message: "Secure data destruction does not merely require removal of the encryption key, since we can't be sure the attacker does not have or will not recover the key. Secure erasure is required." This claim sounds rather awkward to me. Using disk encryption with the knowledge that an attacker can/might be able to recover the key pretty much defeats the purpose of it in the first place.

Obviously if you have suspicions that the key has been leaked, you would wipe the disk. But in the general case, destroying encryption keys is good enough. People who have had access to the key will also have had access to the encrypted data - wiping the disk won't assure you that the user hasn't kept copies of the data. Is this basis for claiming that disk wiping is useless, too?

I'm not the only person who seems to consider it a secure method of data destruction [2] [3] -- intgr 22:15, 28 September 2006 (UTC)

I'm putting it back until someone objects here. -- intgr 07:42, 29 September 2006 (UTC)

US NIST objects, and rightfully. Let's suppose that your disk is encrypted with AES so you assume that the data can't be recovered and you dispose of it without secure erasure. An attacker gets your disk and keeps it. A few months pass and AES is broken (a shortcut attack is discovered). AES becomes insecure. Now the attacker gets back to your disk and decrypts it. If you had securely erased the disk, the attacker would have recovered nothing. The bottom line, encryption is not erasure. Maxt 09:17, 29 September 2006 (UTC)

I totally understand what you mean, but this is just one POV of the issue, not fact – and should be handled as such. While some people advocate not using disk encryption for data disposal, a significant number of others are in favor of it. Please see WP:POV and WP:NPOV.

As a counterpoint from my own POV, I would argue that as there are no feasible cryptanalytic attacks against any currently used block ciphers so far (currently known attacks typically require petabytes, if not much more, of known plaintext/ciphertext pairs), it's unrealistic to believe that one would be found in the future. Furthermore, given that the disk encryption suite correctly utilizes a secure block cipher mode of operation, the attacker wouldn't even know where to locate the ciphertexts they know the plaintexts for. -- intgr 10:48, 29 September 2006 (UTC)

Also note that the paper you just cited has already removed their claim about disk encryption being inappropriate. Quoting their errata section:

Deleted “Encryption is not a generally accepted means of sanitization. The increasing power of computers decreases the time needed to crack cipher text and therefore the inability to recover the encrypted data can not be assured.” [emphasis added]

-- intgr 10:59, 29 September 2006 (UTC)

I'm proposing re-adding it as:

1. Fast data destruction (data remanence), and disk repurposing, as merely destroying all the keys will render the stored information useless. However, since the underlying encryption scheme might be broken in the future, concerns have been raised about the security of this method.

Do you think this formulation is NPOV enough? -- intgr 14:21, 29 September 2006 (UTC)

Look at what you wrote: "data destruction". But note that you are actually not destructing the data. You are merely making access to it more difficult (which is the sole purpose of encryption, and not the one of media sanitization). Keep in mind that you can never be 100% sure that the encryption itself is secure (for a myriad of reasons). That's the point. Maxt 15:42, 30 September 2006 (UTC)

Yes, you are not destroying the data per se, you are destroying the possibility to access the data that's there, which is equivalent in my mind. Might as well use the official term, "media sanitization", but I figured "data destruction" would sound more familiar/obvious to a casual reader. I'm very well aware of the fact that cryptographic algorithms can have weaknesses, but as per my explanation above, I find it it very unlikekly that these weaknesses will be feasible to exploit in the real world. But enough about opinions.

Your response sounds like you never really bothered reading WP:POV. As many credible professionals/cryptographers do think encryption is good enough given correct implementations, the article should reflect their points of view. If you're able to find credible sources claiming otherwise, it should reflect both points of view (see WP:VERIFY). But removing information from Wikipedia just because you disagree with it is not permitted. -- intgr 17:11, 30 September 2006 (UTC)

> But removing information from Wikipedia just because you disagree with it is not permitted.

It was removed not because I just disagree with it. It was removed for being obviously factually incorrect. Simple logic will tell you that encryption is not data destruction (let alone secure data destruction). [Just because there are still people who believe that Earth is flat doesn't mean that a "Earth is flat" statement should not be removed from Wikipedia.] Maxt 16:11, 9 October 2006 (UTC)

Please, for once, read the Wikipedia policies I am pointing out here. For example, you will want to read what actually constitutes a fact on Wikipedia. Your "logic" is original research and thus unacceptable, unless you back it up with some real, verifiable research. While your analogy is obviously an attempt at demagogy – yes, it can be stated on Wikipedia that Earth is flat from some people's points of view. -- intgr 18:34, 9 October 2006 (UTC)

Wiping the encryption key is not deletion from a information theoretical perspective. But from a practical perspective the data are gone. Any storage encryption, which is not secure for this purpose, is not secure for any purpose. I mean the encryption is supposed to protect the data even if you had no chance to wipe anything, the scenario where the key has been wiped is at least as secure and usually much more secure. Kasperd 03:31, 10 October 2006 (UTC)

Basically agree with Kasperd on this. Intgr has taken an overly stringent view of no original research, in my view. I can, fairly, deduce that two satellites in the same orbit have the same period, or that the last known passenger pigeon having died, the species is extinct. Neither in those cases nor this, it is not prohibited original reserach to note that a key might be discovered (eg, stolen, purchased, ..), or an algorithm thought effectively unbreakable be found not to be so. In either case, data on the hypothetical disk would become available to an attacker. Best to do as NSA is said to do, and DoD has prescribed in a public standard, to wit overwrite the data one or more times with random data or physically destroy the disk. Only then will some unfortunate future event (re keys or algorithm vulnerability) not expose data. If you use Linux, shred works fine, and there are several commercial products for Windows -- and a few non-commercial ones too. Tossing a key is not 'useless', that's a strawman, but it is insufficient for high levels of future security. A lst point on this; it is not always true that key access and knowledge of the data being protected are congruent. The IT VP might have a key, but be barred from normal access to the systems involved.

On the question of merging the articles, I think the proposal at Talk:WikiProject Cryptography is about right. ww 08:23, 3 November 2006 (UTC)

Huh? I never disagreed with Kasperd. He is supporting my POV.

Note that anything that's said against data disposal by destroying the cryptography keys, is also relevant for any secure communication over a possibly insecure channel (such as the Internet) – if an attacker can eavesdrop the channel, they can store the information and crack it in the future. Does this mean that we shouldn't use cryptography over the Internet? That's absurd. It's obvious that any cryptographic solution only works as long as the primitives/assumptions are unbroken – it doesn't need to be asserted every time one speaks about cryptography, and neither does it mean that the features of the cryptographic system are useless. They are features, and their weaknesses need to be taken into consideration.

The advantage of disk encryption over any other data destruction approach is instant and implicit data disposal ["fast" above probably wasn't a good choice of words], meaning that you don't even have to do anything to securely get rid of your data – just don't post-it the passphrase to the disk when giving it away. ;) A wipe tool will require several passes over the disk; careful physical destruction is not trivial, either. Obviously, if you've got the time, and if the data is worth it, wiping or physically destroying the disk will work better – I'm not questioning that.

Regardless of whether Maxt's points of view (alleged "facts") are original research or not, some notable and more credible cryptographers, including Bruce Schneier, do consider this a safe method of data disposal, and while Schneier's blog doesn't qualify as a reliable secondary source, I think the feature is at least worth a mention as long as the opposition doesn't have a stronger source. -- intgr 09:49, 3 November 2006 (UTC)

Is anyone still fundamentally opposed to re-adding this, or am I clear to do that now? -- intgr 17:22, 24 November 2006 (UTC)

intgr, I don't think you're really reading Maxt's point properly. If we are talking about media sanitization then destroying the crypto keys does not sanitize the media that is encrypted. I do not disagree with your assertion that destroying the keys is probably good enough. But I think Maxt is being justifiably picky about the use of the term "sanitization" or "destruction." Until the data is destroyed (for instance, by overwriting it 7 times with random data, or by phsyically destroying the media) then it is not sanitized or destroyed. As you state, it may very well be inaccessible for all intents and purposes.

A second point though is that cryptography is not unbreakable no matter how secure the algorithm is. If I had the time and resources to attempt to decrypt encrypted data using every possible key combination then it doesn't matter how good the algorithm is. I do not need to recover the key, I simply try every single option. This is why using large key sizes is important- it makes it impossible to try every key combo in a feasible amount of time. The problem is that as computing power accelerates, more keys can be attempted in a shorter period of time, and eventually your 56-bit keys seem relatively useless. You move up to 128-bit, 256-bit, and even higher these days. All encryption can be broken. The only problem is that it might take too long to do so for the data to be useful any more. This is why for data that has a shelf life of only a few hours or days using massive key lengths is overkill. However, the data on your hard drive might still be useful for a long time. If it needs to be kept confidential for the next 50 years then simply deleting the keys used to encrypt it and hoping for the best may not be a good idea. Sir.loucious 23:16, 29 December 2006 (UTC)sir.loucious

I suppose the former point simply comes down to how one defines "media sanitization" or "data destruction". I indeed fail to see a significant difference in (1) making it difficult to read the original data, and (2) making it difficult to access the keys to read the data.

I cannot pretend to be an expert on this, but when "overwriting" the original data 7 times, you are not actually "destroying" the data either – you are merely making the original signal weaker so that it can no longer be detected by the hard disk head itself. And then simply repeating the process 6 more times, effectively achieving that the original data is $x^{7}$ times weaker than the most recent layer of noise. It is not, however, entirely impossible to pick out the initial data with sensitive enough equipment.

The same can be said about physical destruction – you can shatter the disk platter into millions of pieces and then magnetize them, but you cannot absolutely get rid of the data they used to contain – although it may be essentially impossible to read it again, so it is "destroyed" for all practical purposes.

I also did explicitly state "However, if security towards future attacks is a concern, file wiping or physical destruction is advised."

But I don't really think you have a slight clue of how "long" a brute force attack really takes, so I'm going to write this short essay. Please do not take any offence from the phrase "a slight clue", I think you might even agree with me by the time you're done reading.

When speaking of the strength of symmetric ciphers, as long as there are no significant weaknesses in the algorithm, its strength against brute force is an exponential function of the key size, or O($2^{n}$). Thus it does not mainly depend on how "determined" the attacker is – given the steep curve of exponential functions, there is a certain bound of what can be achieved with a limited amount of time and resources (called "computational boundedness").

Moore's law effectively dictates that the computational capacity of computers is an exponential function of time, more precisely $2^{years/2}$ (and while it's an empirical observation, it has held for the entire time that integrated circuits have been in use).

By equating these, it can be said that $2^{n}=2^{years/2}$, or that each bit in key size will buy two years of time from brute force attackers. This implies that to crack an equivalent key through brute force, the attacker would have to double their resources now, or just wait two years. Due to this, it doesn't even matter how much accumulated time the attacker is given for cracking, but only when is the best time to invest one's limited resources and actually start cracking. [see note 1]

It is currently thought that 64-bit keys can already be successfully cracked by very resourceful attackers. Further, NIST recommends phasing out 80-bit keys by 2015. Based on the NIST recommendation it can be said that: $2^{n-80}=2^{(year-2015)/2}$, and thus $year=2\times n-160+2015$.

Due to the very pessimistic estimation, the formula states that 56-bit keys (as in DES) should have already been considered "weak" after 1967, whereas DES was designed in 1975. However, 128-bit keys can be expected to be secure for at least $2\times (128-80)$ more years after 2015, which is 2111. For 256-bit keys, the estimation gives 2367. And note that most symmetric encryption algorithms used today (often AES candidates) do work with 256-bit keys, and they are very lightweight on today's general-purpose processors – there is usually no reason to choose shorter keys over 256-bit ones.

[note 1]: The fastest current record for cracking the DES algorithm was 22 hours and 15 minutes in 1999 (see EFF DES cracker). From this, the cracking rate can be calculated:

${\frac {2^{55}}{(22\times 60+15)\times 60}}=4.50\times 10^{11}\ keys\ per\ second$

A very impressive number by itself. However, consider that cracking a 128-bit key at this same rate would take unproportionally long:

${\frac {2^{127}}{4.50\times 10^{11}}}=3.78\times 10^{26}\ seconds=1.20\times 10^{19}\ years$

For comparison, physicists theorize that our universe has merely existed for $1.37\times 10^{10}$ years. :)

-- intgr 03:41, 30 December 2006 (UTC)

Merge with OTFE

I would oppose merging OTFE with this article, though merging it with Disk encryption would make sense. Full disk encryption only relates to systems that encrypt the entire disk, OS included; the term "OTFE" isn't that specific. Nuwewsco 16:04, 9 October 2006 (UTC)

No, I think it should go into Disk encryption software. Alex.g 16:16, 17 October 2006 (UTC)

I don't think on-the-fly-encryption or full-disk-encryption are specific enough to deserve their own article. Both should be merged with Disk encryption, though we can discuss what the name of the article should be. At the time it was created I would have suggtested disk encryption as the right title, but since then I have realized that a lot of it applies to other storage media as well. I can think of two kinds nonvolatile random access medias: disks and solid state storage such as flash. At first they appear to be quite similar, but when you get into the details you will notice the differences relating to security. Streaming medias such as tapes are different and much simpler to deal with as decades of research in stream ciphers have given us tools to handle it. On-the-fly-encryption is just another way to say the same. Full-disk-encryption does not deserve a seperate article as it is just a minor difference compared to encrypting a partition. There is no differences in the techniques you apply when encrypting a partition and a full disk. BTW Intgr why did you add mergefrom|OTFE and later delete it again? Kasperd 05:24, 27 October 2006 (UTC)

This discussion should be continued on Wikipedia talk:WikiProject Cryptography#Disk encryption reorganization. -- intgr 22:57, 2 November 2006 (UTC)

"BTW Intgr why did you add mergefrom|OTFE and later delete it again?" Oops, that was a mistake; apparently I reverted it while reverting some linkspam. Re-added now. -- intgr 11:02, 3 November 2006 (UTC)

I've never heard the term OTFE before, but I think that we should keep FDE because that is the term that Seagate is using for their products. Simsong 01:54, 19 November 2006 (UTC)

OTFE, FDE, and Disk Encryption and different beasts. If you think they should be merged, maybe you should read about them more. So please do not suggest to merge them, unless you have a very good reason. Saqib 20:50, 21 December 2006 (UTC)

Your claims are not really that convincing; "you should read more", "do not [even] suggest"? Mind explaining what's so different about them?

To me, they're just raw layers of encryption for any purpose. Here's my take: one of those may encrypt the entire disk; the other might encrypt a partition; yet another encrypts and stores everything in a file. They all expose a virtual disk or partition to the operating system, where the operating system will decide what to store on it. If you abstract away the upper and the lower layers (e.g., whether they're disks, partitions, or backed by a file on an existing file system), you have an universal layer that is capable of encrypting any kind of block-addressable device, and exposes this as a virtual block-addressable device to the operating system. All the techniques used in them all, and the basic functionality provided, are the same.

For example, the Linux dm-crypt is capable of doing any of these – all block-addressable devices are abstracted as "block devices". You can encrypt /dev/hda (a whole disk), /dev/hda1 (a partition) or /dev/loop/1 (a loopback device backed by a file). And you get /dev/mapper/<whatever>, on which you can store a a partitioned disk, file system, or use as swap space. If you want pre-boot authentication, you set up an initrd to prompt for the password and initialize the virtual device before booting the system on it.

I really can't see why not to explain the similarities and differences in a single article -- intgr 21:43, 21 December 2006 (UTC)

On the fly encryption is essentially meaningless in this context. Full disk encryption is one way of protecting data at rest with encryption; the other being the encryption of individual files and folders. If this article should be merged with anything, its "protecting data at rest". --Duffbeer703 19:20, 16 January 2007 (UTC)

Notable absences in implementations section

PGP Whole Disk Encryption —Preceding unsigned comment added by 66.162.146.82 (talk) 15:56, 3 January 2008 (UTC)

merge with disk encryption

I really think we should merge Full disk encryption with disk encryption --Bikepunk2 (talk) 16:22, 16 February 2010 (UTC)

Is there any difference between the two? --Explodicle (T/C) 19:56, 23 February 2010 (UTC)

apparently not really. That's why I suggest the merging. Bikepunk2 (talk) 12:30, 1 March 2010 (UTC)

I just redirected disk encryption, since it didn't really contain anything other than links that are in Full disk encryption. --Explodicle (T/C) 16:22, 1 March 2010 (UTC)

File & disk encryption article restructuring

My suggestions for restructuring of the file & disk encryption articles are:

• Whole disk encryption / full disk encryption deserves its own separate article
• It is good to have this overview article here, covering whole disk encryption and other relevant types of encryption. But the current name, "disk encryption" seems to me too similar to "Whole disk encryption". Do we have any reliable sources that suggest the term "disk encryption" is the best choice as the title for this overview article? How about "file and disk encryption" instead?
• 'Stackable' cryptographic filesystems deserve to have their own separate article. At the moment they are lumped in with "General-purpose file systems with encryption" at the Filesystem-level encryption article.
  • Some source material for this separate article might come from: 1, 2, 3
• But there could be a small section here at this overview article explaining that filesystem-level encryption can consist of either "stackable cryptographic filesystems" or "General-purpose file systems with encryption"
  • So the Filesystem-level encryption article should become a redirect to that small section, and its current contents should be moved to this overview article and to the new "stackable cryptographic filesystems" article.
• The encryption layer in storage stack article should be merged into this one.

Thanks. Open4D (talk) 07:04, 29 November 2013 (UTC)

It all depends on how you define the terminology, which I agree is ambiguous. I could be misunderstanding you, but it seems your motivation to separate "full disk encryption" from "disk encryption" is because you consider FS-level encryption to be a subset of disk encryption? I would say it's not disk encryption (it encrypts individual files, not disk blocks); see the section here titled "Disk encryption vs. filesystem-level encryption"

Here's the dichotomy, which rougly matches the current terminology and article layout on Wikipedia:

• Storage encryption (different approaches explained at encryption layer in storage stack)
  • Disk encryption (i.e. anything that encrypts sector-by-sector without knowledge of higher-level concepts like extents, files, directories, etc)
    • Whole disk encryption (TrueCrypt, dm-crypt, hardware-based full disk encryption)
    • Partition encryption (TrueCrypt, dm-crypt, FreeOTFE)
  • Filesystem-level encryption (anything that exports a file system API to the OS)
    • General purpose filesystems with built-in crypto (ZFS, NTFS etc)
    • Cryptographic file systems
      • Stackable cryptographic file systems (eCryptfs, EncFS)
      • Disk-backed cryptographic file systems (StegFS, Rubberhose -- mostly academic projects)

Given this dichotomy, I don't think it makes much sense to separate "disk encryption" from "whole disk encryption" or "partition encryption". They share the same encryption techniques (XTS & others described at disk encryption theory), the same weaknesses (no integrity checking/authentication and subject to content leak vulnerabilities). They're often implemented in the same piece of software (TrueCrypt and dm-crypt support both modes), etc.

> 'Stackable' cryptographic filesystems deserve to have their own separate article. At the moment they are lumped in with "General-purpose file systems with encryption" at the Filesystem-level encryption article

I'd say stackable file systems are a subset of cryptographic file systems, not general-purpose file systems. I don't think it needs a separate article, it can very well be a section in "Filesystem-level encryption", as long as it doesn't get too long. Given that the article is still a stub after 6 years, I wouldn't worry about that. But if you're committed to writing a full article on the subject, then that sounds reasonable.

-- intgr [talk] 22:10, 29 November 2013 (UTC)