Jump to content

Talk:XSL attack

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Former featured article candidateXSL attack is a former featured article candidate. Please view the links under Article milestones below to see why the nomination was archived. For older candidates, please check the archive.
Article milestones
DateProcessResult
July 26, 2004Featured article candidateNot promoted

old comments

[edit]

Specifically, here is the discussion of the article during the FAC process:


Self-nomination. Article about an attack that may (or may not) herald an early retirement for the Advanced Encryption Standard (and not about XML stylesheets...) — Matt 21:10, 18 Jul 2004 (UTC)

  • Object on the basis that it's too hard to understand. Links are great, but you need to explain some terms right off the bat. Even the lead section is unclear to those without prior/specialized knowledge. Exploding Boy 02:11, Jul 19, 2004 (UTC)
    • Agreed, but I think it can be fixed to the point that it is approachable enough to the average, well educated reader. That is the best an article on such a techical topic can hope for. Specifically I defined some previously un-defined terms in the intro. I think we'll have to put up with a longer than usual intro for an article this technical, in order to make it readable by more people. After the intro, the article could stand to have an even more specific discussion of the method itself. An example would be devine, but I would not object for the lack of it. - Taxman 17:42, Jul 19, 2004 (UTC)
    • Let's see if we can improve it. I think this is a difficult question that pops up in a lot of technical articles; exactly how much technical know-how can you assume? For example, in semigroup, you can probably get away with presuming that your reader knows what a group (mathematics) is; otherwise, they would be unlikely to be reading the article in the first place. If you don't make at least some assumptions, then you end up with hundreds of articles all burdened with duplicated definitions (and it makes it less useful for a specialist); on the other hand, if you define too little, then it becomes incomprehensible to a non-specialist. Personally, I think it's a good idea to make the lead section especially accessible, and to bring out the general relevance of the topic in a understandable-to-all way, but it's less necessary in the nuts-and-bolts parts of the article. — Matt 20:20, 19 Jul 2004 (UTC)
  • Support. This is an inherently complex topic not reducible to simplicity in any potentially feasible WP article. This property is not a bar (eg, Attack on Pearl Harbor whose complexity is political and historical, not technical, but which is on the featured list even so despite its length). This article is clearly written and sensibly structured about obscure material; this alone qualifies it as a good WP article in my opinion. As a bonus, the topic is an important (if technical) one in a field of considerable relevance to most everyone. DRM relies on such techniques and will, it appears, be ubiquitous shortly. I note that the writing is not 'sparkling' in a literary sense, but this is not, I feel, relevant for such topics and has not been required for past WP featured articles. ww 14:06, 19 Jul 2004 (UTC)
  • (Not a vote yet) Matt, maybe this sounds ridiculous, but do you think it would be possible to show how the XSL attack works by means of a simple example? Of course not with a 128-bit block cypher, but with a much smaller one? If that would seem possible, I think it would greatly improve the accessibility of the article. Jeronimo 17:58, 19 Jul 2004 (UTC)
    • I've taken a class in crypto and I still found this article a bit complex. To a layman, I can see how it could be Byzantine. I think an example would help a lot. →Raul654 20:19, Jul 25, 2004 (UTC)
      • OK, fair comment; I can try and hack together an example, but I can't remember the details, only the gist, of the attack, so I'd have to wade through the relevant papers again. That could take a while (even Bruce Schneier notes that they're "dense and hard to understand"!), so I'm happy to let the nomination fail for now. — Matt 02:12, 26 Jul 2004 (UTC)


This article annoys me. It seems to be a few paragraphs of vague "XSL may work by representing block cyphers as polynomials" and a few pages of solidly sourced "no, it really DOESN'T ruin AES." I suspect it needs more and easier to understand descriptions of how it (doesn't) work(s). PianoSpleen 12:16, 12 May 2007 (UTC)[reply]

The algorithm is just "hot air" and because of this doesn't deserve an in-depth description. I would suggest a kind of history of the "attack" and an explanation why it was subject to discussion in cryptography. anonymous 20:34 31 Jan 2008 —Preceding unsigned comment added by 88.74.130.53 (talk) 19:34, 31 January 2008 (UTC)[reply]

Language in Application to block ciphers section

[edit]

There are a few sentences in here that are unencyclopedic:

Most professional cryptographers think that Courtois' answer is just it: fun and nothing more.

Like many modern cryptanalytic results, it would be a so-called "certificational weakness"

Furthermore, the section is written in a somewhat derisive tone and seems to be biased towards the "XSL is a load of rubbish" side. The following sentence is poorly written and seems almost mocking.

Like many modern cryptanalytic results, it would be a so-called "certificational weakness"

87.113.25.201 (talk) 15:56, 29 April 2009 (UTC)[reply]

Toli-Zanoni reference

[edit]

The article refers to a paper by Toli and Zanoni.

In a paper in the AES 4 Conference (Lecture Notes in Computer Science 3373), Toli and Zanoni proved that the work of Murphy and Robshaw was flawed.

First, the article does not include the Toli and Zanoni paper in its references. More importantly, the referenced paper expands on the work of Murphy and Robshaw (the embedding of AES in BES) but does not claim to refute any of their results. This comment in the article should be explained or removed.

--Stevemit (talk) 20:33, 17 January 2012 (UTC)[reply]