Talk:Block cipher/Draft

Questions for editors

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? Sandy Harris 09:24, 7 September 2008 (CDT)

I guess I answered my own question there. It is now > 60 K bytes :-) Sandy Harris 04:40, 29 October 2008 (UTC)

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. Howard C. Berkowitz 05:05, 29 October 2008 (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.

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.

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.

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 [1]; 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.

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?

Did that. Still wonder about policy, though. 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

Howard C. Berkowitz 14:00, 29 October 2008 (UTC)

Helps some Thanks. 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? 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 {{main}} and {{seealso}} 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. Howard C. Berkowitz 16:02, 29 October 2008 (UTC)

Howard C. Berkowitz 16:02, 29 October 2008 (UTC)

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.

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.

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. Sandy Harris 18:42, 26 October 2008 (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.

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?

"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.

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.

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. Howard C. Berkowitz 17:58, 26 October 2008 (UTC)

Thinking. Will think & look more.

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. 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." 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. 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. 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? Sandy Harris 10:34, 27 October 2008 (UTC)

Did that, using Block cipher modes of operation which makes sense and is what Wikipedia uses. 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". 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. 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 [[Random number#pseudorandom number generator|PRNG]].

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. 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.

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 cryptosystems 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. 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. 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. 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. 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 <math>n+x</math>.

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. 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. 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 [2]. There is no good reason to use DES, or any other short key cipher, and has not been for years. 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). 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. 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. 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.

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.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 [[hash (cryptography) | cryptographic hash]]? 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. 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. 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. 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. 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. 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? Howard C. Berkowitz 14:22, 3 November 2008 (UTC)

I've rewritten a bit. 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. 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. 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. 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. 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. 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. 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. 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"? 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 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.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? 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. 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:

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 ciphers, differ from block ciphers in that they (fill in relevant info).

I'll come back soon to critique the rest. --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. Sandy Harris

It still needs readers if Joe or anyone else can find the time. 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. 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. 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? 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. 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. 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? Sandy Harris 16:08, 25 May 2009 (UTC)

Went ahead & did that. Comment is still welcome. 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. 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.

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. 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. 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? 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.
(The second paragraph of the introduction belongs into the Bibliography, I think.)
(Another minor point: in mathematics, it is usually "nonlinear" without an hyphen.)
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" [3]. 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? 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. 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.

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. 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 [4]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. 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. 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. 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?) 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. Sandy Harris 05:21, 22 August 2009 (UTC)

Catalog questions

This article currently has two catalogs, a list of block ciphers and a 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 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? 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 $6\times 4$ instead of $6*4$
• 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:
  "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 $\land$, while XOR has more relation to $\lor$. I think that either "+" (binary addition) or $\oplus$ is a better and more usual choice.

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. 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. Sandy Harris 03:34, 29 November 2009 (UTC)

For $6\times 4$ vs $6*4$, 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. 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 WP entry about the caret. They write that it is not used outside of programming code, and I believe this.

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 $\oplus$, so I've changed the article to use that throughout. 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).

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! 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? 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.

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. Sandy Harris 12:09, 30 November 2009 (UTC)

APPROVED Version 1.0

Discussion for Version 1.0 stopped here. Please continue further discussion under this break.

I don't see that Howard actually saw these edits or endorsed them. Peter did, though. Howard, are you okay with this those changes? 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!!!??? 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? 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. 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. 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. 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. Hayford Peirce 00:36, 2 December 2009 (UTC)

Hehe, this one is no big deal. Just be most careful with the controversial ones :D 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. 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? 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. Howard C. Berkowitz 03:47, 2 December 2009 (UTC)