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'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)

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)

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)

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)