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)