imported>Hayford Peirce |
imported>John Stephenson |
| (13 intermediate revisions by 7 users not shown) |
| Line 1: |
Line 1: |
| {{subpages}} | | {{subpages}} |
|
| |
|
| == Questions for editors == | | ==APPROVED [http://en.citizendium.org/wiki?title=Block_cipher&oldid=100606167 Version 1.0]== |
| I'm not sure how large this page should get. Things like the Feistel structure and cipher modes might be explained here, but my guess is they need their own pages. Some of the design considerations might be covered here, or in [[cipher]], [[cryptography]], or [[cryptology]], perhaps even in articles on the attacks they prevent. My guess is those should be here, at least in outline, with details under specific attacks. Comment, anyone? [[User:Sandy Harris|Sandy Harris]] 09:24, 7 September 2008 (CDT)
| |
|
| |
|
| : I guess I answered my own question there. It is now > 60 K bytes :-) [[User:Sandy Harris|Sandy Harris]] 04:40, 29 October 2008 (UTC)
| | <div class="usermessage plainlinks">Discussion for [http://en.citizendium.org/wiki?title=Block_cipher&oldid=100606167 Version 1.0] stopped here. Please continue further discussion under this break. </div> |
|
| |
|
| ::There's nothing wrong with pulling together a high-level article with pointers to things in draft, and get approval on that. I'm trying to do that with DNS; there's a shortage of editors but maybe it will get done. I got it to a point where I felt it was internally consistent, and, while it's not a requirement, well illustrated. At that point, I could feel comfortable not worrying about it and going to the more detailed articles. Software and articles are alike: sometimes you need to ship Version 1. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 05:05, 29 October 2008 (UTC) | | :I don't see that Howard actually saw [http://en.citizendium.org/wiki?title=Block_cipher%2FDraft&diff=100606872&oldid=100586032 these edits] or endorsed them. Peter did, though. Howard, are you okay with this those changes? [[User:D. Matt Innis|D. Matt Innis]] 22:16, 1 December 2009 (UTC) |
|
| |
|
| I'm now fairly happy with [[Block_cipher#Principles_and_techniques]]; I think all that needs adding there is more detail on S-boxes. Do that, and flesh out various later sections and we should have a decent article. | | ::Howard had approved a version through a couple of days ago, and that's the one I was *going* to OK, not a more recent one that had about a single space added to it. Then I saw today that the latest version had been updated by the editors so that it was the most recent one. So that's the one I approved. How am I supposed to figure out that, apparently, Peter approved the later one but not Howard. Where's Joe the Approvals Manager? Why, for once, can't people just give me a nice clean version to approve!!!??? [[User:Hayford Peirce|Hayford Peirce]] 22:31, 1 December 2009 (UTC) |
|
| |
|
| Various questions arise, though. Most of them could also be asked about [[Stream cipher]]. First of course, criticism is needed; what have I missed or got wrong? Contributions would also be great.
| | ::: Sorry, I thought I did it correctly ... Wasn't I supposed to join in, or isn't it o.k. to update to a more recent version? [[User:Peter Schmitt|Peter Schmitt]] 23:04, 1 December 2009 (UTC) |
|
| |
|
| What goes here and what in related articles? Mostly, I'm just writing it here if the related article does not yet exist; if we end up with too much detail for here, we can always start the related article by moving the excess text. I'm trying to just cover the basics here, but there are a lot of basics.
| | :::: No, Peter, you did fine - exactly as you were supposed to do. In fact, with your endorsement, it's still a single editor approval, it's just that Howard's name is on it, too. However, the last version he apparently saw was on November 24 (17 edits earlier). Therefore, he either needed to show he approved those edits by making a statement to that effect here on the talk page. If he doesn't approve, the approval can still stand because you approved this version. So, really it's just a matter of whether Howard wants his name on this same version. All he has to do is let us know. [[User:D. Matt Innis|D. Matt Innis]] 23:44, 1 December 2009 (UTC) |
|
| |
|
| In some cases, it is not clear what a related article should be called; "MARS", "Serpent" and "Hasty Pudding" are all names of ciphers. Should the article be [[Serpent cipher]], [[Serpent (cryptography)]] or what? IBM call theirs "MARS", all uppercase [http://domino.research.ibm.com/comm/research_projects.nsf/pages/security.mars.html]; what do we call an article? GOST is an abbreviation of something-or-other in Russian, and there's both a GOST cipher and a GOST hash.
| | :::::I can still go with the approved version. As the fates have it, I have a one-word correction that should have been applied earlier -- not an outright error but a clarification. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 00:02, 2 December 2009 (UTC) |
|
| |
|
| How should links be set up? Various other articles have [[Feistel cipher]] as a link, but that is not written yet. Change those to point to [[Block_cipher#Feistel_structure]]? Move or copy my text to [[Feistel cipher]]? Or (my preference) create [[Feistel cipher]] as a redirect pointing into this article?
| | :::::: Good news. All's well that ends well. Let's leave this approved version as is and you guys can work out your new one word correction on the draft and call us back if you need it to go into the Approved version. [[User:D. Matt Innis|D. Matt Innis]] 00:11, 2 December 2009 (UTC) |
| | |
| : Did that. Still wonder about policy, though. [[User:Sandy Harris|Sandy Harris]] 10:01, 26 October 2008 (UTC)
| |
| | |
| ::I can't tell you what GOST actually stands for in Russian, but it is the abbreviation for their national standards body, like BSI or ANSI. | |
| | |
| ::Not only is there no real policy, but there are both several forum discussions, and also quite a bit of material on talk pages with Chris Day, who develops the move templates. | |
| | |
| ::: I don't use the forums. See [[User_talk:Sandy_Harris#forums]].
| |
| | |
| ::Here is a suggestion only; I'm still developing my ideas. As you know, my style is more high-level outline first. What I'm starting to do, however, is implement even stubby headings in that as article. I usually put a big bold black centered warning on the article and talk page that the name is in flux; '''PLEASE DO NOT CREATE METADATA'''. It's relatively simple to move articles and talk pages, but once metadata gets involved, there are still some non-intuitive, if not buggy things, about cluster moves.
| |
| | |
| ::I was starting to do that last night, on some ballistic missile defense related items. Whenever a radar or an old project was mentioned, I was much more eager to create stubs. Now, there are some high-level articles already, and there are related articles templates. Related articles leave me with mixed feelings, depending if I can be content with having them mostly red; in some cases, I sin and don't do the definition but just some quick text on the lines. Definitions are some of the trickier things to move around. Definition-based R-templates really are useful for disambiguation and more stable related articles, but they are very hard to move, especially if there is metadata.
| |
| | |
| ::Does that, at all, help? I'm still caffeine-depleted and may be more coherent in an hour or two
| |
| | |
| [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 14:00, 29 October 2008 (UTC)
| |
| | |
| ::: Helps some Thanks. [[User:Sandy Harris|Sandy Harris]] 14:28, 29 October 2008 (UTC)
| |
| | |
| How should links work within an article? I've consistently done it with internal links; every link to "DES" is to "#DES", the article's DES section, except for a link in that section pointing out to the main DES article. This seems right to me; keep the reader here, at the same level of detail, unless he actually asks for more. What do editors thnk, and is there a policy on this? [[User:Sandy Harris|Sandy Harris]] 06:11, 25 October 2008 (UTC)
| |
| | |
| :Good approach. I know you have forum access problems; there are a number of discussions on just what to do. If you do have proposals, let Chris Day know, since he is the Builder of Templates. Having internal wikilinks makes it very easy to change to external links with no user impact.
| |
| | |
| :While there is less a strict policy and more a judgment call, do consider the <nowiki>{{main}} and {{seealso}}</nowiki> to put at the tops of articles and headings. Off the top of my head, block cipher might have cipher or cryptography as main. I can't honestly say if seealso would better fit alternatives such as stream ciphers, or complementary issues in information security. Seealso doesn't feel right, however, for subarticles. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 16:02, 29 October 2008 (UTC)
| |
| | |
| [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 16:02, 29 October 2008 (UTC)
| |
|
| |
|
| | :::::::Well, that's last time I will ever approve or reapprove an article that Joe the Manager hasn't specifically told me to. [[User:Hayford Peirce|Hayford Peirce]] 00:36, 2 December 2009 (UTC) |
|
| |
|
| | ::::::::Hehe, this one is no big deal. Just be most careful with the controversial ones :D [[User:D. Matt Innis|D. Matt Innis]] 00:54, 2 December 2009 (UTC) |
|
| |
|
| | :::::::::Yes, it is a big deal -- it means that it's taken two Cops to do what one should have been able to do. If I can't do it correctly the first time, then I won't do it again. And I can't do it correctly if Joe the Manager doesn't tell me *explicitly* precisely which version to approve. As I said above, and I mean it seriously, if I don't get a go-ahead from Joe in the future on an approval or re-approval, I simply won't do them. [[User:Hayford Peirce|Hayford Peirce]] 03:08, 2 December 2009 (UTC) |
|
| |
|
| | ===Questions=== |
| | Howard, what's your one-word change? We can make it on the draft? Also, is it time to archive most of the talk page? [[User:Sandy Harris|Sandy Harris]] |
|
| |
|
| | :Add to "In theory, any '''block''' cipher can be broken by a brute force attack"...so the statement doesn't conflict with one-time pads. Yes, it's time to archive. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 03:47, 2 December 2009 (UTC) |
| | :: I made it "In theory, any cipher '''except a [[one-time pad]]''' can be broken by a brute force attack", since stream ciphers are also vulnerable. |
| | :: Also did the archiving. [[User:Sandy Harris|Sandy Harris]] 03:26, 27 November 2010 (UTC) |
|
| |
|
| | == Re-approve? == |
|
| |
|
| | The current approved version is from 2009. I have made a number of [http://en.citizendium.org/wiki?title=Block_cipher%2FDraft&action=historysubmit&diff=100803401&oldid=100606872 changes since then]. I'd say it needs re-approval, and is ready for that. |
|
| |
|
| == Organization of "Principles and techniques" ==
| |
|
| |
|
| I've never claimed to be an expert on crypto algorithms, but, when I looked at the introductory paragraph, it mentioned a number of specialized terms, and then shifted more and more into detail. Most of the principles discussed here for block ciphers also apply to other cryptographic primitives. '''Key size''' is critical in stream ciphers as well as block ciphers. Hash algorithms generally use ''iteration'' and require avalanche. In both hashes and stream ciphers, '''non-linearity''' is an important design criterion, and '''s-boxes''' can be used in either.
| | == Approval Process: {{ApprovalProcess|certify}} == |
|
| |
|
| In the introductory text, you could add a few sentences on each of the topics. As it's organized now, a reader who didn't know about S-boxes would have to go through a lot of material to get to the discussion. At a minimum, have internal wikilinks to the detailed definitions.
| | ''Call for review: ''[[User:Sandy Harris|Sandy Harris]] 03:42, 8 June 2012 (UTC) |
|
| |
|
| : I moved thing so e.g. the comment on stream ciphers also needing non-linearity now comes at the end of the non-linearity section. [[User:Sandy Harris|Sandy Harris]] 18:42, 26 October 2008 (UTC) | | ''Call for Approval: ''[[User:Anthony.Sebastian|Anthony.Sebastian]] 01:59, 18 June 2012 (UTC) |
|
| |
|
| Try to carry words or phrases through the text. For example, if you mention iteration in the introduction, don't name the section about it "iterated block ciphers." Name it "iteration". Consider another level of subheading, as, for example, tradeoffs and cryptographic vulnerabilites.
| | ''Approval Notice: ''[[User:Anthony.Sebastian|Anthony.Sebastian]] 03:55, 6 September 2012 (UTC) |
|
| |
|
| Perhaps you may want to move at least some of "nonlinearity" earlier into the section. Isn't it the rationale for most of these things?
| | ''Certification of Approval: ''[[User:Anthony.Sebastian|Anthony.Sebastian]] 03:56, 18 September 2012 (UTC) |
|
| |
|
| "Substitution-permutation networks" pops up with no introduction. Should it be a subsection of nonlinearity? Indeed, it almost looks like S-boxes could be a subsection of S-P networks.
| | ---- |
| | ''Please discuss the article below, [[{{BASEPAGENAME}}/Approval]] is for brief official referee's only!'' |
| | === Comments === |
|
| |
|
| The justification for Feistel methods, which appears to be avalanche, doesn't occur until the end of that section. What about making Feistel a subsection of avalanche, and then moving, to the beginning of the Feistel material, that it is a means to achieve avalanche.
| | Unfortunately, any time I've had for Citizendium has been used up by Management Council activities. Realistically, I am not going to have time to review this, or any other articles, for approval in the near future. I'm sorry, life has been pretty complicated lately (death in the family) and this is the situation, which I did not anticipate.[[User:Pat Palmer|Pat Palmer]] |
|
| |
|
| These are some general ideas for flow; you can probably see others. Again, think of the relatively new reader who is not familiar with terms. When I coauthored a textbook for the first time, the lead author beat me repeatedly with a clue-by-four until I grasped the essential clue: when a concept is first introduced, it needs at least some definition within, at most, the next few sentences. I learned that when I couldn't easily define something at one hierarchical level of writing, it was a cosmic message that the concept belonged at a lower level, after the foundations were developed. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 17:58, 26 October 2008 (UTC)
| | : No rush. This one is a long complex article on an important topic. We should take the time to get it right and we have time since there's an earlier approved version in place. |
| | | : There are several new computer editors. Would any of them care to comment here? |
| : Thinking. Will think & look more.
| | : It does need more eyes. The writing is almost entirely mine, and only one editor (no longer here) was actively involved during development, though others were during approval. [[User:Sandy Harris|Sandy Harris]] 05:40, 8 June 2012 (UTC) |
| | |
| : However, the order I've got was fairly carefully worked out. e.g. "Iterated block ciphers" needs to be first because it explains terms like "round" without which SP-networks, Feistel and Avalanche cannot be explained. Avalanche before the other two because it is one criterion for evaluating them. I put non-linearity late because it is complicated and leads directly to S-boxes, and deliberately did not explain S-boxes under SP-networks (though there's a mention & link) because they are a more general mechanism. [[User:Sandy Harris|Sandy Harris]] 18:42, 26 October 2008 (UTC)
| |
| | |
| ::Good observation. That would suggest that "round", perhaps, should be a subsection. Any time you find something that forms a foundation for understanding another process. Once you explain round, there's absolutely nothing wrong, and much right, with saying "the idea of a round is the base for additional mechanisms described below, such as SP-networks, Feistel and Avalanche." [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 18:55, 26 October 2008 (UTC)
| |
| | |
| == Safe and unsafe ==
| |
| | |
| My main point here probably belongs in [[cryptography]] or even [[information security]], but there needs to be perspective on what it means to be safe or unsafe. I completely agree that DES is not appropriate for anything that has to remain secure for even days, or has to protect any substantial body of data. Take something like a stock buy order with a time limit — it needs protection while the trader is placing the order with a fixed price authorization, but if he loses, the information has no particular value. If the order gave the trader a range of acceptable prices, and the trader could buy at less than the maximum, those orders become more sensitive, because they could reveal the overall valuation strategy of the buyer.
| |
| | |
| A military COMSEC principle is often misstated. If you send a firing order to artillery, and they will kill the target before the target could move even if fully warned, in principle, it would make no difference if it were sent in the clear. If, however, the enemy could collect a series of messages and infer things about your doctrine, then those messages might need much more protection.
| |
| | |
| There are special cases of protection being too much. I found some diaries of mine from age 13, and I remember using Playfair on the encrypted sections. After a fair bit of computer time, I concluded I didn't know how to use Playfair at the time, and came up with a one-way system. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 21:30, 26 October 2008 (UTC)
| |
| | |
| == Move modes? ==
| |
| I wonder about moving the section on modes of operation out to its own article. That's not directly related to block cipher design, which is enough to cover here. It is a usage consideration, like proper re-keying. It needs mention and a link here, but details can be elsewhere. [[User:Sandy Harris|Sandy Harris]] 10:09, 27 October 2008 (UTC)
| |
| | |
| : Would it move to a new separate article, perhaps [[Block cipher modes]]? Or to a sub-topic, perhaps [[Block cipher/Modes of operation]]? If the latter, how do I do that? [[User:Sandy Harris|Sandy Harris]] 10:34, 27 October 2008 (UTC)
| |
| | |
| :: Did that, using [[Block cipher modes of operation]] which makes sense and is what Wikipedia uses. [[User:Sandy Harris|Sandy Harris]] 09:57, 29 October 2008 (UTC)
| |
| | |
| Related to that, I'd like to insert a new section "High-level considerations" or "The role of block ciphers" or some such, showing a bit about the context where block ciphers are used. Mention key management issues, public key & DH as solutions, re-keying, mode of operation, side-channel, need for authentication .., No detail on any of those, just a bit on the principle & a wikilink. Make the point that secure components are necessary for secure systems, but not sufficient. All before we start on block cipher details with "principles & techniques". [[User:Sandy Harris|Sandy Harris]] 10:27, 27 October 2008 (UTC)
| |
| | |
| ::While I recognize PKI and ECB are different things at different levels of detail, it really wouldn't hurt to have a high-level article, perhaps initially branching from [[Cryptography]] on [[Cryptographic key management]]? ("Management" is the most common term, but I notice that many people think key creation is somewhere else). ECB could be covered at different levels of detail in different places.
| |
| | |
| ::Keys, of course, aren't limited to block ciphers. The pure management piece can cover stream ciphers, all the way down to manual systems. Smith, in ''Internet Cryptography'', has an excellent practical section on the secure handling of keys (KEK, perhaps). There's a wide range of military key loading devices, which blur into things that are more authentication token (e.g., the physical Crypto Ignition Key that looks like a thick conventional key). (makes mental note more about needing introductory authentication in [[information security]], high-level authentication article that covers things like [[biometrics]], multiple person authentication (e.g., dual key), etc.).
| |
| | |
| ::Sandy, I'm deliberately making suggestions here rather than in the text. I was reminded that I can't approve an article if I've made any substantive edits to it. Also, I think we work together better this way. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 14:44, 27 October 2008 (UTC)
| |
| | |
| == Miscellany ==
| |
| | |
| Down at the bottom, there's a red reference to [[pseudorandom number generator]]. Even if the sentence structure means you want the link to read something else, such as PRNG, remember that you can link to a subhead, such as <nowiki>[[Random number#pseudorandom number generator|PRNG]]</nowiki>.
| |
| | |
| Just as a guideline that I don't think violates editor status, I started a Related Articles subpage. You might want to clone it to some other articles.
| |
| | |
| It is useful to have definitions for important terms within articles, since without definitions, Related Pages and Disambiguation Pages don't work well. Unfortunately, there isn't a really clean way to have a definition-only of something that is part of a larger article, which makes searches inelegant. This is a long-running CZ issue: could there be an "approved short article" that, by its nature, ''is'' a definition and doesn't carry all the metadata, and especially not the definition subpage, of a regular article. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 15:05, 27 October 2008 (UTC)
| |
| | |
| == External attacks ==
| |
| | |
| As you suggest, some of this is, or will be, covered elsewhere. See, for example, [[communications intelligence#acoustic cryptanalysis]].
| |
| | |
| From wetware memory, the relatively little-known Federal Standard 1027, issued along with the DES algorithm specification, which was both a Federal Information Processing Standard and a Federal Standard, warned against timing attacks. 1027 was public, written by NSA, and addressed the physical security of devices in which DES was implemented.
| |
| | |
| Also, see [[Radiofrequency MASINT#Unintentional Radiation MASINT]].
| |
| | |
| [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 01:43, 29 October 2008 (UTC)
| |
| | |
| : Yes, much of this really belongs elsewhere, in particular a lot of [[Block_cipher#Context]] should be in higher level articles because it is not specific to block ciphers. I think [[hybrid cryptosystem]]s really need their own article, covering how each primitive contributes and how they can be put together. Some of [[Block_cipher#The_AES_generation]] should probably be in a separate article on the [[AES contest]]. Some of the more detailed descriptions of ciphers might be moved to articles specific to those ciphers.
| |
| | |
| : For now, though, I'm just trying to get it written. If I know of good coverage elsewhere, give an overview here and link to the other. If I don't, just write it here. Later on, we can worry about what goes where, move or copy text as appropriate. For a few things, I'm writing here because I just want to take a different slant than the text elsewhere gives. We can worry about that later too; both may be correct for different contexts, or perhaps we need some debate and/or compromise; those will be easier with text in hand. [[User:Sandy Harris|Sandy Harris]] 04:30, 29 October 2008 (UTC)
| |
| | |
| == Are we there yet? ==
| |
| | |
| I think it is done, ready for approval. Not finished or perfect, but ready.
| |
| | |
| One test that is absolutely necessary, though, is to have some people that do not know the field read through it and see if it — especially the "concepts & techniques" section — makes sense to them. I'm convinced it should, but don't actually know if it does. [[User:Sandy Harris|Sandy Harris]] 09:55, 29 October 2008 (UTC)
| |
| | |
| :I'm still thinking on it. Much of the "context" section, I believe, would better move to more general articles. As a start, I created [[key (cryptographic)]] and a first-cut definition for [[key management (cryptographic)]].
| |
| | |
| :: I agree; only a sentence or two & a link or two per secton are actually needed here. [[User:Sandy Harris|Sandy Harris]] 01:42, 31 October 2008 (UTC)
| |
| | |
| :As far as concepts & techniques, avoid the tendency for things that are really not specific to block ciphers, such as key length. Some terminology, however, does need context. '''Whitening''', for example, seems to come out as unique to block ciphers. It is a separate problem that the term gives me an image of a crypto device with a key loader and a funnel for bleach. Seriously, whitening appears to be akin to cipher feedback in DES, but really going back to the historical idea of '''autokey'''.
| |
| | |
| :: Key length is not specific to block ciphers, but it is critically important for them and they are the best-known application of the principle. Also, it has implications for the rest of the design — build your cipher so that no attack is better than brute force, then make brute force (hence all others) impossible with a big key. [[User:Sandy Harris|Sandy Harris]] 01:42, 31 October 2008 (UTC)
| |
| | |
| :While I'm not sure exactly how to rearrange things, the second paragraph of "avalanche" is very well written, and I think some of it needs to move to the section start. Also, the first paragraph is literally hard to read, which I think would improve if things such as n+x became <nowiki><math>n+x</math></nowiki>.
| |
| | |
| :: I re-arranged & re-wrote a bit.
| |
| | |
| :The first part of nonlinearity also seems to belong in more general material; a brief introduction is appropriate, but assume I already know of the principle of nonlinearity and that what I want to understand are the nonlinearization techniques peculiar to block ciphers.
| |
| | |
| :: I think the explanation of how to break a linear block cipher is relevant, and specific to block ciphers. The next section covers non-linearisation techniques. [[User:Sandy Harris|Sandy Harris]] 01:42, 31 October 2008 (UTC)
| |
| | |
| :As a general rule, a single subhead under a higher heading should be merged or moved. "S-boxes as a model of other things" seems orphaned. For example, [[IDEA]] is mentioned, but hasn't been defined or used. Perhaps the IDEA-specific material from this section needs to move into the IDEA section.
| |
| | |
| :: I deleted the heading and shortened the text some; that's now one paragraph. [[User:Sandy Harris|Sandy Harris]] 01:42, 31 October 2008 (UTC)
| |
| | |
| :I'm not sure I'm ready to accept the common flat statement "DES is not secure". It is not secure for appreciable amounts of traffic that need an appreciable time of protection. For something such as a credit authorization transaction with frequent session keys and trusted timestamps, the period for which the information would be useful, and in which a miscreant might create false data, may be quite adequately protected by DES. Agreed that I wouldn't put DES chips into new devices if AES coprocessors are available.
| |
| | |
| :: I avoided a flat statement here, using things like "DES is now considered obsolete and has been replaced by AES" or "DES is no longer considered secure".
| |
| | |
| :: I consider a flat "DES is not secure" to be obviously correct, and to have been correct since at least the early 90s. Diffie and others said 56 bits was inadequate back in the 70s when DES was being standardized, However, if we're going to discuss those topics, it belongs in a historical article, not this one.
| |
| | |
| :: You appear to be subscribing to a fallacy which I attack elsewhere [http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/politics.html#shortkeys]. There is no good reason to use DES, or any other short key cipher, and has not been for years. [[User:Sandy Harris|Sandy Harris]] 01:42, 31 October 2008 (UTC)
| |
| | |
| :::I'm afraid I call the fallacy fallacious. :-) "Secure" is not an absolute. While I absolutely agree it would be insane to put DES into any new system, I also will defend that there are legacy systems in which there is no good reason to tear into a running system and change out short-key crypto in a low-threat environment. There are systems, where, after my initial noises of shock and dismay, urge the replacement activity take place 24/7.
| |
| | |
| :::Threat is also not an absolute. It involves many factors, including the intrinsic value of the information were it either disclosed, or, through falsified cryptographic authetication, had its integrity compromised. The time value of the information is significant, considering both the short-term value of a message, and any knowledge that can be derived from a long-term analysis of messages. NSA used to store warehouses full of Soviet intercepts that they hoped, someday, that they might decrypt, but they've been purging things that relate to things like the Warsaw Pact's plan to invade Western Europe, or generations-old weapons, or things for which the Russians will happily sell the equipment and documentation (onsite technical support available at extra charge). [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 03:34, 31 October 2008 (UTC)
| |
| | |
| :Some initial reactions; it's a matter of polishing and organizing. My sense is that from a pure readability standpoint, the details of each specific cipher belong in their own articles; if you are talking about a generation, it's visually useful to see the full list in one or two scrolls. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 17:15, 30 October 2008 (UTC)
| |
| | |
| == An aside of admiration... ==
| |
| | |
| People have been struggling to refer to this decade. The noughts?
| |
| | |
| "The AES Generation" has been echoing in my head since I read it, sort of like one of those TV commercial soundtracks that Will Not Die. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 01:53, 31 October 2008 (UTC)
| |
| | |
| :More seriously, the article gets better with every round of iteration (BAD Howard! BAD Howard!) I know it's frustrating to keep tweaking, and I respect that, as you put it, we have top-down and bottom-up styles.
| |
| | |
| :I am learning from this, and not just in algorithms. Some of our (positive if occasionally frustrating) interaction here have helped me deal with some completely unrelated editorial issues in CZ. It's too bad that you have the access problem with the Forums, but let me assure you that some of the "process" discussion we are having -- how best to have related articles, and maybe some new constructs -- to help users find materials -- are feeding into discussions. Believe me, I can go into the details of a routing or addressing algorithm and get lost in the topic.
| |
| | |
| :Sooner or later, one of the other Computers editors will get some cycles; I do have some articles that I think are ready for approval, with no one to approve (or critique). DNS, I think, is a case where I've found some balance between top-level and more detailed issues, and I hope that you will be commenting on the interactions of DNS as a limited DNSSEC PKI and a more general one for IPSec, as well as all the interactions of security and management with IPv6.
| |
| | |
| [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 14:34, 31 October 2008 (UTC)
| |
| | |
| == Hashes of various sorts ==
| |
| | |
| I created [[hash (disambiguation)]]. Looking through various articles by various people, we have both "cryptographic hash" and "hash (cryptographic)". Do you have a preference? Feel free to modify the disambigution page if you prefer the second, and perhaps you might put in a definition.
| |
| | |
| It's probably not a huge job to collect hash fragments (from the cooking standpoint,that's redundant), put them into one article, and massage it into a coherent article on the general technique. That would point up, at least, to integrity and authentication applications in [[information security]].[[User:Howard C. Berkowitz|Howard C. Berkowitz]] 16:46, 31 October 2008 (UTC)
| |
| | |
| : I've used "cryptographic hash" in text. One reason I have not started an article yet is that I'm not sure what the name should be.
| |
| | |
| : Where are the fragments? I'm working bottom-up here; [[block cipher]] is near done; [[stream cipher]] nowhere near done but as far as I want to take it. Hashes are the obvious next thing, the only major crypto primitive not covered yet.
| |
| | |
| : We changed "cryptographic snake oil" to "snake oil (cryptography)". My guess is this one should be [[hash (cryptography)]] (not "cryptographic") with [[cryptographic hash]] and [[message digest]] redirecting to it. But those are at least partly policy decisions, related to the overall CZ naming scheme. Should [[cryptographic hash]] exist as a redirect, or should all the links be <nowiki>[[hash (cryptography) | cryptographic hash]]</nowiki>? Should the more formal [[message digest]] or [[message digest algorithm]] be the main title with [[hash (cryptography)]] as the redirect? I'll happily defer to a editor on such questions.
| |
| | |
| : There are related questions. I think policy would be to have [[Hashed message authentication code]] with a redirect from [[HMAC]]. Fine there, but are MD4 and MD5 exceptions? AFAIK no-one uses the formal name, so perhaps they should be.
| |
| | |
| : What about the SHA family? The top article is [[Secure hash algorithm]], but how many articles & how are the rest organised? There was the original SHA algorithm. Then NSA added a one-bit rotation (which they refused to explain) to create SHA-1; that's what people generally mean when they say "SHA". Then NIST standardised SHA-2 which has several variants; SHA-224, SHA-256, SHA-384, SHA-512. Now they are running an [[AHS contest]] to create an [[Advanced hash standard]], also known as SHA-3, also supporting 224, 256, 384 & 512-bit sizes.
| |
| | |
| : I think we need articles on the topics linked to in the previous paragraph; not sure if we need more. I'd like the hash article organised much like [[block cipher]], with AHS candidates instead of AES at the end. [[User:Sandy Harris|Sandy Harris]] 01:53, 1 November 2008 (UTC)
| |
| | |
| ::Overall naming scheme? The substance of many discussions is about all. Your guess, on this, is as good as mine. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 02:06, 1 November 2008 (UTC)
| |
| | |
| == Some context and compromise about "being secure" ==
| |
| | |
| Recently, you've said, with respect to DES, "With an intelligence agency budget, it is crackable in seconds." I completely agree. Earlier, you said that the EFF custom system and large agencies can break it promptly. With that I do not agree.
| |
| | |
| : I give a link to a $10,000 off-the-shelf system that finds a DES key in a week, given one known plaintext. [[User:Sandy Harris|Sandy Harris]] 15:50, 3 November 2008 (UTC)
| |
| | |
| ::And the likelihood some private person is going to buy it to break the circulation system at the town library? Again, Sandy, may I suggest directly answering the issue: "does DES need to be replaced in any systems where it is now used"? Remember, there are costs of doing so. The desirability of moving to an AES-native system might justify moving to a new operating system. I'm thinking, however, of legacy applications that are the only things on the machine that access a purpose-installed DES software library.
| |
| | |
| ::I advise on some hospital systems, where encryption of any sort is not legally required on the LAN, although many use single DES. Before I would tell some of those clients to move in AES, I'd suggest they do some things with biometric authentication -- and move workstation off counters where they are easily visible to the passing public. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 16:03, 3 November 2008 (UTC)
| |
|
| |
| I would never advise a client to put DES in a new system. Indeed, I've set up housemates' PCs with longer than minimal AES key lengths.
| |
| | |
| My concern, however, is, especially in the articles on a specific kind of cryptosystem, the insistence that any particular encryption technology is completely insecure. Remember, not everyone reading this is going to have expertise in system-level security assessment; perhaps I should write a risk-benefit analysis, at a more general level, in [[information security]].
| |
| | |
| : Yes, but then we'd likely argue on that talk page. :-)
| |
| | |
| ::But it's a valid argument, with very real-world impacts. Security is not limited to or defined by crypto. Again: we do not disagree about using AES in new systems, or, if it's a relatively simple matter of changing calls to OS-supported encryption, to changing under proper version control. I have to think long and hard, however, if changing DES is the first security issue for legacy applications for organizations to which $10,000 would be a lot of money. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 16:03, 3 November 2008 (UTC)
| |
| | |
| As I have said, I can see no reason to install DES in anything new. Good software and coprocessor applications are readily available. Try to picture a reader that interprets "not secure" as "essentially broken by their children", and might, in some panic, tear apart legacy applications to replace DES with AES. Since such a reader is not experienced with software modification, that reader might wind up with a completely secure machine, which won't work at all.
| |
| | |
| Here's the kind of user and application I have in mind. A local library I know is very concerned about patron privacy. Some time ago, when DES was all that was readily available, they put it on the book checkin-checkout LAN and computers, and perhaps a few reference machines not connected to the Internet. Given semi-small-town politics, I could easily picture someone coming in, who knew they were using DES, and start demanding AES conversion. They aren't physically secure. Hard copies of overdue book lists are common. There would be little to stop a surveillance agent, in the parking lot, from aiming a telephoto lens through the window near the checkout, and read the screen. Replacing DES with AES may break their application if they don't know what they are doing, and, assuming they want the strong privacy policy to continue, divert resources from things that actually will improve their security: lock up and shred overdue book lists if the volunteers have to have them in hard copy, put a light curtain on the window/turn the checkout terminal screen away from the window/put an optical guard on it.
| |
| | |
| Your point is well taken for new applications, especially when there is a serious threat. There are, however, a huge number of existing, low-risk applications where cryptanalysis is the lowest of threats. The article should not scare people; I believe it is in [[information security]] where the tradeoffs should be. In this article, it's perfectly appropriate to say what intelligence agencies, EFF, and even Internet cloud computing can do to DES, but in quantitative cost and power terms. Give the person looking at all risks consider the overall problem for the existing systems, and whether a new backup drive, or being sure to run basic anti-malware software, or to put certain files on a USB drive and lock it up when not in use. Could you even buy a DES USB drive any more? [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 14:22, 3 November 2008 (UTC)
| |
| | |
| : I've rewritten a bit. [[User:Sandy Harris|Sandy Harris]] 15:50, 3 November 2008 (UTC)
| |
| | |
| ::This looks good. Now you are making me wonder if any of the classical writers measured Achilles' vulnerable heel length. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 17:28, 3 November 2008 (UTC)
| |
| | |
| == Tiger hash ==
| |
| | |
| While I really don't want a full-sized house tiger, I am happy that was clarified to be an algorithm, rather than chopped and fried tiger. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 00:14, 29 November 2008 (UTC)
| |
| | |
| : I live in China. I'll bet I could find edible tiger products. It sometimes seems they use most things as food and ''everything'' as medicine. [[User:Sandy Harris|Sandy Harris]] 07:10, 29 November 2008 (UTC)
| |
| | |
| == Approval?==
| |
| I've just shortened the "Context" section radically, moving text that did not really belong here to [[cryptanalysis]] and deleting material already copied to [[cryptography#keying]] or [[hybrid cryptosystem]].
| |
| | |
| I think that was the last big thing that needed doing before approval. Is it now ready? Checking history, I find I'm the only editor ever, except for one format fix early on by Hayford Pierce. [[User:Sandy Harris|Sandy Harris]] 05:00, 16 April 2009 (UTC)
| |
| | |
| :Some copy editing needed on references, which I can do if permitted for (presumed) single-editor approval. In most cases, it will work better if you use "citation" rather than "cite paper"; not all the bibliographic references show up with cite paper -- where posible, provide links. For the book references 1 and 2, put the name of the books in double apostrophes rather than quotes, so the will italicize. Also, the text reference to a marginal website should move from the articles to external links.
| |
| | |
| :: done. [[User:Sandy Harris|Sandy Harris]] 09:20, 16 April 2009 (UTC)
| |
| | |
| :That's all I immediately saw, just waking up and going back to bed soon. Given the number of options, it might be a little easier to read with some summary/comparison tables; I want to think if anything is long enough to justify a subarticle, or if the structure is such that the moderately interested reader can get adequate detail without going through every section. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 07:09, 16 April 2009 (UTC)
| |
| | |
| :: Good questions. I'm not sure of the right structure either. Also, as we both said above, getting more eyes would be good; not sure if it is possible. [[User:Sandy Harris|Sandy Harris]] 09:20, 16 April 2009 (UTC)
| |
| | |
| :: Several things have already been moved out of here into separate articles. [[Block cipher modes of operation]], [[code book attack]], [[algebraic attack]]. Is that what you mean by "subarticle"? [[User:Sandy Harris|Sandy Harris]] 09:27, 16 April 2009 (UTC)
| |
| | |
| :::Some first thoughts, still waking up and just have a little time.
| |
| :::*'''Citations''': I've checked, and most of the problems go away if you change "cite paper" to "citation" in the templates; most go away--I think that "cite paper" gets confused if you give it both a publisher and journal. In general, if you have both, use journal in preference to title, building publisher into the journal line if you have to disambiguate. Provide links if available.
| |
| :::*'''External links''': The main article shouldn't have any. If you want to say a particular algorithm has a website, either make it an inline reference, or move it to the External Links subpage.
| |
| :::*'''Pseudocode-code''': There is a predefined <code>code</code> subpage. The C-code can move there, with a link to a subheader within the page. Things like the DES algorithm are hard to read as a block of monospaced indented code; either convert them to numbered/bulleted lists, or move them to code. The S-boxes also take up a lot of visual space; perhaps they could be made two-column, a graphic, or moved to code.
| |
| :::*'''Subarticles''': I want to look farther. [[Rotation]] comes to mind as both useful elsewhere, if you are thinking of circulating shift register. When I was writing one of my books and said "it will be obvious that...", I did have the grace to go to the mirror and slap myself several times. If it's easier to express in linear algebra (and indeed in a diagram), it's fair to the reader to make that expression available.
| |
| :::More later. At this point, I'm focusing on getting it physically more readable for content.[[User:Howard C. Berkowitz|Howard C. Berkowitz]] 13:52, 16 April 2009 (UTC)
| |
| | |
| I've done most of this. I sidestepped the code and tables issues by moving most of the detail on IDEA to a separate article. That article will need cleaning up later. What it leaves here is a cleaner more concise section, I think all we need.
| |
| | |
| I've put the cipher homepages in external links, but I think they should still be mentioned in the article itself. Do others agree? What is the format for linking to them from the article? [[User:Sandy Harris|Sandy Harris]] 01:05, 19 April 2009 (UTC)
| |
| | |
| : I think I've now replaced all external links in the article with links to [[Block_cipher/External_Links]]. [[User:Sandy Harris|Sandy Harris]] 02:31, 30 April 2009 (UTC)
| |
| | |
| == observations from a lay reader ==
| |
| | |
| I thought I'd volunteer to read the article as one who knows next to nothing of the topic and critique it based on how easy it is for me to understand. So I started at the top and found the first paragraph kind of clunky because the two sentences do not connect to each other very well. If you're going to mention stream ciphers in the opening (which may not be necessary at all), I'd suggest something like this: <blockquote>'''Block ciphers''' are one of two main types of [[symmetric cipher]]. They operate on fixed-size blocks of [[plaintext]], giving a block of [[ciphertext]] for each. The other main type of symmetric cipher, [[stream cipher]]s, differ from block ciphers in that they (fill in relevant info).</blockquote> I'll come back soon to critique the rest. --[[User:Joe Quick|Joe Quick]] 15:21, 16 April 2009 (UTC)
| |
| | |
| : Great! It really needs that. I've rewritten the opening, made some fixes Howard suggested & a few more that occurred to me as I re-read it. I'm away for the weekend, will do more sometime next week. [[User:Sandy Harris|Sandy Harris]] | |
| | |
| : It still needs readers if Joe or anyone else can find the time. [[User:Sandy Harris|Sandy Harris]] 23:40, 5 May 2009 (UTC)
| |
| | |
| == Additions ==
| |
| I've made a few additions. A section on "large-block ciphers" at the end, two more ciphers in the "AES generation" section, Camellia & SEED, tweakable ciphers in the "iterated block ciphers" section, and the Biham/Biryukov stuff in "Variations on DES". Readers, please have a look. [[User:Sandy Harris|Sandy Harris]] 09:13, 30 April 2009 (UTC)
| |
| | |
| I've also made another pass through it, trying to clarify various things, make the order a bit more logical, etc. At this point, it has gone about as far as I can take it. Editor, or just reader, feedback would be wonderful. Howard's already given quite a lot, and Joe some; those were helpful. But it really needs more, from them or others. [[User:Sandy Harris|Sandy Harris]] 07:55, 12 May 2009 (UTC)
| |
| | |
| :Looking good. Minor suggestions only -- be sure, when you describe the steps of an algorithm, to at least bullet if not number them. Just out of curiosity, what was wrong with Hasty Pudding? [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 02:27, 23 May 2009 (UTC)
| |
| | |
| :: I think mostly it was just too unorthodox. It is hard to be confident of security without a lot of analysis and if something is unconventional, not much existing analysis applies. [[User:Sandy Harris|Sandy Harris]] 03:27, 23 May 2009 (UTC)
| |
| | |
| We currently have all 5 AES finalists plus three others for 8 of 15 candidates described. I figure it is worth adding brief descriptions of the other 7, will do that sometime this week. Then the question arises whether that is too much for this article and a large chunk should move, perhaps to an AES competition article. Write it, then worry about that. [[User:Sandy Harris|Sandy Harris]] 00:30, 25 May 2009 (UTC)
| |
| | |
| That is done. I think it needs more layers of headings, so the structure under "The AES Generation" becomes:
| |
| * AES
| |
| * Other finalists
| |
| ** Twofish
| |
| ** ... 3 more
| |
| * Unconventional candidates
| |
| ** Hasty Pudding
| |
| ** Frog
| |
| * Other candidates
| |
| ** ... 8 more
| |
| * Other 128-bit ciphers
| |
| ** Camellia
| |
| ** SEED
| |
| Any comment? [[User:Sandy Harris|Sandy Harris]] 16:08, 25 May 2009 (UTC)
| |
| | |
| : Went ahead & did that. Comment is still welcome. [[User:Sandy Harris|Sandy Harris]] 11:17, 31 May 2009 (UTC)
| |
| | |
| I added something at [[Block_cipher/Catalogs]] and linked to it from the main article. Is that the right place for it? Is there a better way to format it than just using HTML table tags as I did? If it does need moving or re-formatting, someone else please do it. [[User:Sandy Harris|Sandy Harris]] 02:11, 26 May 2009 (UTC)
| |
| | |
| ==Since You Asked==
| |
| I'm reading this as a complete novice who knows absolutely nothing about codes except what I've read in spy novels, but since you asked (on the forums), I can offer my reactions here:
| |
| :: - My major reaction would be that comments are right: This is too long. Might it work to deal with the winner, AES, in this entry and move the discussions of the four "losers" to separate pages. (I haven't checked, so forgive me if this is redundant but that would suggest links in each of them back to AES and you might want to use redirect pages named "RES" and "Rijndael" to point here so all five are treated consistently.
| |
| :: - Why is "Linearity" on the Related Articles page the only item lacking a definition? (An oversight most likely; It should be added before approval.)
| |
| :: - The Bibliography page is empty and the comment there is unconvincing. Even a list of the "Ten Best Books on Block Cipher" (In the last 10 years; Ever, Whatever) would be an improvement. As is, leaving this as an empty page detracts seriously from an otherwise outstanding contribution.
| |
| :: - The External Links page is good, but it probably could be excellent. See the list of suggested topics at [[CZ:External_Links]] for other categories that might be included there. Also, the Homepages for... section doesn't have any explanatory text after the links. All other sections do.
| |
| ::I hope these are useful. To this novice, this is an excellent piece of work and a credit to the CZ effort! It needs to be nominated for a highlighted article.
| |
| ::[[User:Roger Lohmann|Roger Lohmann]] 11:59, 4 June 2009 (UTC)
| |
| | |
| * I've changed the Bibliography & External links sections some, though the links could probably use more work.
| |
| | |
| * I'm reluctant to attempt a definition of linearity. I understand some of the applications, but I'm not certain I'd define the general and abstract concept precisely right. Is there a math editor in the house?
| |
| | |
| * I'm not sure what to do about the length.
| |
| ** I've already moved some stuff originally written here out to create things like [[algebraic attack]], [[International Data Encryption Algorithm]] & [[block cipher modes of operation]], and moved some things to higher-level articles like [[cryptography]].
| |
| ** Much of the current AES section could move to an [[AES competition]] article, and some to articles on specific ciphers, but I think this article needs at least brief coverage of the five finalists and the two ciphers with interesting new design ideas (Hasty Pudding & FROG).
| |
| ** The section on CAST is quite long; much of it could move to a CAST article but I thought it was needed here because the design ideas influenced other ciphers.
| |
| * Editor input, or comments from other readers, would be welcome on this. [[User:Sandy Harris|Sandy Harris]] 02:47, 5 June 2009 (UTC)
| |
| | |
| * For that matter, the two largest sections, [[Block_cipher#DES_and_alternatives]] & [[Block_cipher#The_AES_generation]], might both become separate articles leaving only an overview in the main article. [[User:Sandy Harris|Sandy Harris]] 03:49, 5 June 2009 (UTC)
| |
| | |
| Also, there are lots of other block ciphers I have not even mentioned. WP's list is
| |
| | |
| : 3-Way | ABC | Akelarre | Anubis | ARIA | BaseKing | BassOmatic | BATON | BEAR and LION | C2 | Camellia | CAST-128 | CAST-256 | CIKS-1 | CIPHERUNICORN-A | CIPHERUNICORN-E | CLEFIA | CMEA | Cobra | COCONUT98 | Crab | CRYPTON | CS-Cipher | DEAL | DES-X | DFC | E2 | FEAL | FEA-M | FROG | G-DES | GOST | Grand Cru | Hasty Pudding cipher | Hierocrypt | ICE | IDEA | IDEA NXT | Intel Cascade Cipher | Iraqi | KASUMI | KeeLoq | KHAZAD | Khufu and Khafre | KN-Cipher | Ladder-DES | Libelle | LOKI97 | LOKI89/91 | Lucifer | M6 | M8 | MacGuffin | Madryga | MAGENTA | MARS | Mercy | MESH | MISTY1 | MMB | MULTI2 | MultiSwap | New Data Seal | NewDES | Nimbus | NOEKEON | NUSH | Q | RC2 | RC5 | RC6 | REDOC | Red Pike | S-1 | SAFER | SAVILLE | SC2000 | SEED | SHACAL | SHARK | Skipjack | SMS4 | Spectr-H64 | Square | SXAL/MBAL | Threefish | TEA | Treyfer | UES | Xenon | xmx | XTEA | XXTEA | Zodiac
| |
| | |
| Arguably, this article should cover more of those. I'm thinking about adding BassOmatic (famously wrong, the easily broken block cipher Zimmerman invented for PGP 1.0), Square (ancestor of Rijndael, and a new class of cryptanalysis was invented to break it) and maybe Idea NXT. However, the article's already too long. Comment? [[User:Sandy Harris|Sandy Harris]] 04:17, 5 June 2009 (UTC)
| |
| | |
| ::I see this for the first time, and only "browsed" it. So I may bring up things that already have been discussed, and I may have overlooked important things. I, too, think that this is too much material for one article. If someone (e.g., me) is looking for information on block ciphers one will first look for answers to the following questions: What are block ciphers, what are they needed for, what ideas, methods, problems, etc. are relevant. After a brief answer a somewhat more detailed and technical exposition should provide some in depth information (for those wanting to know more). This seems to be nicely done in the first three sections. (Maybe the introduction could say a little bit more, for those who don't want to read these sections.) But the material on special ciphers should, I think, be moved to their own pages, either a page for each, or (if useful) by grouping them together if they are only variants. Of course, the catalog should contain all these ciphers (and more). And, maybe, they could be replaced by a simplified(?) example that illustrates the methods described in the text. And, maybe, a section on the history of the block ciphers would be nice, too. <br> (The second paragraph of the introduction belongs into the Bibliography, I think.) <br> (Another minor point: in mathematics, it is usually "nonlinear" without an hyphen.)<br> [[User:Peter Schmitt|Peter Schmitt]] 14:49, 5 June 2009 (UTC)
| |
| | |
| It is becoming clear we need a catalog listing many block ciphers, perhaps starting with WP's list. I'm not sure how to create that; I could do it with an HTML table but there may be a way that is more wiki-ish or easier. Suggestions? Volunteers?
| |
| | |
| Once we have that, start moving material to other articles. How much of the DES section should be in the DES article? I think Triple DES and probably "Variations on DES" can be separate articles. IDEA already has an article, started with text moved from here. GOST, RC5, Skipjack and TEA could be treated similarly and coverage here reduced to links in the catalog and a sentence or two in text. CAST and Blowfish should have articles, but I think much of the design principles discussion does belong here.
| |
| | |
| What it the right format for article names? Blowfish cipher? Blowfish block cipher? Blowfish (cryptography)? Blowfish (cipher)? IDEA is at [[International Data Encryption Algorithm]], and TEA belongs at [[Tiny Encryption Algorithm]], but should there be redirects from IDEA (cipher) or some such?
| |
| | |
| I think the AES contest merits a separate article. The red links I've created so far are to "AES contest", but I now think [[AES competition]] would be better; WP has "Advanced Encryption Standard process" [http://en.wikipedia.org/wiki/Advanced_Encryption_Standard_process]. Other opinions? Given such an article, and stubs for many of the ciphers started with material moved from here, the "AES generation" section here can be radically shortened.
| |
| | |
| However, I'm busy with other things for the next several weeks. It is not clear whether or when I'll find time for any of the above. Anyone else care to tackle some of it? [[User:Sandy Harris|Sandy Harris]] 00:26, 6 June 2009 (UTC)
| |
| | |
| == Moving forward ==
| |
| My current thoughts on where this should go:
| |
| | |
| * Create [[AES competition]] (but is that the right name?) by copying the "AES generation" section from here.
| |
| * Create articles, or at least stubs, for all the ciphers listed here, by copying material from here. How should those articles be named? DES already has an article, so just copy stuff here into that.
| |
| * Copy some material now under CAST, use it to expand the Feistel ciphers section and create a new section under "Principles and techniques", "Resisting ...".
| |
| * Reduce the "DES and alternatives" and "AES generation" sections here to a few paragraphs each with lots of links.
| |
| | |
| This needs comment before any action. In particular, agreeing on a naming convention before creating a host of new articles seems essential. [[User:Sandy Harris|Sandy Harris]] 04:20, 6 June 2009 (UTC)
| |
| | |
| : Some suggestions:
| |
| :: A list of ciphers could be put into a (partially annotated) catalog.
| |
| :: New articles could be created for groups of related ciphers (not necessarily for each cipher, redirections should be sufficient, at least in the beginning).
| |
| :: In the main article, a short history could give an overview. replacing the material on special ciphers which is moved to the new articles, including an article on the AES competition.
| |
| :: I think "DES competition" is fine, but an alternative might be "History of DES", or something like that.
| |
| :[[User:Peter Schmitt|Peter Schmitt]] 09:19, 9 June 2009 (UTC)
| |
| | |
| That's done! Created [[AES competition]], two articles on groups of ciphers — [[CAST (cipher)]] and [[Rivest ciphers]] — and several for individual ciphers — [[Blowfish (cipher)]], [[SEED (cipher)]], [[Camellia (cipher)]], [[Twofish]], [[Threefish]], [[Skipjack]], [[GOST cipher]], ... This made a mess of the links, but I think I've fixed all the problems in this article. With all that material moved, this is now much shorter and cleaner. There are still quite a few red links down near the bottom, but those will go away as I create articles for other AES candidate ciphers using text now in [[AES competition]].
| |
| | |
| New version needs comment & criticism, then perhaps move toward approval. [[User:Sandy Harris|Sandy Harris]]
| |
| ==Procedurally confused==
| |
| I thought we had this at about-to-approve, and then Things Happened. I'm perfectly happy to nominate, though.
| |
| | |
| One thought--it deals with civilian and open crypto. While we obviously don't know the algorithms of all the military systems, we can make some reasonable guesses about when it started being used. While Kahn talks about some special-case mechanical systems that come close, I think it's arguably something that had to wait for electronics.
| |
| | |
| My guess, for the U.S., is that it started being used in the 1970s vintage [[KG-13]], although that might have been stream. Is this worth exploring? I was able to find a specific note that the 1981 [[KYV-2]] is block cipher [http://www.prc68.com/I/KYV2.shtml][[User:Howard C. Berkowitz|Howard C. Berkowitz]] 17:34, 8 August 2009 (UTC)
| |
| | |
| : I added a sentence mentioning military uses, second paragraph of "DES and alternatives". I'm not sure it needs exploring beyond that. [[User:Sandy Harris|Sandy Harris]] 03:33, 9 August 2009 (UTC)
| |
| | |
| :: Since it is unlikely that substantial information can be found we should not worry too much about military cryptography. Perhaps a separate article about historical methods can be written. [[User:Peter Schmitt|Peter Schmitt]] 22:05, 10 August 2009 (UTC)
| |
| | |
| :::Not saying we need it here, but a very substantial amount of information is available about US military cryptography. Remember Kerchoff's Principle: the security is in the keys. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 22:14, 10 August 2009 (UTC)
| |
| | |
| == Some remarks ==
| |
| | |
| I have only started to read the article. But here are a few comments:
| |
| : Random number (generator) is linked several times. It should be [[random number generator]], and the article should have this title -- there is no ''single'' random number. (One link should be enough.]
| |
| : The "see also" link could be included into the lead: "Block ciphers are ... a method used in [[cryptography]] or similar.
| |
| : AES competition is also linked twice in three lines. (Reformulation might avoid the "see also")
| |
| : Context (a remark on style): In think that it would better to provide the same information, but not in a style of a "list of contents".
| |
| (I do not make suggestions via direct edits because this could be a problem for approval?) [[User:Peter Schmitt|Peter Schmitt]] 23:04, 10 August 2009 (UTC)
| |
| | |
| : I think I've dealt with all of those. The last one led me to rewrite both of the first two sections, the intro and "Context", moving some text between them. [[User:Sandy Harris|Sandy Harris]] 05:21, 22 August 2009 (UTC)
| |
| | |
| == Catalog questions ==
| |
| This article currently has two catalogs, a [[Block cipher/Catalogs/Cipher list|list of block ciphers]] and a [[Block cipher/Catalogs/Cipher table|table]] with more detail on their properties. Should we eliminate the list, have just one catalog? How? Would the table need renaming?
| |
| | |
| The table is fairly large, but incomplete. One source for additional entries would be WP's list of block ciphers. Any volunteers to do the work of adding those?
| |
| | |
| Another catalog is a list of [[AES competition/Catalogs/AES players|well-known players]] in the [[AES competition]]. I created it originally as a catalog for this article, but then we split [[AES competition]] into a separate article so I moved it over there. However, when you look at that article, no catalog link is shown up at the top. How do we fix that? [[User:Sandy Harris|Sandy Harris]] 03:26, 7 October 2009 (UTC)
| |
| | |
| == Comments ==
| |
| | |
| It is a very long article -- I have not yet read all of it. It is comprehensive and well written survey.
| |
| | |
| But here are a few comments, mostly minor:
| |
| * Shouldn't it be "F-function" instead of "F function"?
| |
| * In mathematics we rather write <math>6\times4</math> instead of <math>6*4</math>
| |
| * In mathematics variables are written in italics: "''n''" instead of "n", etc.
| |
| * For consistency: do you write XOR-ed or XORed?
| |
| * (First paragraph of Nonlinearity) What is meant by: <br> "If all operations in a cipher were linear — in any algebraic system, with the attacker making the choice of system and perhaps trying more than one — then"? How can the attacker choose the system?
| |
| * (Iterated block ciphers) "At setup time the primary key undergoes key scheduling giving a number of round keys. In the actual encryption or decryption, each round uses its own round key." How are the round keys determined? Are they computed from the cipher key, or does the cipher require several keys?
| |
| * (Cipher structures) "he or she" - "him or her". Shouldn't this be avoided?
| |
| * The use of "^" for XOR is irritating (it reminds of logical and <math>\land</math>, while XOR has more relation to <math>\lor</math>. I think that either "+" (binary addition) or <math>\oplus</math> is a better and more usual choice.
| |
| [[User:Peter Schmitt|Peter Schmitt]] 00:38, 29 November 2009 (UTC)
| |
| | |
| : The ^ notation is from the C programming language, denoting a bitwise XOR on computer words. In mathematical terms, this would be a vector operation. Each bit of the output word is the XOR of the corresponding bits of the input words. For programmers, this is a standard notation. [[User:Sandy Harris|Sandy Harris]] 02:42, 29 November 2009 (UTC)
| |
| | |
| : I think I have dealt with all of those except "^" and "he or she" which I do not think need changing. I did add a parenthetical explanation of the "^" notation. [[User:Sandy Harris|Sandy Harris]] 03:34, 29 November 2009 (UTC)
| |
| | |
| : For <math>6\times4</math> vs <math>6*4</math>, I'd normally write the latter but pronounce it "6 by 4". I've changed he article to use "6 by 4" throughout; seems the simplest solution to me. [[User:Sandy Harris|Sandy Harris]] 04:58, 29 November 2009 (UTC)
| |
| | |
| :: Just a quick reply (I do not have more time at the moment): If the "*" is usual in cryptography I do not object. But: Would you also write " (n*m)-matrix" or "(3*3)-matrix", or "3 by 3 matrix"? Or rather ( 3 x 3 )-matrix?
| |
| :: I have read (in the [http://en.wikipedia.org/wiki/Exclusive_or WP entry] about the caret. They write that it is not used outside of programming code, and I believe this.
| |
| :: [[User:Peter Schmitt|Peter Schmitt]] 09:27, 29 November 2009 (UTC)
| |
| | |
| :: I'm a C programmer, so using the caret seems natural to me. However, I checked two specifications by well-known cryptographers, [[Rijndael]] and [[Serpent]]. Both use <math>\oplus</math>, so I've changed the article to use that throughout. [[User:Sandy Harris|Sandy Harris]] 11:16, 29 November 2009 (UTC)
| |
| | |
| ::: I have finished reading the article.
| |
| ::: The following comments are probably mostly a matter of personal taste:
| |
| :::* I prefer shorter articles and would split it (but discuss this only after approval).
| |
| :::* I think that most (if not all) references should be moved as "sources" to the Bibliography subpage.
| |
| :::* Links need not be repeated over and over (and, if I am right, CZ policy agrees).
| |
| ::: Concerning the "catalogs": To me its fine that the list and the properties are separate.
| |
| ::: I'll join as supporting editor (and update the version).
| |
| ::: [[User:Peter Schmitt|Peter Schmitt]] 23:24, 29 November 2009 (UTC)
| |
| | |
| :: It has already been split some, spawning [[Block cipher modes of operation]], [[Algebraic attack]] (which needs a look from a math editor), [[AES competition]] and articles on individual ciphers. I'm not sure much else could go and still leave this article coherent.
| |
| :: Another editor. Great! [[User:Sandy Harris|Sandy Harris]] 23:57, 29 November 2009 (UTC)
| |
| | |
| :: Except for ''Applied Cryptography'', which is already in the bibliography, all the references are journal articles. I cannot see that those belong in a bibliography.
| |
| :: Should I de-link repeated links? Or would that mess up approval versioning? Do it on the draft after approval? [[User:Sandy Harris|Sandy Harris]] 00:08, 30 November 2009 (UTC)
| |
| | |
| ::: I have set the approval version to the current version. Howard or I can change this again, if you make some more changes. As I said, I do not consider my remarks as requests.
| |
| ::: I know that the article has already been split, but it is still - or again - quite long. But certainly not now.
| |
| ::: Why should journal articles be treated differently from books? A bibliography is (at least in my understanding) a collection of references to the literature. It can and should be organized "user-friendly", i.e., further reading should be separated from "original sources". For me footnotes/references are only needed to link a specific remark to a specific part of a citation.
| |
| :::: [[User:Peter Schmitt|Peter Schmitt]] 00:39, 30 November 2009 (UTC)
| |
| | |
| ::::: I have made a number of small changes, mostly based on your suggestions. Please update the version. [[User:Sandy Harris|Sandy Harris]] 12:09, 30 November 2009 (UTC)
| |
| | |
| ==APPROVED [http://en.citizendium.org/wiki?title=Block_cipher&oldid=100606167 Version 1.0]==
| |
| | |
| <div class="usermessage plainlinks">Discussion for [http://en.citizendium.org/wiki?title=Block_cipher&oldid=100606167 Version 1.0] stopped here. Please continue further discussion under this break. </div>
| |
| | |
| :I don't see that Howard actually saw [http://en.citizendium.org/wiki?title=Block_cipher%2FDraft&diff=100606872&oldid=100586032 these edits] or endorsed them. Peter did, though. Howard, are you okay with this those changes? [[User:D. Matt Innis|D. Matt Innis]] 22:16, 1 December 2009 (UTC)
| |
| | |
| ::Howard had approved a version through a couple of days ago, and that's the one I was *going* to OK, not a more recent one that had about a single space added to it. Then I saw today that the latest version had been updated by the editors so that it was the most recent one. So that's the one I approved. How am I supposed to figure out that, apparently, Peter approved the later one but not Howard. Where's Joe the Approvals Manager? Why, for once, can't people just give me a nice clean version to approve!!!??? [[User:Hayford Peirce|Hayford Peirce]] 22:31, 1 December 2009 (UTC)
| |
| | |
| ::: Sorry, I thought I did it correctly ... Wasn't I supposed to join in, or isn't it o.k. to update to a more recent version? [[User:Peter Schmitt|Peter Schmitt]] 23:04, 1 December 2009 (UTC)
| |
| | |
| :::: No, Peter, you did fine - exactly as you were supposed to do. In fact, with your endorsement, it's still a single editor approval, it's just that Howard's name is on it, too. However, the last version he apparently saw was on November 24 (17 edits earlier). Therefore, he either needed to show he approved those edits by making a statement to that effect here on the talk page. If he doesn't approve, the approval can still stand because you approved this version. So, really it's just a matter of whether Howard wants his name on this same version. All he has to do is let us know. [[User:D. Matt Innis|D. Matt Innis]] 23:44, 1 December 2009 (UTC)
| |
| | |
| :::::I can still go with the approved version. As the fates have it, I have a one-word correction that should have been applied earlier -- not an outright error but a clarification. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 00:02, 2 December 2009 (UTC)
| |
| | |
| :::::: Good news. All's well that ends well. Let's leave this approved version as is and you guys can work out your new one word correction on the draft and call us back if you need it to go into the Approved version. [[User:D. Matt Innis|D. Matt Innis]] 00:11, 2 December 2009 (UTC)
| |
| | |
| :::::::Well, that's last time I will ever approve or reapprove an article that Joe the Manager hasn't specifically told me to. [[User:Hayford Peirce|Hayford Peirce]] 00:36, 2 December 2009 (UTC)
| |
