iBet uBet web content aggregator. Adding the entire web to your favor.
iBet uBet web content aggregator. Adding the entire web to your favor.



Link to original content: http://en.wikipedia.org/wiki/Talk:IEEE_P1619
Talk:IEEE P1619 - Wikipedia Jump to content

Talk:IEEE P1619

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

LRW issue

[edit]

The attacks on LRW seem to be mentioned only on the IEEE P1619 mailing list, so I labelled the section "Original Research". Has this been discussed in any peer-reviewed journal? Also, it seems to be disputed that the attack is even possible if the underlying block cipher has an adequate block length and key size [1]. Then the attack wouldn't be on LRW, but on the underlying block cipher: if AES is used, the attack would be completely infeasible.

I don't think that's really a fair change; it isn't original research - that most members of SISWG have concerns is significant, and it is referenced by the link to the SISWG mailing list. XEX does replace LRW in the latest P1619 draft FireDemon 09:25, 15 September 2007 (UTC)[reply]
I agree that it is significant that most members of SISWG have concerns. However, these concerns are being stated as facts: "An attacker can derive the LRW tweak key when a cipher in LRW mode encrypts data that contains the tweak key" and "Collisions in the output of the cipher can lead to discovery of 1/2 of the tweak key". The first statement assumes that a collision occurs, otherwise the attack doesn't work, but for that about 256 exabytes of data is needed. The second statement assumes that the tweak key is "low-entropy", but that assumption violates the definition of a cryptographic key. Also, LRW is not replaced by Rogaway's XEX, but by "XEX TCB CTS". My issues are: Rogaway's XEX security proof doesn't apply to "XEX TCB CTS" as the tweak values are repeated after about 2^64 instead of 2^128 blocks. TCB or "Tweaked Codebook Mode" is a new invention, it does not appear anywhere outside the IEEE P1619 mailing list, this should be mentioned. In short: my problem is not with the events in the history of P1619, but with the cryptographic claims made in this article. From Wikipedia's Original Research policy: "The threshold for inclusion in Wikipedia is verifiability, not truth. This policy and the verifiability policy reinforce each other by requiring that only assertions, theories, opinions, and arguments that have already been published in a reliable source may be used in Wikipedia." A mailinglist is not a reliable source for the cryptographic claims made in this article. I'm going to put the OR warning back until a reference to a reliable source is added for these cryptographic claims. —Preceding unsigned comment added by 193.190.253.144 (talk) 10:32, 15 September 2007 (UTC)[reply]
I think that the first problem (K2 followed by zeroes in the data stream) actually does not require any collisions to reveal the K2 - it is there in plain view, just slightly obfuscated. One only needs to know where to look - which is not that hard in a swap file. Dimawik 05:30, 19 September 2007 (UTC)[reply]
I would say that the contributors to the list (and its readers) included a quite significant portion of the active cryptographic community. The discussion and its conclusion have been thus much better peer-reviewed than an average article in a magazine. The fact that the discussion had never been printed on good paper stock by Springer does not make the result any less scientific. After all, one the most recent significant mathematical results has also not been published on paper. Dimawik 06:33, 17 September 2007 (UTC)[reply]
On the Poincaré conjecture page you link to, it says: "Huai-Dong Cao and Xi-Ping Zhu published a paper in the June 2006 issue of the Asian Journal of Mathematics giving a complete proof of the Poincaré and geometrization conjectures, in which they used some earlier work by Kleiner and Lott." That means the full proof was in fact printed on "good paper stock" and peer-reviewed by all 28 people of the editorial board. But that is not my point. The Wikipedia guidelines on Verifiability do not consider a mailinglist to be a reliable source. 193.190.253.144 22:28, 18 September 2007 (UTC)[reply]
I think you have misunderstood me as speaking against the peer review. Nobody sane can be against the peer review; after all, this is one of the foundations of the science as we know it. But the peer review does not require for the result to be printed on paper by a respected publisher. As long as a discussion has been held among esteemed professionals in the field and they reached an agreement, the media used for the discussion is irrelevant. Original papers by Perelman were published in arXiv, and were certainly much better reviewed than the "good paper stock" publications you quote. Same is true for the facts in this article. The readers and contributors of the P1619 mailing list included more professionals in the field than a typical editorial board of an IEEE publication. Therefore, in this particular case I see no reason to doubt the outcome of the discussion. And no, the guidelines article you have referenced does not discourage using the mailing lists as a source. Dimawik 05:20, 19 September 2007 (UTC)[reply]
And what is the outcome of the discussion? Several people have pointed out that Matt Ball's attack is completely infeasible[2]. The attack assumes that you can find collisions in the output of AES (you need about 256 exabytes of data for that), and do an exhaustive key search to detect such a collision in the output of LRW (you need to try 2^128 keys)[3]. Matt Ball claims that an exhaustive key search is possible because a 128 bit key is actually only has about 2^24 possible values if it's an ASCII string. This goes against the definition of a cryptographic key, which is picked at random from the entire keyspace. He does not explain how he would actually find such a collision. 193.190.253.144 17:07, 19 September 2007 (UTC)[reply]
I might be wrong, but my understanding of the discussion is that writing the K2 to disk twice followed by a string of zeros is fatal without any collisions and requires just a few XORs to recover the key [4]. Since the swap file in a secure system needs to be encrypted, this situation is very hard to prevent, and this has been the main reason for dropping the LRW in P1619. That said, my suggestion to add the sunny side of the story to the text of an article, keep the links to the mail list and remove the "fact" request. —Preceding unsigned comment added by Dimawik (talkcontribs) 18:36, 19 September 2007 (UTC)[reply]
You're right. That last link [5] explained it all to me. I've tried to clarify the "LRW issue" a bit, but feel free to make further improvements to that section. A few remarks though. You don't need to write the tweak key K2 twice, only once is enough. The plaintext K2||0n or 0n||K2 creates the same input for the AES function, so there is in fact a collision. There seems to be an easy way to prevent this attack: allocate a larger block of memory, fill it with random data and put K2 somewhere in the middle. —Preceding unsigned comment added by 193.190.253.144 (talk) 20:41, 19 September 2007 (UTC)[reply]

Out of date?

[edit]

If the standard was ever approved, then the "P" should be taken off. It indicates "proposed" standards only. If not, then article should be written in past tense since it talks about things that happened five years in the past. W Nowicki (talk) 17:20, 31 August 2013 (UTC)[reply]


[edit]

The link in the section "has been replaced by the XEX-AES tweakable block cipher in P1619.0 Draft 7" is broken.