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)

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)