Talk:Disk encryption theory

External links

Does the link to ipcores belong on this page or Disk encryption hardware? Kasperd 19:22, 3 September 2006 (UTC)

Cores are closer to crypto algorithms than to actual boxes, so I think the link has more affinity here. The Disk encryption hardware article does not currently mention LRW. Dimawik 03:58, 4 September 2006 (UTC)

I was under the impression that these are blueprints detailed enough that they could directly be turned into a piece of hardware. If I'm correct about this, I'd say they are closer to a piece of hardware than an algorithm. But still I agree they are not actual hardware. Kasperd 13:08, 5 September 2006 (UTC)

EME/CMC patents

I think in the article the statement "CMC and EME were considered for standardization by SISWG. CMC was rejected for technical considerations. EME is patented, and so is not favored to be a primary supported mode." is wrong. Here it looks like EME2-AES (and XCB-AES but I don't know if this relates to CMC) are indeed standardized. — Preceding unsigned comment added by 175.156.196.14 (talk) 14:54, 3 June 2011 (UTC)

Can somebody provide a link to the patent (I cannot find it on patft.uspto.gov) or at least where SISWG discusses it (their mail archive is public). GBL 12:13, 18 January 2006 (UTC)

Added.

Maxt 12:21, 19 January 2006 (UTC)Maxt

Regarding the request for the EME flaw: The reference for the EME mode flaw is in the process of being obtained. 11:57 11 September 2006

I removed the reference to the EME flaw until a proper sitation could be found chongo 13:05 11 September 2006

Integrity

The integrity paragraph in the problem definition section describes a sector per sector integrity. But this protection is of limited value as an adversary could combine data and metadata from different points in time and thereby trick the decryption module to decrypt the wrong data. This is a serious attack in scenarios where the adversary may have legitimate access to some of the encrypted data, but not all of them. Kasperd 10:16, 28 December 2005 (UTC)

To some extent it may even be possible to protect against rollbacks. This article by Kristian Gjøsteen has some discussion about it http://eprint.iacr.org/2005/083. Kasperd 10:29, 28 December 2005 (UTC)

Maybe this section should be moved to Talk:Disk_encryption. Kasperd 10:29, 28 December 2005 (UTC)

done GBL 11:31, 18 January 2006 (UTC)

LRW

I don't think that the following sentence is true: The LRW mode of operations was introduced by Liskov, Rivest, and Wagner. If it is true, then a reference should be added. Maxt 13:57, 6 January 2006 (UTC)Maxt

I also doubt that. They did introduce tweakable block ciphers in this article http://theory.lcs.mit.edu/~rivest/LiskovRivestWagner-TweakableBlockCiphers.pdf. LRW is based on this article, but it is not introduced in the article. So I also think a reference is missing to document who introduced LRW mode. Kasperd 12:09, 8 January 2006 (UTC)

LRW mode is what described in Theorem 2 of the ref combined with some particular 2-xor-universal (AXU_2) function. GBL 12:13, 18 January 2006 (UTC)

You are right. The LRW mode in fact was introduced by Liskov, Rivest and Wagner. They specify the mode generally. With other modes (like CBC or CTR) there are no prescribed ciphers. In case of LRW there are also no prescribed encryption or hash algorithms. Only the mode is defined. The choice of these algorithms has nothing to do with the mode as long as the algorithms fall into the right categories (i.e. a cipher, a hash function with certain desired properties). However, what's still unknown is who came up with the name LRW. Maxt 12:04, 19 January 2006 (UTC)Maxt

LRW issue: P1619 right now (Aug 30th 2006) appear to be unhappy with the LRW. Major changes are being proposed, see for example [1]. It seems like the activity is spurred by a comment made by Niels Ferguson in the Crypto conference. Essentially, if the K2 is accidentally (due to poor design of the overall system) is encrypted on the media, it is leaked. Dimawik 02:01, 31 August 2006 (UTC)

This issue has been known for years (and the IEEE drafts have mentioned it for years too). There's no news.

I agree with the first statement. But 30 messages on email reflector over a span of the day is news to me. Dimawik 07:54, 3 September 2006 (UTC)

The text of the article now says that the P1619 decided to replace the LRW. Minutes of the meeting contain no such thing. Any comments by people who know? Dimawik 00:45, 11 September 2006 (UTC)

The text of the article now says "SISWG is looking into possible alternatives including a replacement tweak function and a completely new mode". See below for more details. chongo 11:48 11 September 2006 (UTC).

Some members of P1619.0 informally discussed issues related to LRW. Following that discusssion a formal meeting of P1619.0 was held. The Aug 30, 2006 meeting minutes show:

There are implementations that cannot guarantee where and how K2 is stored and that is not followed by 0. This is clearly an issue with current proposal.

XCB could be used to realize a narrow block mode, or LRW could be fixed to address this issue (even if there are many applications). One possible solution would be to forbid SW implementation of LRW, and specify that is only for HW ones that do not store K2 on the data path.

A raw poll showed that almost no one would approve 1619 as is. We need to have a meeting soon where there are a few proposals to fix the tweak and decide upon that.

AI All: come back with a proposed tweak change for LRW and a better understanding of the collision problem.

Next meeting will be the start of 1619.0 and first item on the agenda will be to solve the tweak issue.

As of September 2006, the P1619.0 group is discussing variants on the LRW treak as well the replacement of LRW with XCB which can be seen in the P1619 Email archive. chongo 11:31, 11 September 2006 (UTC)

The article now states that:

"other types of encryption software (including on-the-fly volume encryption software, such as TrueCrypt) the probability that the tweak key will be encrypted with itself is negligible".

I'm curious how does TrueCrypt manages to prevent the LRW tweak key from being self encrypted? Do they use Encryption-Scheme Security in the Presence of Key-Dependent Messages or do they take other steps to keep the tweak key out of the plaintext stream? chongo 12:03, 11 September 2006 (UTC)

There are only a few ways to encrypt the tweak key currently in RAM with itself. One is bad design/implementation, the other is the tweak key being stored in swap/hibernation file. Now, two things: 1) TrueCrypt can't encrypt the operating system (so the swap/hibernation file senario does not apply to TrueCrypt). 2) TrueCrypt uses only random keys (rejects non-random-looking or low-hamming-weight keys) so the chance that the a plaintext block will contain the tweak key is 2**-128 for 128-bit ciphers and 2**-64 for 64-bit ciphers (ie. in both cases the probability is negligible).

There are other ways that an attacker can attempt inject a tweak key into the plaintext space. The RAM path you outline is just one of several possible vectors, BTW. And some of those vectors are not impacted by generating random or pseudo-random keys. In fact, some methods can make use of the fact that keys are being generated as part of their attack. I assume you have looked into such other attack vectors?

What other attack vectors are there? If an adversary was allowed to make you save your key material anywhere, no mode of operation can help you. You lose all security.

That might be true. However if you require the key material to only be stored on the encrypted device and give the encryption algorithm access to real randomness, there may be ways to achieve security. My point here is, that if key material is encrypted in some random way, which the adversary cannot predict, then I don't see an obvious way to force the key to be leaked except by using sector numbers as a covert channel since most storage encryption schemes do not hide access patterns.

Probably this approach does not lead to any efficient solution for the problem. Rather than assuming an arbitrary adversary to choose key dependent messages, we probably should consider some more restricted key dependent messages.

I can come up with one realistic attack vector. Assume the user decides to do a dump of system memory with the purpose of later performing some debuging analysis of the dump. Now performing such a dump to an unencrypted storage is always going to be a problem, and there is nothing to do about that. The user should know this and perform the dump to an encrypted storage, and obviously the key for this storage must currently be in memory, and thus written as part of the dump to the storage. Kasperd 14:49, 13 September 2006 (UTC)

If you use TrueCrypt as you are told to, you prevent this attack. The TrueCrypt documentation says: "we strongly recommend that you disable memory dump file generation on your computer at least for each session during which your work with any sensitive data and during which you mount a TrueCrypt volume". http://www.truecrypt.org/docs/?s=memory-dump-files . They also urge users to disable swap file, and hibernation file in the same situation.

It seems the reason they give such advice is because the file could potentially written to an unencrypted file system. If you configured the system to do such dumps to an encrypted storage, you would not expect the key to leak. However the way TrueCrypt works, it could leak. This is the reason LRW was rejected by SISWG P1619. It is a weakness in LRW, not specific to TrueCrypt. Kasperd 04:53, 17 October 2006 (UTC)

I agree. Well, it seems to me that they covered that issue specifically in another section of the "Security Precautions".Maxt 19:22, 17 October 2006 (UTC)

You are right, they actually do cover lots of security problems in that section. Notice the introduction Please note that it is impossible to inform about all security risks here. There are, unfortunately, too many of them and it would require thousands of pages to describe them. And indeed there are problems which are not mentioned. Kasperd 04:10, 20 October 2006 (UTC)

Yes, and what's your point again? Maxt 13:36, 20 October 2006 (UTC)

I was commenting on the discussion regarding one of the flaws in LRW. My point is, that there are real weaknesses in LRW. Things that could be safe with a better mode are not safe with LRW. Another point, which may not be that relevant to this particular discussion is the fact that TrueCrypt seems to assume the user knows about every possible weakness and avoids triggering them. Some users may have an intuition about what is safe and what is not safe (such as not storing an unencrypted version of the key or password), but I think very few users have an intuition about which things are unsafe to do because of obscure weaknesses (such as storing an encrypted version of a memory dump containing the key). It seems users are supposed to carefully read the entire documentation and remember all the weaknesses. And avoiding all of them may not be that practical. The LRW weakness may be mitigated by using different secondary keys before and after applying the block cipher. TrueCrypt does not have the tight memory requirements like some hardware implementations where every byte counts. Kasperd 19:22, 21 October 2006 (UTC)

> It seems users are supposed to carefully read the entire documentation and remember all the weaknesses.

Well if not the entire documentation, they should at least read the "Security Precautions" chapter. It's like driving your car above the maximum allowed speed of the tyres. You are supposed to read the maximum allowed speed of the tyres, remember it, and not exceed it. If you do exceed it, you may die. If one is from the lazy crowd, he will face the consequences. It's a serious security product and as such it requires a serious and responsible approach from the user, it's not a toy for the careless.

>The LRW weakness may be mitigated by using different secondary keys before and after applying the block cipher.

Based on my benchmarks, LRW mode is already 20% slower than ECB. Using two tweak keys would not only not be LRW mode anymore, it would also be 40% slower than ECB, which would be major slowdown (remember why they chose Rijndael as AES, instead of the slow Serpent?) And what would be the benefit? For the purposes of TrueCrypt the weakness is insignificant (it's a problem for full disk encryption software where the chance that the key will encrypt itself is not negligible, due to the swap file). For TrueCrypt, the LRW issues are practically non-issues (see above), and if they should become real issues, they are already mentioned in the manual. Maxt 11:36, 22 October 2006 (UTC)

I think you exaggerate the cost of using two different keys for tweaking. And I don't know what to make of your numbers without knowing what key size you used to perform those benchmarks. There is a difference in the performance when using 128 bit keys and 256 bit keys, but the absolute additional cost of doing LRW is the same in both cases. I didn't even know that TrueCrypt supported ECB mode, why include a mode known to be that weak? And are you sure the TrueCrypt implementation is optimal with respect to performance? There is a lot of potential for speedup of LRW by precomputing parts of the patterns needed for XOR. As for not being LRW I disagree, it still is LRW just with an additional whitening layer. You can do the full LRW and after that XOR with a pattern computed in the same way, but with a different key. But it is equivalent to just xoring the two keys before computing the pattern. Claiming that TrueCrypt is more secure than a full disk encryption doesn't make sense to me. It will always be less secure to store the key completely unencrypted rather than storing it on the media it is used to encrypt. Besides, encrypting a complete disk using TrueCrypt is just a matter of configuration. Kasperd 04:04, 23 October 2006 (UTC)

> I didn't even know that TrueCrypt supported ECB mode

I didn't say that TrueCrypt supports ECB mode, and it of course does not. My benchmark was basically based on comparing the speed of encryption of TrueCrypt 4.0 (CBC mode) and TrueCrypt 4.1 (LRW mode). There was a 15-20% slow down, obviously due to the addition of the LRW hash. I referred to it as ECB mode because it is the fastest mode (so it is ideal for performance comparisons) and CBC (TC 4.0) is just as fast as ECB.

> There is a lot of potential for speedup of LRW by precomputing parts of the patterns needed for XOR.

I believe TrueCrypt does that already. But you know more about the inner workings of TrueCrypt than I do probably.

> Claiming that TrueCrypt is more secure than a full disk encryption doesn't make sense to me.

I didn't claim that. If you read what I wrote again, you will see that what I wrote basically was: True full disk encryption software should not use LRW mode, because it has a non-negligible chance that the tweak key will encrypt itself. In contrast, in all configurations under which you can use TrueCrypt, the chance that the LRW tweak key will encrypt itself is practically negligible (and the obscure scenario where it could happen is documented in the TC manual).

> Besides, encrypting a complete disk using TrueCrypt is just a matter of configuration.

Yes, it is possible to do that by encrypting an image of a VMWare disk etc. But even in such configuration the tweak key would not encrypt itself even if it ended up in a swap file (the tweak key could end up in the swap file of the host operating system, under which VMWare would be running, but TrueCrypt cannot encrypt this "uppermost" swap file, so we're back to square one :-) And as the TrueCrypt manual recommends, this uppermost swap file should be disabled when you mount a TrueCrypt volume.Maxt 18:23, 25 October 2006 (UTC)

You should also be aware that encrypting a value that is a low hamming distance from a tweak key (no matter how the tweak key was generated) can leak key material. It is not sufficient to guard against encrypting the exact value of the tweak key.

You probably confuse this with the situation where the tweak key is low-entropy. Then if the plaintext is low-entropy too, collisions are more likely. If the tweak key is high-entropy and random-looking, the Liskov-Rivest-Wagner proof holds.

I removed all of that text about IEEE SISWG and TrueCrypt. The article on Disk encryption / LRW is not the place to debate a standard. Just stick to the LRW description. If you want to talk about the standard, then take that up in a standards body or start a Wikipedia page about SISWG. If you want to remark about the TrueCrypt implementation, then take those topics on the TrueCrypt. 15:25 13 September 2006

Since I think that the LRW text deleted by 67.188.223.123 has some value, I have moved it to the P1619 article, where the discussion about the current LRW tribulations seems to be a better fit. In the process, I have removed more controversial aspects of it (the ones that required citations :-) Dimawik 05:23, 14 September 2006 (UTC)

I have added a simple link to SISWG article to the LRW section. CMC/EME section does have a similar link. Dimawik 05:33, 14 September 2006 (UTC)

What is "F"?

The math in the treatment of LRW uses the symbol F which is not introduced in the paragraph. However, 'A' is used, so perhaps the math doesn't match the prose? I don't understand it so I can't fix it.

Also, the aside about precomputing uses a '+' symbol; I think a circled plus (XOR) is needed?

—Długosz

It looks like A and F both are names for the additional key. Pehaps we should take a look on the article introducing tweakable block ciphers to see what notation is used there. The + symbol of which you talk is addition in the finite field, and as such I don't think the using + can be considered incorrect. However since in in the standard representation addition in the field is the same as XOR, using the circled plus would be equally correct and possibly easier to understand. How about the XOR operation already used in the definition? Does the proof use properties of XOR or the finite field to show security? Kasperd 11:01, 6 February 2006 (UTC)

Fixed. GBL 13:21, 8 February 2006 (UTC)

Not fixed. Perhaps the fix was reverted? 195.249.104.29 (talk) 11:35, 26 September 2019 (UTC)

Simple approaches

"On the other extreme it maybe be enough to adversary, who lured the user to store some file, to know that the file is actually stored (e.g., to convince the curt"

Can anybody figure out what that sentence was trying to say? I was about to fix the "maybe be" and then realized I really had no idea what was going on here...

It is a bit confusing. It doesn't quite fit with the rest of the text, even after being cleaned up. I believe what he is trying to say is something like this:

"Another difficulty with establishing a threat model is assessing the goal of the adversary. While most attackers are after the data on the hard drive, some attackers have different goals. One attacker may require a large portion of your data in order to act, while at the other extreme, it may be enough for the adversary to know only that a particular file was on the machine.

For example, some encryption methods encrypt the individual files, but not the filing system. This prevents the attacker from reading the file itself, but allows him to find the names of the files that are encrypted. If the attacker's goal was not accessing the data, but placing incriminating data on to the drive, he could then send the target a file containing incriminating information, with the intent that the target save the information to his drive. The attacker would then check to ensure that a file with that name had been saved to the drive, and contact the authorities to turn the person in.

If done properly, this could even work on an entirely innocent target. For instance, the attacker could send the target an encrypted file containing child pornography, then alert the authorities, supplying said authorities with the key to the file in question. The target, not possessing the key, would be completely unaware of the contents."

Filksinger 17:02, 16 October 2006 (UTC)

Clean-up

I made some clean-up and I hope to continue it soon (at least to describe how to encrypt 520-byte blocks). The following is a list of changes I made

• Examples of what is “threat model” and how hard to get it right should be in threat model. I moved the text to talk:threat model.
• “change the MBR to make the disk unbootable” does not hide information because you will end-up with non-bootable computer :-)
• 520-byte sectors of AS/400 are mentioned in P1619/D9
• Apparently, some believe that in $E_{K}(P\oplus T)\oplus T$ (LRW) $T$ is the tweak. It is not true, the tweak is the input to the cipher — I renamed $T$ to $X$ to avoid confusion.
• Refs to hardware moved to disk encryption hardware.

Btw, I guess we should seriously clean-up this talk page as well GBL 16:58, 26 November 2006 (UTC)

Thanks for taking up the dirty work. :)

There's more to do than you can probably imagine at this point, please see Wikipedia talk:WikiProject Cryptography#Disk encryption reorganization. As for cleaning up talk pages: one does not clean them. If at all, they are archived, but the current talk page is not long enough to warrant that. Also, note that new comments should be added to the bottom, not at the top. -- intgr 17:11, 26 November 2006 (UTC)

I agree this talk page may be needing a cleanup. Maybe parts of it should be archived (though I don't know in details how archiving of talk pages work). But have all the things discussed on this page been fixed yet? Kasperd 06:28, 30 November 2006 (UTC)

See WP:ARCHIVE for details about archiving talk pages. -- intgr 07:47, 30 November 2006 (UTC)

typo in XEX?

"...and α is the primitive element of GF(2128) defined by polynomial x (0x2 in hexadecimal)."

0x2 in hexadecimal??? Doesn't make much sense to me. Does this mean 0*(x^2), which is 0? Or 0*x*2, which is 0 again? Or is "0x" the prefix for hexadecimal and it is the constant "2"? Maybe it's a typo for "K2 in hexadecimal" (the second key part)? 141.76.46.116 08:47, 30 August 2007 (UTC)

"x" is represented by an integer with the second least significant bit set: 10 in binary. "0x" is traditional notation for hexadecimal numbers. GBL 13:44, 1 October 2007 (UTC)

I still dont get what alpha to power j is meant to be. Is it (2 << j) ?

For small j it is (1<<j) :-) Dimawik (talk) 23:54, 17 May 2010 (UTC)

Eliminating Stream Ciphers?

It's really problems 2 and 3 together that lead to eliminating stream ciphers from consideration, right?

The issue with a stream cipher is that for a given IV and key, there's (probably) no way to jump to the n^th byte of output.

So if you had only one IV it would be abysmally slow (problem 2), and if you have lots of IVs you waste space (problem 3).

Is there a better way to explain the no-fast-jumping problem? --Memoss (talk) 01:06, 1 May 2009 (UTC)

No, this isn't right. There are stream ciphers that allow "fast jumping", such as LEVIATHAN and Salsa20 - we call these "seekable" stream ciphers, after the "seek" function in C. Also, with a strong stream cipher there should be no problem using the disk sector as the IV; you don't need to store the IVs. ciphergoth (talk) 07:47, 1 May 2009 (UTC)

The problem with using stream ciphers for disk encryption is that the attacker may be able to observe the ciphertext in multiple points in time. With an unchanging IV, XORing two different ciphertexts from the same location gives you the exact difference of the plaintexts, as it cancels out the keystream. While CBC is also not good in this scenario, it doesn't fail quite as badly. -- intgr [talk] 19:32, 1 May 2009 (UTC)

Actually i'm not sure there are any articles on Wikipedia that clearly explain what happens when an IV is reused with stream ciphers. Sounds like it would be relevant to the stream cipher and initialization vector articles; if anyone is looking for low-hanging improvements to make, this would be one. -- intgr [talk] 19:49, 1 May 2009 (UTC)

The term 'CTR' should be defined prior to its use in order to make it more readable to those less knowlegble (e.g. me) -thanks! Also the term 'zeroed out' with respect to IV's I find very inprecise and could be better worded or briefly explained - thanks once again. —Preceding unsigned comment added by 84.13.63.14 (talk) 18:08, 8 September 2009 (UTC)

Actually come to think about it 'ECB' should also be defined too (but I happened to know what that meant) (Electronic Code Book). —Preceding unsigned comment added by 84.13.63.14 (talk) 18:11, 8 September 2009 (UTC)

I object: stream ciphers are perfectly valid and functional for the purpose of disk encryption.93.205.124.81 (talk) 03:47, 28 March 2010 (UTC)

Stream ciphers have two important weaknesses when used for disk encryption:

1. As pointed out above, they are extremely weak when an attacker can capture two ciphertexts encrypted with the same keystream. It is downright easy to recover two English-language ASCII texts XORed with each other, which is what an attacker gets if he finds them both written to the same disk block. (This objection disappears if the cipher can be integrated into a file system which can store a per-block IV.)
2. Second, a stream cipher permits controlled modification of the plaintext. While the absence of authentication limits what can be expected, using a stream cipher an evil maid can trivially make arbitrary XOR changes to known disk locations. (Say, system files that are placed in predictable locations by the OS installer.)

They are "perfectly valid and functional" in a narrow clintoneque sense; in practice they have significant weaknesses. Far better is a disk block sized block cipher. See OAEP for an example of a way to build such an "all-or-nothing transform".

71.41.210.146 (talk) 06:11, 3 April 2010 (UTC)

These weaknesses aren't a problem in all cases. For example, ZFS encryption uses Galois/Counter_Mode by default. This works because ZFS records are immutable and each record gets a new IV, so each keystream is used just once. This does come with some overhead for storing authentication information, but this is practical because it's stored with each ZFS block header (which describes a whole ZFS record, by default 128KiB) rather than with each individual sector. Since ZFS already stores checksum information and other metadata for each record, there is in practice no additional storage overhead when enabling encryption.

The article should capture these caveats around stream ciphers rather than saying they are ruled out entirely. Majiir Paktu (talk) 21:45, 29 September 2023 (UTC)

"Waste disk space"

The third point of the problem description list, "The encryption method should not waste disk space.", is not entirely clear to me. Maybe it should be replaced with something along the lines of "The extra disk space used by the encryption method disk should be constant (i.e. independent of disk size)" or something similar? -- LM 2009-09-17 —Preceding unsigned comment added by 118.173.131.127 (talk) 10:49, 17 December 2009 (UTC)

Stream ciphers in disk encryption

[Section moved from User talk:intgr]

While it is true that

${\begin{aligned}p_{1}\oplus k&=c_{1}\\p_{2}\oplus k&=c_{2}\\\Rightarrow c_{1}\oplus c_{2}&=p_{1}\oplus p_{2}\end{aligned}}$

what knowledge can be gathered from $p_{1}\oplus p_{2}$, as long as either one is unknown? 93.205.108.67 (talk) 16:53, 29 March 2010 (UTC)

As long as p1 and p2 aren't random, it leaks a whole lot of information. Stream ciphers only work because one of the operands (the keystream) is random and secret.

In the worst extreme case, the sector was previously filled with zeroes and was overwritten with actual data, is pretty likely in many applications; this would leak the whole sector to the attacker. But the XOR between two plaintext documents can be quite revealing for cryptographers too. -- intgr [talk] 05:24, 30 March 2010 (UTC)

And as noted in the section you decided to delete completely, exactly this kind of danger was explicitly noted as having to be taken care of beforehand. So, given the specific case of a stolen notebook, stream ciphers provide confidentiality (even without previously randomizing the disk's sectors).

Therefore, I would like you to undo your deletion and reinstate the section.195.200.70.41 (talk) 13:56, 30 March 2010 (UTC)

---

What you state above is true, but it seems that disk encryption in general is focused on block ciphers, at least in some part due to this aspect. And especially now that XTS has been accepted as a standard for disk encryption.

Anyway, the security aspect wasn't my primary concern with the section, but I couldn't fit any more into the edit summary. Here are some of my reasons against it:

1. I haven't actually heard of any disk encryption products using stream ciphers for disk encryption, nor any papers or articles written on the subject. As such, the claims made in this section cannot be verified from a reliable source. If such products exist, I suspect it's because they didn't do their research or don't actually care about security.
2. Presents the misconception that block ciphers are slow and stream ciphers are fast. The truth is, nearly all widely used block ciphers are slow because they use S-box/P-box lookup tables, not because they're block ciphers. Recent ARX-based (addition-rotation-XOR) block ciphers, like also most stream ciphers, can be just as fast. Threefish and TEA/XTEA are examples of ARX block ciphers.
3. The "Some well-known secure stream ciphers" part lists ciphers that are hardly ever used -- at least not in open standards or protocols. As far as I can tell, Salsa20, RC4 and A5 are the only noteworthy stream ciphers that have any traction at all in the real world. Given that the rest get quite little attention from the public and academia, I think there's no basis to call them "well known" nor "secure".

In particular #1 of the above is problematic because it doesn't conform to Wikipedia's verifiability policy. -- intgr [talk] 14:57, 30 March 2010 (UTC)

---

If this is your wish - be it as it may. I will not insist too much on this. Just a few last comments regarding your statements above:

• Do you maybe have an explanation, why a group of experts standardizes XTS, although it seems as if they did not interpret the original XEX-paper correctly? Besides, it is XTS-AES, which has been standardized. XTS in conjunction with different ciphers is not. Might this standard therefore be likely to change in the near future?
• There may be block-ciphers, which reach comparable efficiency to stream ciphers, however: block ciphers require chaining, resulting in additional operational overhead and therefore are bound to be slower than stream ciphers.
• The listed stream ciphers were only a small extract from the eSTREAM project phases - all of which have received intense review by an assortment of well-known cryptographers, e.g. Vincent Rijmen, who was one of the project's judges.

You might also want to take a look at

• "The eSTREAM Project".
• "List of papers".
• "Measurements of stream ciphers".
• "New Features of Latin Dances: Analysis of Salsa, ChaCha, and Rumba".

• On security in general: I was under the impression, that security/confidentiality can only be measured with regard to an attacker's profile and abilities. It remains unclear, why the single profile in the article's opening should be the only valid one.93.205.121.246 (talk) 17:01, 30 March 2010 (UTC)

Don't get me wrong, it's not my "wish" to keep stream ciphers out of this article, just that I disagreed with many things stated in the original addition, and that it didn't cite any sources where it mattered. If you can find any reliable sources for using stream ciphers in disk encryption then I'd be happy to see that summarized in the article.

RE your point #2, you must be kidding me. The overhead of block encryption modes is negligible. The overhead of CBC for instance is 1 XOR operation per block, same as stream ciphers where you have to XOR the keystream with the plaintext.

#3: Yes, the eSTREAM project is doing good work at developing stream ciphers. But still it's nowhere close to the amount of cryptanalysis work done on existing block ciphers and hash functions, simply because almost nobody uses stream ciphers. I will bet that the SHA-3 competition has generated more papers in its short life than eSTREAM ever has.

-- intgr [talk] 02:24, 31 March 2010 (UTC)

Since we are talking about usually less than 20 CPU cycles required to encrypt one byte of plaintext, depending on the cipher, even one additional cycle required for an additional XOR actually does matter. —Preceding unsigned comment added by 93.205.111.251 (talk) 15:41, 2 April 2010 (UTC)

And the same overhead applies to stream ciphers. It doesn't take 1 cycle; with a 64-bit operation it takes 1/8 cycles per byte, and probably less because modern CPUs will parallelize it. -- intgr [talk] 10:40, 3 April 2010 (UTC)

Could you provide a valid reference? Any reference known to me (including the ones mentioned above, most notably "Measurements of stream ciphers". always come to the result, that all modern stream ciphers are far faster than any block cipher at the same security level.195.200.70.40 (talk) 05:16, 6 April 2010 (UTC)

A reference for what? I said that the overhead of block cipher modes of operation is irrelevant, not that all block ciphers are as fast as stream ciphers. As for some that are fast, I already pointed out ARX-based ciphers like Threefish and TEA/XTEA above. -- intgr [talk] 06:06, 6 April 2010 (UTC)

Issues with XTS

There is also an issue about the size of the filesystem encrypted with the support of XTS. This is discussed here: http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/2008-September/002265.html —Preceding unsigned comment added by 62.2.182.207 (talk) 19:40, 1 April 2010 (UTC)

This is a misconception, since it does not apply to large filesystems (containing many data units/sectors, which are encrypted totally indepently), but to very large single data units, i.e.: The size of any single data unit should not exceed 2⁷⁰ bytes. The data unit size for a typical filesystem is between 512 and 64536 bytes only (2⁹/2¹⁶).93.205.111.251 (talk) 15:37, 2 April 2010 (UTC)

This was also discussed on the dm-crypt mailing list. —Preceding unsigned comment added by Calestyo (talk • contribs) 21:43, 26 July 2010 (UTC)

Comparison of LRW mode and successors with CBC-ESSIV

Is it right that LRW mode was invented to solve the watermark problem in CBC-plain mode that is already solved by CBC-ESSIV? But CBC-ESSIV does not need another key so it allows an encrypted block device that have the same size then the underlaying block device (IMHO a big advantage of CBC mode).
Summaray: Where are the main differences between CBC-ESSIV, original LRW (where some weaknesses have been found) and its successor XTC and XEX? --RokerHRO (talk) 07:40, 17 May 2010 (UTC)

All of the modes mentioned keep the sector size. LRW is broken, ESSIV is slower to start and not blessed by NIST. Dimawik (talk) 00:00, 18 May 2010 (UTC)

Hum, so if there are no known weeknesses in CBC-ESSIV I can use it in my own applications, because it looks simpler to me and I think I've understood this mode completely. :-) But of course a comparison for inititalization speed and encryption speed would be nice. --20:28, 19 May 2010 (UTC) —Preceding unsigned comment added by RokerHRO (talk • contribs)

The CBC-ESSIV mode was invented by a Linux developer. However, the industry and academia at large has never taken this seriously, which unfortunately means that it has had little review by cryptographers.

The conventional wisdom of using CBC is that one should never re-use a single IV value. When you overwrite data on a disk sector, ESSIV does exactly that. While I can't see any problems with that, using a cryptographic primitive in a way it's not designed to be used sounds bad. Cryptography is always harder than it looks, so I'm leaning towards XTS.

When I did some benchmarks on dm-crypt years ago, the CPU overhead of ESSIV seemed to be small, within 10% when used with AES-256.

Anyway, if you don't absolutely need small disk blocks and random access for writes, you SHOULD use standard cryptography techniques like CBC or CTR with randomized IVs on every write, and MAC your data. Because disk encryption as described in the article makes quite a few tradeoffs that shouldn't be done in regular crypto applications. -- intgr [talk] 18:15, 20 May 2010 (UTC)

Well, I think the Counter Mode (CTR) looks simple enough and it allows parallel encryption/decryption. I wonder why such simple mode (simpler than CBC and all the other "more sophisticated" chaining modes, LRW, XEX, XTS etc.) isn't used earlier. On the other hand: Using a simple counter and encrypt it once to create an unpredictable result looks the same as hashing the block number to get an IV for CBC (if the block cipher is used as hash function). --RokerHRO (talk) 06:03, 10 August 2010 (UTC)

CTR mode cannot be applied to disk encryption (as specified in this article) because using it securely would require extra space for IV storage. If the IV is statically derived, not stored per sector, then it's vulnerable to the same attacks as stream ciphers; read talk page section #Stream ciphers in disk encryption for details. -- intgr [talk] 12:59, 10 August 2010 (UTC)

CMC algorithm confusion

The abstract of Halevi et al.'s A Tweakable Enciphering Mode describes CMC as encryption + masking + decryption. The rest of the article however corrects this to as encryption + mask + encryption and argues against the first mode (see section 4. Re-orienting the bottom layer). The abstract's mistake was reflected in this page. Limninal (talk) 12:11, 8 August 2010 (UTC)

"The encryption method should not waste disk space"

Under the problem statement, I think this could be worded a bit differently: "the encryption method should not waste disk space". Expansion due to an authentication tag is not a waste, but its not desired in the "drop in" replacement use case.

Lack of an authentication tag is a known problem with this mode. If the threat model includes tampering, then the lack of authentication tag makes the mode unsuitable if a redunancy function is not provided. If the application is providing its own redundancy function for lots of small fields, a lot more space is "wasted" than would be for a single tag on an entire disk sector. --Jeffrey Walton 23:06, 14 September 2012 (UTC)

AEAD is getting some traction now, especially with Secure Boot intending to safeguard code against tampering and machines against duplication (so that disks can be removed & bruteforced somewhere else, etc.). dm-crypt on Linux is able to do some AEAD; there's also dm-integrity. The systemd guy argued for it a while ago. (One of the reasons for AEAD would be to protect filesystem from tampering -- a broken filesystem could still trigger broken behavior in the kernel driver. Linux assumes that mounting a filesystem implies some degree of trust, so...) --Artoria2e5 🌉 03:41, 4 September 2024 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 3 external links on Disk encryption theory. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added {{dead link}} tag to http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=rogaway.IN.&OS=IN/rogaway
• Added archive https://web.archive.org/web/20101024155616/http://siswg.net:80/index.php?option=com_content&task=view&id=38&Itemid=73 to https://siswg.net/index.php?option=com_content&task=view&id=38&Itemid=73
• Added archive https://web.archive.org/web/20060714161658/http://www.siswg.org:80/docs/KeyBackup-10-04-2004.pdf to http://www.siswg.org/docs/KeyBackup-10-04-2004.pdf
• Added archive https://web.archive.org/web/20050128092039/http://www.siswg.org:80/docs/EME-AES-03-22-2004.pdf to http://www.siswg.org/docs/EME-AES-03-22-2004.pdf

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

N An editor has determined that the edit contains an error somewhere. Please follow the instructions below and mark the |checked= to true

• 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.—InternetArchiveBot (Report bug) 22:34, 13 December 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 4 external links on Disk encryption theory. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Corrected formatting/usage for http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=rogaway.IN.&OS=IN%2Frogaway
• Corrected formatting/usage for http://www.siswg.org/docs/KeyBackup-10-04-2004.pdf
• Corrected formatting/usage for http://www.siswg.org/docs/EME-AES-03-22-2004.pdf
• Added archive https://web.archive.org/web/20080514160137/http://citp.princeton.edu.nyud.net/pub/coldboot.pdf to http://citp.princeton.edu.nyud.net/pub/coldboot.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

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.—InternetArchiveBot (Report bug) 09:54, 11 September 2017 (UTC)

"Disk encryption theory"? Honestly?

This article is broken.

Any reason why the material was broken out of block cipher modes and content was removed? Obviously, you can use any block cipher mode for disk encryption you prefer, but it might have advantages and disadvantages, e.g. when it comes to random access. This article gives only few info and no overview. I would say the article is completely worthless. --Ghettobuoy (talk) 03:08, 1 February 2019 (UTC)

IAPM mode never discussed

It makes little sense to have the first mention of IAPM mode occur in the patents section. Either devote part of the page to a discussion of IAPM mode, or eliminate the discussion of patents. Ghstark (talk) 01:06, 15 February 2020 (UTC)