Talk:Block cipher/Draft: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Sandy Harris
imported>John Stephenson
m (moved Talk:Block cipher to Talk:Block cipher/Draft over redirect: Cannot get the banner info on approved-article Talk pages to show with Citable Versions subpages, so moving this whence it came for now)
 
(115 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'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.
<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>


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


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


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


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?
:::: 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)


: Did that. Still wonder about policy, though. [[User:Sandy Harris|Sandy Harris]] 10:01, 26 October 2008 (UTC)
:::::I can still go with the approved version. As the fates have it, I have a one-word correction that should have been applied earlier -- not an outright error but a clarification. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 00:02, 2 December 2009 (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? [[User:Sandy Harris|Sandy Harris]] 06:11, 25 October 2008 (UTC)
:::::: Good news.  All's well that ends well.  Let's leave this approved version as is and you guys can work out your new one word correction on the draft and call us back if you need it to go into the Approved version. [[User:D. Matt Innis|D. Matt Innis]] 00:11, 2 December 2009 (UTC)


== Organization of "Principles and techniques" ==
:::::::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'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.
::::::::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)


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.
:::::::::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 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)
===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]]


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


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?
== Re-approve? ==


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


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)
== Approval Process: {{ApprovalProcess|certify}} ==


: Thinking. Will think & look more.
''Call for review: ''[[User:Sandy Harris|Sandy Harris]] 03:42, 8 June 2012 (UTC)


: 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)
''Call for Approval: ''[[User:Anthony.Sebastian|Anthony.Sebastian]] 01:59, 18 June 2012 (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)
''Approval Notice: ''[[User:Anthony.Sebastian|Anthony.Sebastian]] 03:55, 6 September 2012 (UTC)


== Safe and unsafe ==
''Certification of Approval: ''[[User:Anthony.Sebastian|Anthony.Sebastian]] 03:56, 18 September 2012 (UTC)


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 &mdash; 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.
----
''Please discuss the article below, [[{{BASEPAGENAME}}/Approval]] is for brief official referee's only!''
=== Comments ===


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


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)
: 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?
== Move modes? ==
: 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)
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)
 
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)

Latest revision as of 14:28, 2 October 2013

This article is developing and not approved.
 Main Article
 Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
Catalogs [?]
 

APPROVED Version 1.0

Discussion for Version 1.0 stopped here. Please continue further discussion under this break.
I don't see that Howard actually saw these edits or endorsed them. Peter did, though. Howard, are you okay with this those changes? D. Matt Innis 22:16, 1 December 2009 (UTC)
Howard had approved a version through a couple of days ago, and that's the one I was *going* to OK, not a more recent one that had about a single space added to it. Then I saw today that the latest version had been updated by the editors so that it was the most recent one. So that's the one I approved. How am I supposed to figure out that, apparently, Peter approved the later one but not Howard. Where's Joe the Approvals Manager? Why, for once, can't people just give me a nice clean version to approve!!!??? Hayford Peirce 22:31, 1 December 2009 (UTC)
Sorry, I thought I did it correctly ... Wasn't I supposed to join in, or isn't it o.k. to update to a more recent version? Peter Schmitt 23:04, 1 December 2009 (UTC)
No, Peter, you did fine - exactly as you were supposed to do. In fact, with your endorsement, it's still a single editor approval, it's just that Howard's name is on it, too. However, the last version he apparently saw was on November 24 (17 edits earlier). Therefore, he either needed to show he approved those edits by making a statement to that effect here on the talk page. If he doesn't approve, the approval can still stand because you approved this version. So, really it's just a matter of whether Howard wants his name on this same version. All he has to do is let us know. D. Matt Innis 23:44, 1 December 2009 (UTC)
I can still go with the approved version. As the fates have it, I have a one-word correction that should have been applied earlier -- not an outright error but a clarification. Howard C. Berkowitz 00:02, 2 December 2009 (UTC)
Good news. All's well that ends well. Let's leave this approved version as is and you guys can work out your new one word correction on the draft and call us back if you need it to go into the Approved version. D. Matt Innis 00:11, 2 December 2009 (UTC)
Well, that's last time I will ever approve or reapprove an article that Joe the Manager hasn't specifically told me to. Hayford Peirce 00:36, 2 December 2009 (UTC)
Hehe, this one is no big deal. Just be most careful with the controversial ones :D D. Matt Innis 00:54, 2 December 2009 (UTC)
Yes, it is a big deal -- it means that it's taken two Cops to do what one should have been able to do. If I can't do it correctly the first time, then I won't do it again. And I can't do it correctly if Joe the Manager doesn't tell me *explicitly* precisely which version to approve. As I said above, and I mean it seriously, if I don't get a go-ahead from Joe in the future on an approval or re-approval, I simply won't do them. Hayford Peirce 03:08, 2 December 2009 (UTC)

Questions

Howard, what's your one-word change? We can make it on the draft? Also, is it time to archive most of the talk page? Sandy Harris

Add to "In theory, any block cipher can be broken by a brute force attack"...so the statement doesn't conflict with one-time pads. Yes, it's time to archive. Howard C. Berkowitz 03:47, 2 December 2009 (UTC)
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. Sandy Harris 03:26, 27 November 2010 (UTC)

Re-approve?

The current approved version is from 2009. I have made a number of changes since then. I'd say it needs re-approval, and is ready for that.


Approval Process: Approval certified

Call for review: Sandy Harris 03:42, 8 June 2012 (UTC)

Call for Approval: Anthony.Sebastian 01:59, 18 June 2012 (UTC)

Approval Notice: Anthony.Sebastian 03:55, 6 September 2012 (UTC)

Certification of Approval: Anthony.Sebastian 03:56, 18 September 2012 (UTC)

Please discuss the article below, Block cipher/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.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. Sandy Harris 05:40, 8 June 2012 (UTC)
Retrieved from "https://citizendium.org/wiki/index.php?title=Talk:Block_cipher/Draft&oldid=529515"