imported>Sandy Harris |
imported>John Stephenson |
| (81 intermediate revisions by 10 users not shown) |
| Line 1: |
Line 1: |
| {{subpages}} | | {{subpages}} |
|
| |
|
| == Questions for editors == | | ==APPROVED [http://en.citizendium.org/wiki?title=Block_cipher&oldid=100606167 Version 1.0]== |
| I'm not sure how large this page should get. Things like the Feistel structure and cipher modes might be explained here, but my guess is they need their own pages. Some of the design considerations might be covered here, or in [[cipher]], [[cryptography]], or [[cryptology]], perhaps even in articles on the attacks they prevent. My guess is those should be here, at least in outline, with details under specific attacks. Comment, anyone? [[User:Sandy Harris|Sandy Harris]] 09:24, 7 September 2008 (CDT)
| |
|
| |
|
| : I guess I answered my own question there. It is now > 60 K bytes :-) [[User:Sandy Harris|Sandy Harris]] 04:40, 29 October 2008 (UTC)
| | <div class="usermessage plainlinks">Discussion for [http://en.citizendium.org/wiki?title=Block_cipher&oldid=100606167 Version 1.0] stopped here. Please continue further discussion under this break. </div> |
|
| |
|
| ::There's nothing wrong with pulling together a high-level article with pointers to things in draft, and get approval on that. I'm trying to do that with DNS; there's a shortage of editors but maybe it will get done. I got it to a point where I felt it was internally consistent, and, while it's not a requirement, well illustrated. At that point, I could feel comfortable not worrying about it and going to the more detailed articles. Software and articles are alike: sometimes you need to ship Version 1. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 05:05, 29 October 2008 (UTC) | | :I don't see that Howard actually saw [http://en.citizendium.org/wiki?title=Block_cipher%2FDraft&diff=100606872&oldid=100586032 these edits] or endorsed them. Peter did, though. Howard, are you okay with this those changes? [[User:D. Matt Innis|D. Matt Innis]] 22:16, 1 December 2009 (UTC) |
|
| |
|
| I'm now fairly happy with [[Block_cipher#Principles_and_techniques]]; I think all that needs adding there is more detail on S-boxes. Do that, and flesh out various later sections and we should have a decent article. | | ::Howard had approved a version through a couple of days ago, and that's the one I was *going* to OK, not a more recent one that had about a single space added to it. Then I saw today that the latest version had been updated by the editors so that it was the most recent one. So that's the one I approved. How am I supposed to figure out that, apparently, Peter approved the later one but not Howard. Where's Joe the Approvals Manager? Why, for once, can't people just give me a nice clean version to approve!!!??? [[User:Hayford Peirce|Hayford Peirce]] 22:31, 1 December 2009 (UTC) |
|
| |
|
| Various questions arise, though. Most of them could also be asked about [[Stream cipher]]. First of course, criticism is needed; what have I missed or got wrong? Contributions would also be great.
| | ::: Sorry, I thought I did it correctly ... Wasn't I supposed to join in, or isn't it o.k. to update to a more recent version? [[User:Peter Schmitt|Peter Schmitt]] 23:04, 1 December 2009 (UTC) |
|
| |
|
| What goes here and what in related articles? Mostly, I'm just writing it here if the related article does not yet exist; if we end up with too much detail for here, we can always start the related article by moving the excess text. I'm trying to just cover the basics here, but there are a lot of basics.
| | :::: No, Peter, you did fine - exactly as you were supposed to do. In fact, with your endorsement, it's still a single editor approval, it's just that Howard's name is on it, too. However, the last version he apparently saw was on November 24 (17 edits earlier). Therefore, he either needed to show he approved those edits by making a statement to that effect here on the talk page. If he doesn't approve, the approval can still stand because you approved this version. So, really it's just a matter of whether Howard wants his name on this same version. All he has to do is let us know. [[User:D. Matt Innis|D. Matt Innis]] 23:44, 1 December 2009 (UTC) |
|
| |
|
| In some cases, it is not clear what a related article should be called; "MARS", "Serpent" and "Hasty Pudding" are all names of ciphers. Should the article be [[Serpent cipher]], [[Serpent (cryptography)]] or what? IBM call theirs "MARS", all uppercase [http://domino.research.ibm.com/comm/research_projects.nsf/pages/security.mars.html]; what do we call an article? GOST is an abbreviation of something-or-other in Russian, and there's both a GOST cipher and a GOST hash.
| | :::::I can still go with the approved version. As the fates have it, I have a one-word correction that should have been applied earlier -- not an outright error but a clarification. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 00:02, 2 December 2009 (UTC) |
|
| |
|
| How should links be set up? Various other articles have [[Feistel cipher]] as a link, but that is not written yet. Change those to point to [[Block_cipher#Feistel_structure]]? Move or copy my text to [[Feistel cipher]]? Or (my preference) create [[Feistel cipher]] as a redirect pointing into this article?
| | :::::: Good news. All's well that ends well. Let's leave this approved version as is and you guys can work out your new one word correction on the draft and call us back if you need it to go into the Approved version. [[User:D. Matt Innis|D. Matt Innis]] 00:11, 2 December 2009 (UTC) |
|
| |
|
| : Did that. Still wonder about policy, though. [[User:Sandy Harris|Sandy Harris]] 10:01, 26 October 2008 (UTC) | | :::::::Well, that's last time I will ever approve or reapprove an article that Joe the Manager hasn't specifically told me to. [[User:Hayford Peirce|Hayford Peirce]] 00:36, 2 December 2009 (UTC) |
|
| |
|
| ::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. | | ::::::::Hehe, this one is no big deal. Just be most careful with the controversial ones :D [[User:D. Matt Innis|D. Matt Innis]] 00:54, 2 December 2009 (UTC) |
|
| |
|
| ::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. | | :::::::::Yes, it is a big deal -- it means that it's taken two Cops to do what one should have been able to do. If I can't do it correctly the first time, then I won't do it again. And I can't do it correctly if Joe the Manager doesn't tell me *explicitly* precisely which version to approve. As I said above, and I mean it seriously, if I don't get a go-ahead from Joe in the future on an approval or re-approval, I simply won't do them. [[User:Hayford Peirce|Hayford Peirce]] 03:08, 2 December 2009 (UTC) |
|
| |
|
| ::: I don't use the forums. See [[User_talk:Sandy_Harris#forums]].
| | ===Questions=== |
| | Howard, what's your one-word change? We can make it on the draft? Also, is it time to archive most of the talk page? [[User:Sandy Harris|Sandy Harris]] |
|
| |
|
| ::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. | | :Add to "In theory, any '''block''' cipher can be broken by a brute force attack"...so the statement doesn't conflict with one-time pads. Yes, it's time to archive. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 03:47, 2 December 2009 (UTC) |
| | :: I made it "In theory, any cipher '''except a [[one-time pad]]''' can be broken by a brute force attack", since stream ciphers are also vulnerable. |
| | :: Also did the archiving. [[User:Sandy Harris|Sandy Harris]] 03:26, 27 November 2010 (UTC) |
|
| |
|
| ::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.
| | == Re-approve? == |
|
| |
|
| ::Does that, at all, help? I'm still caffeine-depleted and may be more coherent in an hour or two | | The current approved version is from 2009. I have made a number of [http://en.citizendium.org/wiki?title=Block_cipher%2FDraft&action=historysubmit&diff=100803401&oldid=100606872 changes since then]. I'd say it needs re-approval, and is ready for that. |
|
| |
|
| [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 14:00, 29 October 2008 (UTC)
| |
|
| |
|
| ::: Helps some Thanks. [[User:Sandy Harris|Sandy Harris]] 14:28, 29 October 2008 (UTC) | | == Approval Process: {{ApprovalProcess|certify}} == |
|
| |
|
| How should links work within an article? I've consistently done it with internal links; every link to "DES" is to "#DES", the article's DES section, except for a link in that section pointing out to the main DES article. This seems right to me; keep the reader here, at the same level of detail, unless he actually asks for more. What do editors thnk, and is there a policy on this? [[User:Sandy Harris|Sandy Harris]] 06:11, 25 October 2008 (UTC)
| | ''Call for review: ''[[User:Sandy Harris|Sandy Harris]] 03:42, 8 June 2012 (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. | | ''Call for Approval: ''[[User:Anthony.Sebastian|Anthony.Sebastian]] 01:59, 18 June 2012 (UTC) |
|
| |
|
| :While there is less a strict policy and more a judgment call, do consider the <nowiki>{{main}} and {{seealso}}</nowiki> to put at the tops of articles and headings. Off the top of my head, block cipher might have cipher or cryptography as main. I can't honestly say if seealso would better fit alternatives such as stream ciphers, or complementary issues in information security. Seealso doesn't feel right, however, for subarticles. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 16:02, 29 October 2008 (UTC) | | ''Approval Notice: ''[[User:Anthony.Sebastian|Anthony.Sebastian]] 03:55, 6 September 2012 (UTC) |
|
| |
|
| [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 16:02, 29 October 2008 (UTC)
| | ''Certification of Approval: ''[[User:Anthony.Sebastian|Anthony.Sebastian]] 03:56, 18 September 2012 (UTC) |
|
| |
|
| | ---- |
| | ''Please discuss the article below, [[{{BASEPAGENAME}}/Approval]] is for brief official referee's only!'' |
| | === Comments === |
|
| |
|
| | Unfortunately, any time I've had for Citizendium has been used up by Management Council activities. Realistically, I am not going to have time to review this, or any other articles, for approval in the near future. I'm sorry, life has been pretty complicated lately (death in the family) and this is the situation, which I did not anticipate.[[User:Pat Palmer|Pat Palmer]] |
|
| |
|
| | | : No rush. This one is a long complex article on an important topic. We should take the time to get it right and we have time since there's an earlier approved version in place. |
| | | : There are several new computer editors. Would any of them care to comment here? |
| | | : It does need more eyes. The writing is almost entirely mine, and only one editor (no longer here) was actively involved during development, though others were during approval. [[User:Sandy Harris|Sandy Harris]] 05:40, 8 June 2012 (UTC) |
| | |
| | |
| == 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. [[User:Sandy Harris|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. [[User:Howard C. Berkowitz|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. [[User:Sandy Harris|Sandy Harris]] 18:42, 26 October 2008 (UTC)
| |
| | |
| ::Good observation. That would suggest that "round", perhaps, should be a subsection. Any time you find something that forms a foundation for understanding another process. Once you explain round, there's absolutely nothing wrong, and much right, with saying "the idea of a round is the base for additional mechanisms described below, such as SP-networks, Feistel and Avalanche." [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 18:55, 26 October 2008 (UTC)
| |
| | |
| == Safe and unsafe ==
| |
| | |
| My main point here probably belongs in [[cryptography]] or even [[information security]], but there needs to be perspective on what it means to be safe or unsafe. I completely agree that DES is not appropriate for anything that has to remain secure for even days, or has to protect any substantial body of data. Take something like a stock buy order with a time limit — it needs protection while the trader is placing the order with a fixed price authorization, but if he loses, the information has no particular value. If the order gave the trader a range of acceptable prices, and the trader could buy at less than the maximum, those orders become more sensitive, because they could reveal the overall valuation strategy of the buyer.
| |
| | |
| A military COMSEC principle is often misstated. If you send a firing order to artillery, and they will kill the target before the target could move even if fully warned, in principle, it would make no difference if it were sent in the clear. If, however, the enemy could collect a series of messages and infer things about your doctrine, then those messages might need much more protection.
| |
| | |
| There are special cases of protection being too much. I found some diaries of mine from age 13, and I remember using Playfair on the encrypted sections. After a fair bit of computer time, I concluded I didn't know how to use Playfair at the time, and came up with a one-way system. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 21:30, 26 October 2008 (UTC)
| |
| | |
| == Move modes? ==
| |
| I wonder about moving the section on modes of operation out to its own article. That's not directly related to block cipher design, which is enough to cover here. It is a usage consideration, like proper re-keying. It needs mention and a link here, but details can be elsewhere. [[User:Sandy Harris|Sandy Harris]] 10:09, 27 October 2008 (UTC)
| |
| | |
| : Would it move to a new separate article, perhaps [[Block cipher modes]]? Or to a sub-topic, perhaps [[Block cipher/Modes of operation]]? If the latter, how do I do that? [[User:Sandy Harris|Sandy Harris]] 10:34, 27 October 2008 (UTC)
| |
| | |
| :: Did that, using [[Block cipher modes of operation]] which makes sense and is what Wikipedia uses. [[User:Sandy Harris|Sandy Harris]] 09:57, 29 October 2008 (UTC)
| |
| | |
| Related to that, I'd like to insert a new section "High-level considerations" or "The role of block ciphers" or some such, showing a bit about the context where block ciphers are used. Mention key management issues, public key & DH as solutions, re-keying, mode of operation, side-channel, need for authentication .., No detail on any of those, just a bit on the principle & a wikilink. Make the point that secure components are necessary for secure systems, but not sufficient. All before we start on block cipher details with "principles & techniques". [[User:Sandy Harris|Sandy Harris]] 10:27, 27 October 2008 (UTC)
| |
| | |
| ::While I recognize PKI and ECB are different things at different levels of detail, it really wouldn't hurt to have a high-level article, perhaps initially branching from [[Cryptography]] on [[Cryptographic key management]]? ("Management" is the most common term, but I notice that many people think key creation is somewhere else). ECB could be covered at different levels of detail in different places.
| |
| | |
| ::Keys, of course, aren't limited to block ciphers. The pure management piece can cover stream ciphers, all the way down to manual systems. Smith, in ''Internet Cryptography'', has an excellent practical section on the secure handling of keys (KEK, perhaps). There's a wide range of military key loading devices, which blur into things that are more authentication token (e.g., the physical Crypto Ignition Key that looks like a thick conventional key). (makes mental note more about needing introductory authentication in [[information security]], high-level authentication article that covers things like [[biometrics]], multiple person authentication (e.g., dual key), etc.).
| |
| | |
| ::Sandy, I'm deliberately making suggestions here rather than in the text. I was reminded that I can't approve an article if I've made any substantive edits to it. Also, I think we work together better this way. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 14:44, 27 October 2008 (UTC)
| |
| | |
| == Miscellany ==
| |
| | |
| Down at the bottom, there's a red reference to [[pseudorandom number generator]]. Even if the sentence structure means you want the link to read something else, such as PRNG, remember that you can link to a subhead, such as <nowiki>[[Random number#pseudorandom number generator|PRNG]]</nowiki>.
| |
| | |
| Just as a guideline that I don't think violates editor status, I started a Related Articles subpage. You might want to clone it to some other articles.
| |
| | |
| It is useful to have definitions for important terms within articles, since without definitions, Related Pages and Disambiguation Pages don't work well. Unfortunately, there isn't a really clean way to have a definition-only of something that is part of a larger article, which makes searches inelegant. This is a long-running CZ issue: could there be an "approved short article" that, by its nature, ''is'' a definition and doesn't carry all the metadata, and especially not the definition subpage, of a regular article. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 15:05, 27 October 2008 (UTC)
| |
| | |
| == External attacks ==
| |
| | |
| As you suggest, some of this is, or will be, covered elsewhere. See, for example, [[communications intelligence#acoustic cryptanalysis]].
| |
| | |
| From wetware memory, the relatively little-known Federal Standard 1027, issued along with the DES algorithm specification, which was both a Federal Information Processing Standard and a Federal Standard, warned against timing attacks. 1027 was public, written by NSA, and addressed the physical security of devices in which DES was implemented.
| |
| | |
| Also, see [[Radiofrequency MASINT#Unintentional Radiation MASINT]].
| |
| | |
| [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 01:43, 29 October 2008 (UTC)
| |
| | |
| : Yes, much of this really belongs elsewhere, in particular a lot of [[Block_cipher#Context]] should be in higher level articles because it is not specific to block ciphers. I think [[hybrid cryptosystem]]s really need their own article, covering how each primitive contributes and how they can be put together. Some of [[Block_cipher#The_AES_generation]] should probably be in a separate article on the [[AES contest]]. Some of the more detailed descriptions of ciphers might be moved to articles specific to those ciphers.
| |
| | |
| : For now, though, I'm just trying to get it written. If I know of good coverage elsewhere, give an overview here and link to the other. If I don't, just write it here. Later on, we can worry about what goes where, move or copy text as appropriate. For a few things, I'm writing here because I just want to take a different slant than the text elsewhere gives. We can worry about that later too; both may be correct for different contexts, or perhaps we need some debate and/or compromise; those will be easier with text in hand. [[User:Sandy Harris|Sandy Harris]] 04:30, 29 October 2008 (UTC)
| |
| | |
| == Are we there yet? ==
| |
| | |
| I think it is done, ready for approval. Not finished or perfect, but ready.
| |
| | |
| One test that is absolutely necessary, though, is to have some people that do not know the field read through it and see if it — especially the "concepts & techniques" section — makes sense to them. I'm convinced it should, but don't actually know if it does. [[User:Sandy Harris|Sandy Harris]] 09:55, 29 October 2008 (UTC)
| |
| | |
| :I'm still thinking on it. Much of the "context" section, I believe, would better move to more general articles. As a start, I created [[key (cryptographic)]] and a first-cut definition for [[key management (cryptographic)]].
| |
| | |
| :: I agree; only a sentence or two & a link or two per secton are actually needed here. [[User:Sandy Harris|Sandy Harris]] 01:42, 31 October 2008 (UTC)
| |
| | |
| :As far as concepts & techniques, avoid the tendency for things that are really not specific to block ciphers, such as key length. Some terminology, however, does need context. '''Whitening''', for example, seems to come out as unique to block ciphers. It is a separate problem that the term gives me an image of a crypto device with a key loader and a funnel for bleach. Seriously, whitening appears to be akin to cipher feedback in DES, but really going back to the historical idea of '''autokey'''.
| |
| | |
| :: Key length is not specific to block ciphers, but it is critically important for them and they are the best-known application of the principle. Also, it has implications for the rest of the design — build your cipher so that no attack is better than brute force, then make brute force (hence all others) impossible with a big key. [[User:Sandy Harris|Sandy Harris]] 01:42, 31 October 2008 (UTC)
| |
| | |
| :While I'm not sure exactly how to rearrange things, the second paragraph of "avalanche" is very well written, and I think some of it needs to move to the section start. Also, the first paragraph is literally hard to read, which I think would improve if things such as n+x became <nowiki><math>n+x</math></nowiki>.
| |
| | |
| :: I re-arranged & re-wrote a bit.
| |
| | |
| :The first part of nonlinearity also seems to belong in more general material; a brief introduction is appropriate, but assume I already know of the principle of nonlinearity and that what I want to understand are the nonlinearization techniques peculiar to block ciphers.
| |
| | |
| :: I think the explanation of how to break a linear block cipher is relevant, and specific to block ciphers. The next section covers non-linearisation techniques. [[User:Sandy Harris|Sandy Harris]] 01:42, 31 October 2008 (UTC)
| |
| | |
| :As a general rule, a single subhead under a higher heading should be merged or moved. "S-boxes as a model of other things" seems orphaned. For example, [[IDEA]] is mentioned, but hasn't been defined or used. Perhaps the IDEA-specific material from this section needs to move into the IDEA section.
| |
| | |
| :: I deleted the heading and shortened the text some; that's now one paragraph. [[User:Sandy Harris|Sandy Harris]] 01:42, 31 October 2008 (UTC)
| |
| | |
| :I'm not sure I'm ready to accept the common flat statement "DES is not secure". It is not secure for appreciable amounts of traffic that need an appreciable time of protection. For something such as a credit authorization transaction with frequent session keys and trusted timestamps, the period for which the information would be useful, and in which a miscreant might create false data, may be quite adequately protected by DES. Agreed that I wouldn't put DES chips into new devices if AES coprocessors are available.
| |
| | |
| :: I avoided a flat statement here, using things like "DES is now considered obsolete and has been replaced by AES" or "DES is no longer considered secure".
| |
| | |
| :: I consider a flat "DES is not secure" to be obviously correct, and to have been correct since at least the early 90s. Diffie and others said 56 bits was inadequate back in the 70s when DES was being standardized, However, if we're going to discuss those topics, it belongs in a historical article, not this one.
| |
| | |
| :: You appear to be subscribing to a fallacy which I attack elsewhere [http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/politics.html#shortkeys]. There is no good reason to use DES, or any other short key cipher, and has not been for years. [[User:Sandy Harris|Sandy Harris]] 01:42, 31 October 2008 (UTC)
| |
| | |
| :::I'm afraid I call the fallacy fallacious. :-) "Secure" is not an absolute. While I absolutely agree it would be insane to put DES into any new system, I also will defend that there are legacy systems in which there is no good reason to tear into a running system and change out short-key crypto in a low-threat environment. There are systems, where, after my initial noises of shock and dismay, urge the replacement activity take place 24/7.
| |
| | |
| :::Threat is also not an absolute. It involves many factors, including the intrinsic value of the information were it either disclosed, or, through falsified cryptographic authetication, had its integrity compromised. The time value of the information is significant, considering both the short-term value of a message, and any knowledge that can be derived from a long-term analysis of messages. NSA used to store warehouses full of Soviet intercepts that they hoped, someday, that they might decrypt, but they've been purging things that relate to things like the Warsaw Pact's plan to invade Western Europe, or generations-old weapons, or things for which the Russians will happily sell the equipment and documentation (onsite technical support available at extra charge). [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 03:34, 31 October 2008 (UTC) | |
| | |
| :Some initial reactions; it's a matter of polishing and organizing. My sense is that from a pure readability standpoint, the details of each specific cipher belong in their own articles; if you are talking about a generation, it's visually useful to see the full list in one or two scrolls. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 17:15, 30 October 2008 (UTC)
| |
| | |
| == An aside of admiration... ==
| |
| | |
| People have been struggling to refer to this decade. The noughts?
| |
| | |
| "The AES Generation" has been echoing in my head since I read it, sort of like one of those TV commercial soundtracks that Will Not Die. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 01:53, 31 October 2008 (UTC)
| |
| | |
| :More seriously, the article gets better with every round of iteration (BAD Howard! BAD Howard!) I know it's frustrating to keep tweaking, and I respect that, as you put it, we have top-down and bottom-up styles.
| |
| | |
| :I am learning from this, and not just in algorithms. Some of our (positive if occasionally frustrating) interaction here have helped me deal with some completely unrelated editorial issues in CZ. It's too bad that you have the access problem with the Forums, but let me assure you that some of the "process" discussion we are having -- how best to have related articles, and maybe some new constructs -- to help users find materials -- are feeding into discussions. Believe me, I can go into the details of a routing or addressing algorithm and get lost in the topic.
| |
| | |
| :Sooner or later, one of the other Computers editors will get some cycles; I do have some articles that I think are ready for approval, with no one to approve (or critique). DNS, I think, is a case where I've found some balance between top-level and more detailed issues, and I hope that you will be commenting on the interactions of DNS as a limited DNSSEC PKI and a more general one for IPSec, as well as all the interactions of security and management with IPv6.
| |
| | |
| [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 14:34, 31 October 2008 (UTC)
| |
| | |
| == Hashes of various sorts ==
| |
| | |
| I created [[hash (disambiguation)]]. Looking through various articles by various people, we have both "cryptographic hash" and "hash (cryptographic)". Do you have a preference? Feel free to modify the disambigution page if you prefer the second, and perhaps you might put in a definition.
| |
| | |
| It's probably not a huge job to collect hash fragments (from the cooking standpoint,that's redundant), put them into one article, and massage it into a coherent article on the general technique. That would point up, at least, to integrity and authentication applications in [[information security]].[[User:Howard C. Berkowitz|Howard C. Berkowitz]] 16:46, 31 October 2008 (UTC)
| |
| | |
| : I've used "cryptographic hash" in text. One reason I have not started an article yet is that I'm not sure what the name should be.
| |
| | |
| : Where are the fragments? I'm working bottom-up here; [[block cipher]] is near done; [[stream cipher]] nowhere near done but as far as I want to take it. Hashes are the obvious next thing, the only major crypto primitive not covered yet.
| |
| | |
| : We changed "cryptographic snake oil" to "snake oil (cryptography)". My guess is this one should be [[hash (cryptography)]] (not "cryptographic") with [[cryptographic hash]] and [[message digest]] redirecting to it. But those are at least partly policy decisions, related to the overall CZ naming scheme. Should [[cryptographic hash]] exist as a redirect, or should all the links be <nowiki>[[hash (cryptography) | cryptographic hash]]</nowiki>? Should the more formal [[message digest]] or [[message digest algorithm]] be the main title with [[hash (cryptography)]] as the redirect? I'll happily defer to a editor on such questions.
| |
| | |
| : There are related questions. I think policy would be to have [[Hashed message authentication code]] with a redirect from [[HMAC]]. Fine there, but are MD4 and MD5 exceptions? AFAIK no-one uses the formal name, so perhaps they should be. | |
| | |
| : What about the SHA family? The top article is [[Secure hash algorithm]], but how many articles & how are the rest organised? There was the original SHA algorithm. Then NSA added a one-bit rotation (which they refused to explain) to create SHA-1; that's what people generally mean when they say "SHA". Then NIST standardised SHA-2 which has several variants; SHA-224, SHA-256, SHA-384, SHA-512. Now they are running an [[AHS contest]] to create an [[Advanced hash standard]], also known as SHA-3, also supporting 224, 256, 384 & 512-bit sizes.
| |
| | |
| : I think we need articles on the topics linked to in the previous paragraph; not sure if we need more. I'd like the hash article organised much like [[block cipher]], with AHS candidates instead of AES at the end. [[User:Sandy Harris|Sandy Harris]] 01:53, 1 November 2008 (UTC)
| |
| | |
| ::Overall naming scheme? The substance of many discussions is about all. Your guess, on this, is as good as mine. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 02:06, 1 November 2008 (UTC)
| |
| | |
| == Some context and compromise about "being secure" ==
| |
| | |
| Recently, you've said, with respect to DES, "With an intelligence agency budget, it is crackable in seconds." I completely agree. Earlier, you said that the EFF custom system and large agencies can break it promptly. With that I do not agree.
| |
| | |
| : I give a link to a $10,000 off-the-shelf system that finds a DES key in a week, given one known plaintext. [[User:Sandy Harris|Sandy Harris]] 15:50, 3 November 2008 (UTC)
| |
| | |
| ::And the likelihood some private person is going to buy it to break the circulation system at the town library? Again, Sandy, may I suggest directly answering the issue: "does DES need to be replaced in any systems where it is now used"? Remember, there are costs of doing so. The desirability of moving to an AES-native system might justify moving to a new operating system. I'm thinking, however, of legacy applications that are the only things on the machine that access a purpose-installed DES software library.
| |
| | |
| ::I advise on some hospital systems, where encryption of any sort is not legally required on the LAN, although many use single DES. Before I would tell some of those clients to move in AES, I'd suggest they do some things with biometric authentication -- and move workstation off counters where they are easily visible to the passing public. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 16:03, 3 November 2008 (UTC)
| |
|
| |
| I would never advise a client to put DES in a new system. Indeed, I've set up housemates' PCs with longer than minimal AES key lengths.
| |
| | |
| My concern, however, is, especially in the articles on a specific kind of cryptosystem, the insistence that any particular encryption technology is completely insecure. Remember, not everyone reading this is going to have expertise in system-level security assessment; perhaps I should write a risk-benefit analysis, at a more general level, in [[information security]].
| |
| | |
| : Yes, but then we'd likely argue on that talk page. :-)
| |
| | |
| ::But it's a valid argument, with very real-world impacts. Security is not limited to or defined by crypto. Again: we do not disagree about using AES in new systems, or, if it's a relatively simple matter of changing calls to OS-supported encryption, to changing under proper version control. I have to think long and hard, however, if changing DES is the first security issue for legacy applications for organizations to which $10,000 would be a lot of money. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 16:03, 3 November 2008 (UTC)
| |
| | |
| As I have said, I can see no reason to install DES in anything new. Good software and coprocessor applications are readily available. Try to picture a reader that interprets "not secure" as "essentially broken by their children", and might, in some panic, tear apart legacy applications to replace DES with AES. Since such a reader is not experienced with software modification, that reader might wind up with a completely secure machine, which won't work at all.
| |
| | |
| Here's the kind of user and application I have in mind. A local library I know is very concerned about patron privacy. Some time ago, when DES was all that was readily available, they put it on the book checkin-checkout LAN and computers, and perhaps a few reference machines not connected to the Internet. Given semi-small-town politics, I could easily picture someone coming in, who knew they were using DES, and start demanding AES conversion. They aren't physically secure. Hard copies of overdue book lists are common. There would be little to stop a surveillance agent, in the parking lot, from aiming a telephoto lens through the window near the checkout, and read the screen. Replacing DES with AES may break their application if they don't know what they are doing, and, assuming they want the strong privacy policy to continue, divert resources from things that actually will improve their security: lock up and shred overdue book lists if the volunteers have to have them in hard copy, put a light curtain on the window/turn the checkout terminal screen away from the window/put an optical guard on it.
| |
| | |
| Your point is well taken for new applications, especially when there is a serious threat. There are, however, a huge number of existing, low-risk applications where cryptanalysis is the lowest of threats. The article should not scare people; I believe it is in [[information security]] where the tradeoffs should be. In this article, it's perfectly appropriate to say what intelligence agencies, EFF, and even Internet cloud computing can do to DES, but in quantitative cost and power terms. Give the person looking at all risks consider the overall problem for the existing systems, and whether a new backup drive, or being sure to run basic anti-malware software, or to put certain files on a USB drive and lock it up when not in use. Could you even buy a DES USB drive any more? [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 14:22, 3 November 2008 (UTC)
| |
| | |
| : I've rewritten a bit. [[User:Sandy Harris|Sandy Harris]] 15:50, 3 November 2008 (UTC)
| |
| | |
| ::This looks good. Now you are making me wonder if any of the classical writers measured Achilles' vulnerable heel length. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 17:28, 3 November 2008 (UTC)
| |
| | |
| == Tiger hash ==
| |
| | |
| While I really don't want a full-sized house tiger, I am happy that was clarified to be an algorithm, rather than chopped and fried tiger. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 00:14, 29 November 2008 (UTC)
| |
| | |
| : I live in China. I'll bet I could find edible tiger products. It sometimes seems they use most things as food and ''everything'' as medicine. [[User:Sandy Harris|Sandy Harris]] 07:10, 29 November 2008 (UTC)
| |
| | |
| == Approval?==
| |
| I've just shortened the "Context" section radically, moving text that did not really belong here to [[cryptanalysis]] and deleting material already copied to [[cryptography#keying]] or [[hybrid cryptosystem]].
| |
| | |
| I think that was the last big thing that needed doing before approval. Is it now ready? Checking history, I find I'm the only editor ever, except for one format fix early on by Hayford Pierce. [[User:Sandy Harris|Sandy Harris]] 05:00, 16 April 2009 (UTC)
| |
| | |
| :Some copy editing needed on references, which I can do if permitted for (presumed) single-editor approval. In most cases, it will work better if you use "citation" rather than "cite paper"; not all the bibliographic references show up with cite paper -- where posible, provide links. For the book references 1 and 2, put the name of the books in double apostrophes rather than quotes, so the will italicize. Also, the text reference to a marginal website should move from the articles to external links.
| |
| | |
| :: done. [[User:Sandy Harris|Sandy Harris]] 09:20, 16 April 2009 (UTC)
| |
| | |
| :That's all I immediately saw, just waking up and going back to bed soon. Given the number of options, it might be a little easier to read with some summary/comparison tables; I want to think if anything is long enough to justify a subarticle, or if the structure is such that the moderately interested reader can get adequate detail without going through every section. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 07:09, 16 April 2009 (UTC)
| |
| | |
| :: Good questions. I'm not sure of the right structure either. Also, as we both said above, getting more eyes would be good; not sure if it is possible. [[User:Sandy Harris|Sandy Harris]] 09:20, 16 April 2009 (UTC)
| |
