This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||
|
Does the link to ipcores belong on this page or Disk encryption hardware? Kasperd 19:22, 3 September 2006 (UTC)
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)
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
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)
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
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)
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:
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:
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)
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
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
"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...
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
Btw, I guess we should seriously clean-up this talk page as well GBL 16:58, 26 November 2006 (UTC)
"...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)
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 nth 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)
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)
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)
While it is true that
what knowledge can be gathered from , as long as either one is unknown? 93.205.108.67 ( talk) 16:53, 29 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:
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:
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 was also
discussed on the dm-crypt mailing list. —Preceding
unsigned comment added by
Calestyo (
talk •
contribs) 21:43, 26 July 2010 (UTC)
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)
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)
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)
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:
{{
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/rogawayWhen you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{
Sourcecheck}}
).
An editor has determined that the edit contains an error somewhere. Please follow the instructions below and mark the |checked=
to true
Cheers.— InternetArchiveBot ( Report bug) 22:34, 13 December 2016 (UTC)
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:
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: 18 January 2022).
Cheers.— InternetArchiveBot ( Report bug) 09:54, 11 September 2017 (UTC)
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)
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)
This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||
|
Does the link to ipcores belong on this page or Disk encryption hardware? Kasperd 19:22, 3 September 2006 (UTC)
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)
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
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)
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
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)
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:
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:
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)
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
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
"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...
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
Btw, I guess we should seriously clean-up this talk page as well GBL 16:58, 26 November 2006 (UTC)
"...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)
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 nth 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)
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)
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)
While it is true that
what knowledge can be gathered from , as long as either one is unknown? 93.205.108.67 ( talk) 16:53, 29 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:
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:
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 was also
discussed on the dm-crypt mailing list. —Preceding
unsigned comment added by
Calestyo (
talk •
contribs) 21:43, 26 July 2010 (UTC)
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)
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)
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)
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:
{{
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/rogawayWhen you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{
Sourcecheck}}
).
An editor has determined that the edit contains an error somewhere. Please follow the instructions below and mark the |checked=
to true
Cheers.— InternetArchiveBot ( Report bug) 22:34, 13 December 2016 (UTC)
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:
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: 18 January 2022).
Cheers.— InternetArchiveBot ( Report bug) 09:54, 11 September 2017 (UTC)
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)
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)