Talk:Disk encryption theory

message: Does the link to ipcores belong on this page or Disk encryption hardware? Kasperd 19:22, 3 September 2006 (UTC)
replies: text: 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)
replies: text:  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)
thread_title: External links

message: 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)
replies: text: done GBL 11:31, 18 January 2006 (UTC)
thread_title: Integrity

message: The math in the treatment of LRW uses the symbol <B>F</B> 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)
replies: text:  Fixed. GBL 13:21, 8 February 2006 (UTC)
replies: text:  Not fixed.  Perhaps the fix was reverted? 195.249.104.29 (talk) 11:35, 26 September 2019 (UTC)
thread_title:  What is "F"? 

message: "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)
thread_title:  Simple approaches 

message: 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)
thread_title: "Waste disk space"

message: 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)
replies: text: 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 270 bytes. The data unit size for a typical filesystem is between 512 and 64536 bytes only (29/216).93.205.111.251 (talk) 15:37, 2 April 2010 (UTC)
thread_title:  Issues with XTS 

message: 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)
thread_title:  CMC algorithm confusion 

message: 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)
thread_title:  "The encryption method should not waste disk space" 

message: Hello fellow Wikipedians,
I have just modified  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  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 ).
Cheers.—InternetArchiveBot (Report bug) 22:34, 13 December 2016 (UTC)
thread_title:  External links modified 

message: 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.
Cheers.—InternetArchiveBot (Report bug) 09:54, 11 September 2017 (UTC)
thread_title:  External links modified 

message: 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)
thread_title:  "Disk encryption theory"? Honestly? 

message: 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)
thread_title:  IAPM mode never discussed