Talk:Cryptography/Archive 1

BigCleanup deleted items

[[Image:Lorenz-SZ42-2.jpg|thumbnail|320px|The [[Germany|German]] [[Lorenz cipher]] machine, used in [[World War II]] for encryption of very high-level general staff messages]] [[Image:Skytala&EmptyStrip-Shaded.png|thumbnail|The Ancient Greek [[scytale]], probably much like this modern reconstruction, may have been one of the earliest devices used to implement a cipher.]] [[Image:Nsa-enigma.jpg|240px|thumbnail|left|The [[Enigma machine]], used in several variants by the German military between the late 1920s and the end of [[World War II]], implemented a complex electro-mechanical [[cipher]] to protect sensitive communications. [[Cryptanalysis of the Enigma|Breaking the Enigma]] cipher at Polish [[Biuro Szyfrów]], and the subsequent large-scale decryption of Enigma traffic at [[Bletchley Park]], was an important factor contributing to the Allied victory<ref name="kahnbook" />.]] [[Image:Smartcard.JPG|thumb|250px|A credit card with [[smart card]] capabilities. Smart cards attempt to combine portability with the power to compute modern cryptographic algorithms.]] [[Image:International Data Encryption Algorithm InfoBox Diagram.png|thumbnail|One round (out of 8.5) of the [[patent|patented]] [[International Data Encryption Algorithm|IDEA]] cipher, used in some versions of [[Pretty Good Privacy|PGP]] for high-speed encryption of, for instance, [[electronic mail|e-mail]]]] [[Image:Diffie_and_Hellman.jpg|thumb|left|[[Whitfield Diffie]] and [[Martin Hellman]], inventors of public-key cryptography]] [[Image:Firefox-SSL-padlock.png|thumb|161px|right|Padlock icon from the [[Firefox]] web browser, meant to indicate a page has been sent in SSL or TLS-encrypted protected form. But note that a properly subverted browser might mislead a user by displaying some similar icon when a transmission is not being protected by SSL or TLS. Security is not a straightforward issue.]] {{Cryptography portal}} {{Crypto navbox}}

Do not delete please Robert Tito | Talk 14:43, 19 February 2007 (CST)

Shannon

In his 1946 and 1948 publications made clear what cryptography should be (refs follow) Robert Tito | Talk 00:50, 21 February 2007 (CST)

Article title, structure, relationship to other articles

While I've made edits to this article, I didn't originate it, and I have been wondering if a full rewrite is in order, with the understanding that many topics need to be introduced briefly here, with elaboration in their own articles. Even the title might well be tweaked — cryptology is not a subset of cryptography; cryptography is a subset of cryptology. Personally, I prefer to introduce cryptanalysis only after first introducing the basics of signals intelligence and communications intelligence, since there are many ways to attack a secure communications system.

I agree that the numbers about brute force attacks on DES were not helpful. Pure numbers are rarely that useful for assessing cryptographic strength, since brute force is the last thing to try. DES, if for no other than historical reasons surrounding its development and controversies, does deserve its own article.

As to symmetric vs. asymmetric cryptography, I quite deliberately avoided "public" and "private", which are totally appropriate in a sub-article on public key cryptography. At the level of an introduction, however, I have found it much more useful to start with "secret" vs. "other" keys, because "secret" is much more convenient when starting with a compare-and-contrast about symmetric versus asymmetric. A person new to the subject needs to know that both types must have a secret "something", with a flag that asymmetric cryptography has other features.

One of the reasons for having a sub-article on public key is to address key management, public key certification, and certificate revocation.

I'm concerned that some of the subsections here are jumping too quickly into mechanics without setting enough background.

Let's discuss a structure of crypto articles, and try to come up with an introduction and a logical set of more detailed subarticles. From my perspective, I can build and run a secure network, with multiple layers of security -- but I don't need to know how partial elliptical algorithms work. ...said Howard C. Berkowitz (talk) 13:45, 1 August 2008

Yes, we need such discussion. I've started some at Talk:Random_number and there is some at Talk:Cryptographic snake oil.

Meanwhile, I'm starting from the links in cryptography and cipher and trying to create at least stubs for most of the articles they point to. Examples so far One-time pad, Brute force attack, random number, ... Sandy Harris 12:20, 4 August 2008 (CDT)

General review, comments, and directions

Other Computers or Mathematics Editors, please add your comments. At this point, I'm mostly wearing my Editor hat and bringing up issues here. Previously, I had made some edits in the article, but there is just a hint of revert war beginning. Another matter of concern is that when I questioned some additions, a new article cryptographic snake oil suddenly appeared, not linked to this one.

I'm increasingly concerned that this article is rapidly growing, but its structure is harder to follow, suggesting some careful thinking about an outline and sub-articles may be appropriate. In some cases, there's a link to a stub or null article, and, when there is a live link, the two articles need a bit of text showing how they relate to one another — there are ways that a reader could have independently gotten to either topic and, without crosslinking and preferably compare-and-contrast text, there's no way to see a potentially useful relationship. Howard C. Berkowitz 11:15, 2 August 2008 (CDT)

One-way encryption

In the first CZ introduction to the topic, there's relatively little explanation of why one would want one-way encryption, such as error detection, digital signatures, authentication, atomic integrity protection, and sequential integrity protection. The general CZ reader, certainly not in a software-specific article, cannot assumed to be a programmer. Block diagrams or parables often are better ways to introduce a concept than bursts of code or hexadecimal. Howard C. Berkowitz 11:15, 2 August 2008 (CDT)

I never heard of one-way encryption before. From the page One-way_encryption, I cannot see any difference to an ordinary hash function. There is the security notion of being a one-way encryption (Fujisaki and Okamoto, CRYPTO '99), but that is not what is described in the article. Is there a reference to who introduced this terminology? If not, I would propose merging the text into the Cryptographic_hash article and referencing the hash and the notion in the OWE article. Mario Strefler 02:07, 1 December 2008 (UTC)

Good idea. I did not introduce the term & don't think it rates the importance the article currently gives it. See #Rewrite? below. Note, though, that it can be done with a block cipher rather than a hash, e.g. the original UNix password system used DES [1]. Sandy Harris 03:13, 1 December 2008 (UTC)

Two-way encryption

"Some approaches are said to be two-way because text messages are both encrypted and decrypted. " reads, to me, as if two-way encryption is a special case, as opposed to the most common form of cryptography literally going back over two millenia.

Before leaping into asymmetrical vs. symmetrical cryptosystems, the general reader is likely to want a description of when two-way encryption is appropriate; some very general commentary that not all two-way systems are equal and there frequently needs to be a balance among cryptographic strength, convenience, and cost; perhaps a few application examples such as the millenia-old examples in military and diplomatic communications, and moving to personal uses (a distinction between secrecy and privacy would not be out of place here). ' Again, this has to be assumed to be a first encounter in a general article, and a Caesar cipher (ROT13 if you will) is a much more appropriate introduction than DES, single or triple. Howard C. Berkowitz 11:15, 2 August 2008 (CDT)

I'd say this needs to come first, before the special cases in "one-way encryption". Sandy Harris 11:57, 4 August 2008 (CDT)

Agreed. I think my ZEBRA examples might be a little simpler than Caesar, but he certainly needs to be mentioned for historical background -- and that the Russians still used his technique in WWI. Howard C. Berkowitz 12:20, 4 August 2008 (CDT)

Cryptanalysis

Consider first readers again. The lead doesn't mention the most basic of cryptographic techniques, frequency analysis, which was significant for centuries. The next steps in introducing cryptanalysis usually start talking about polyalphabetic substitution, which is only discussed late in the article, in "History". Before calling something a modern version of Alberti, and a discovery described as the greatest thing since polyalphabetic substitution, the history section should have prepared the new user, perhaps with a link to more detailed examples in cipher. Things like differential cryptanalysis are appropriate for subarticles, quite likely on that subject alone. Howard C. Berkowitz 11:15, 2 August 2008 (CDT)

Legal issues

The NSA, DES-related material is very incomplete. Rather than going off into differential cryptanalysis, a good starting point might be the challenges when DES was first introduced, and, among other things, the Congressional challenge that involved independent review under the authority of the Senate Intelligence Committee. The major issue at the time was whether NSA had weakened the key to provide a back door. At the time, I was the network architect for the Library of Congress, but also a member of the Federal Telecommunications Standards Committee of the National Communications System, so I could talk to politicians, privacy advocates (I like to think of myself as such), but also NSA.

CZ has a stub on DRM, and only a definition of intellectual property. This narrative seems to assume that the reader understands the motivation, legal context, and enforcement of DRM. Howard C. Berkowitz 11:15, 2 August 2008 (CDT)

Action?

I believe getting some consensus on a list of articles, and approximate readership level, is appropriate. Howard C. Berkowitz 11:15, 2 August 2008 (CDT)

I've put up a proposed outline at Cryptology. Howard C. Berkowitz 12:20, 4 August 2008 (CDT)

"Secret" versus symmetric -- or using both

I agree with Pat Palmer that symmetric/asymmetric is certainly more logical. In teaching, I've tended to use "secret key" early in the discussion, until the learners start picking up the nuances. From my perspective, there are several instructional reasons to do this -- and remember my students tend to be in industry classes, so there may be more FUD about learning new things that with voluntary college students.

1. Secret is not a new, scary technical term.
2. If one is speaking of symmetric cryptography, including the repeated changing of a session key during a session initialized with much stronger asymmetric algorithms, there is something real and secret.
3. "Secret" helps explain the importance and challenges of key distribution, whether it's an asymmetric private key or a symmetric key.
4. When getting into asymmetric cryptography, I find it helps to remind students about the opposite usages for authentication and confidentiality; your private key encrypts the digital signature for authentication, while both ends use the other's public key to encrypt for confidentiality.

Howard C. Berkowitz 21:16, 5 August 2008 (CDT)

I'd use "secret key" and "public key" as section headings and in introductory text, but give the synonyms early and use them when it made sense in more technical discussion. Sandy Harris 21:36, 5 August 2008 (CDT)

I like that approach, Sandy. Howard C. Berkowitz 21:47, 5 August 2008 (CDT)

Level and branching to subarticles

In its present form, the article is likely to be overwhelming for someone new to cryptography. In its subarea, this is a "core" article, so should be define "what" rather than "how" or "why". Given the number of concepts to introduce, I don't think this article should be containing any details of theory, any details of algorithms or their strength, etc.

That material should be in CZ, and quite possibly at a greater level of detail, but in separate articles --- probably articles rather than subpages. Ironically, although I still object to the title of that article, I believe that a balanced presentation of many of the ideas in cryptographic snake oil belong here. What do I mean by balanced? I mean there should be a section on selecting a cryptosystem for a specific purpose, addressing how, in general, to state the requirements, and then sections on the "what" of finding good and bad products. Just as an example, one could say "watch out for claims about 'as good as a one time pad'". If the vendor doesn't say this, no problem. If he does, then ...link to the issues...

Actually, before cryptography, there should be a section on "attributes of a secure communication", which is more the broader problems for which cryptography, of different types, is part of the toolbox. Here, I'm thinking about client and server authentication, atomic (record level) and sequential (file level) integrity, content confidentiality (the core of what most people think is crypto), nonrepudiation, etc. I have some material on this that I've written, and can edit into CZ-suitable form later today. Howard C. Berkowitz 11:16, 8 August 2008 (CDT)

Material at too advanced a level for core article.

First, I moved the following from the article:

Because 56 bits is too small to withstand brute force attacks, DES is utterly insecure against modern attacks.

Triple-DES is a way to use DES and still achieve security. It applies DES three times: encrypt, decrypt, then encrypt. Either two or three DES keys can be used. A 192-bit key has 2¹⁹² possible keys, so a brute force search of all keys is wildly impractical. A meet-in-the-middle attack is better, requiring only 2¹²² encryptions, but this is still impractical.

Is it reasonable to assume that someone reading this article, as an introduction, will know the difference between an attack by a brute or a ballerina? Will they understand meet-in-the-middle attack? Will someone not familiar with computer based encryption know how significant the number is -- what is practical in this context? It only says what is impractical.

Some discussion on protecting the key follows. While I haven't gone over it closely, that's certainly a reasonable issue for beginners.

The next section, "theoretical underpinnings" of any encryption would seem to belong in a linked article. The article seems to assume the reader will understand " block ciphers and stream ciphers and to their applications. A block cipher is the modern embodiment of Alberti's polyalphabetic cipher..."

Howard C. Berkowitz 13:32, 8 August 2008 (CDT)

Legal issues

In the U.S., NSA is not the only agency interested in suppressing commercial strong crypto. It is worth exploring if there might be rationales, among domestic law enforcement as well.

Other countries,at various times, have made stronger restrictions. Among others, Australia limited to 40-bit key. France and Russia insisted on key escrow. THis issue, while I regard it as futile, is not limited to the U.S. Howard C. Berkowitz 13:50, 16 October 2008 (UTC)

Certainly not. For starters, there's the Wassenaar agreement where many countries have controls on "dual use" items, things with both civilian and military uses. One reference that covers Wassenaar is [2]. That is out of date and much more advocacy than encyclopedic in tone, but perhaps useful.

The standard reference on crypto laws worldwide is [3]. The guy who maintains the site did a PhD on the topic; the thesis is available on the site. One of his students has a similar page on digital signature laws. Sandy Harris 14:42, 16 October 2008 (UTC)

We have two sections titled "Legal issues" on this page. Merge them? Change one title? Sandy Harris 14:47, 16 October 2008 (UTC)

I meant on the talk page. Sandy Harris 01:26, 17 October 2008 (UTC)

Rewrite?

I think we need to re-order and rewrite most of section 2 in the article. Deal with the issues listed above under "secret vs symmetric" and "Two-way encryption", remove redundancy such as the symmetric/asymmetric distinction being explained twice (Cryptography#Two-way_encryption and Cryptography#Paradigms_of_encryption), generally clean it up.

Here's my outline:

Start with secret key encryption; goal is privacy, there's a long history (link) and two basic methods, block cipher (link) and stream cipher (link). Enough text here to cover basic ideas, details in linked articles, Link to cryptanalysis as well. Discuss the key management problem in some detail, enough to lead into ...

Public key encryption, first presented as a solution to the key management problem. Mention that it also gives digital signatures, but leave details for later. Links to RSA, etc.

Cryptographic hashes (link) and HMAC (link). Basic discussion of the security requirements they meet, link to communications security for details.

Digital signatures (link); easily explained once public key & hashing are understood.

Hybrid systems, with PGP (link) as first example. Moderately detailed discussion of how it all fits together. Mention other hybrids like TLS, SSL and IPsec, giving only a light overview and the links.

Higher-level systems: PKI (link), Kerberos (link), ...

Special requirements: disk encryption, one-way encryption for passwords, ...

I'm not likely to do this soon; I want to finish block cipher first. Volunteers? Comments? Sandy Harris 12:41, 23 October 2008 (UTC)

Understood; I have some of my own priority items as well. As I look at what I just wrote below, I'm going to clone it to the Computers WG page, and maybe Military as well; there are some good principles.

A number of these (PGP, SSL/TLS, etc.) deserve articles, and you may want to make the conscious decision to create stubs -- I am leaning more and more not just to leaving a pink (magenta? red?) link, but at least going and creating the page, if only I copy the introduction from the main article. I don't necessarily fill out all the metadata, but I am finding shortcuts -- I often copy, and then just slightly edit, the definition. I don't believe definitions are useful for most articles themselves, but Chris Day is getting me more and more convinced of the need for definitions for use in R-templates on Related Articles and Disambiguation pages.

When creating stubs, think long and hard about the title. There is a proposal to allow separation between the internal page name and the title, which will help a lot. Otherwise, for an assortment of reasons, disambiguation from other fields' usage of the term being the most important, think long and hard before using an abbreviation as a title. IPsec is a legitimate exception, although there probably need to be IPSec and IPSEC redirects, as well as Internet Protocol Security (and maybe IP Security Architecture).

I'm strongest on the lower layers aspects, as well as some, but not all, deployment issues -- especially when military or medical requirements are involved. I have (well, not since I was 13) claimed to be an originator of cryptographic algorithms; if anything, I'm more interested in SIGINT.

I really would appreciate some help on properly naming, and then expanding a bit communications security, so that becomes something of an index -- I'd like it to have both pure computer and pure telecom topics, which really do fit into that structure if done well. Auditing is something that can branch. There's been a pilot of an interdisciplinary workgroup with chemical engineering, which appears to also create some very logical places for specialized Editors. Security might well be such a topic. Howard C. Berkowitz 14:59, 23 October 2008 (UTC)

I have started this rewrite at User_talk:Sandy_Harris/Sandbox, will post here when I think it is done. Sandy Harris 04:54, 13 December 2008 (UTC)

It is done. I have put it into the article. The text it replaced is at User_talk:Sandy_Harris/Saved; referencing it there may be easier than using history. Sandy Harris 11:28, 16 December 2008 (UTC)

Apropos "cryptography is difficult"

Somewhere, although it's around in the one widely known example at the Battle of Midway, there are reasons, at least in the military, to have cryptosystems with a known weakness: they can become a useful way of passing deceiving information to an enemy. In electronic warfare, there are usually waveforms and frequencies designated "war reserve" or the equivalent; the day-to-day pseudorandom radar pulses may have a pattern the designer wants the enemy to figure out, not easily, and become complacent. Just when you think you know the other side's signals, when they are flying in and breaking things is not the time you want to discover that you didn't really understand.

I don't know of uses of a deception channel like this in the civilian world, but I wouldn't be surprised if it has happened. Mining exploration might be one area; until there was significant electronic commerce, I was surprised to discover that mining & oil companies made up a significant part of the revenue of Hagelin AG. Howard C. Berkowitz 15:41, 23 October 2008 (UTC)

I've added a sentence to the introduction mentioning that having to worry about an adversary makes design harder. Not sure where deceptive tactics would fit in, if at all. Sandy Harris 00:17, 24 October 2008 (UTC)

If you will, it generally doesn't fit into crypto proper at all, but with the use of crypto. To take it from a different standpoint, building a back door for one's own spooks could be part of design, but building what you WANT found as a back door is something else again. Howard C. Berkowitz 00:19, 24 October 2008 (UTC)

Do note my hysterics at "Why Johnny can't encrypt". Well done! Howard C. Berkowitz 01:18, 9 December 2008 (UTC)

Article clarity

Hi, a couple of quick comments based on an even quicker review.

First, I definitely agree with the comments above (at #General review, comments, and directions and #Level and branching to subarticles that the article is likely to be too long, and too in-depth, for someone who wants an introduction to the subject.

The following sections seem to me like good candidates for separate articles, with only brief (i.e. 2-3 sentences), high-level descriptions here:

• Two-way encryption
• Symmetric key encryption
• Asymmetric key encryption
• Generating session keys (needs better title for an article, though - maybe just plain "Session keys", then GSK could be a big section of that)
• Digital signatures
• Legal issues involving cryptography (again, needs a rename as an article - probably "Legal issues of cryptography", or somesuch) - each of the following three sections could get a sentence or two here
• Digital rights management (definitely needs a separate article, as this is a topic of interest in its own right)

The following are so off the main thread of the concept I'd not even put in the 2-3 sentences, but simply list them under 'See Also' (may also need new titles):

• Protection against record modification
• Protection against file modification
• Protecting stored passwords

Comments? J. Noel Chiappa 15:56, 24 October 2008 (UTC)

Clearer lede

Second, the lede isn't as crisp, flowing, and simple as it could be. How about something like this:

Crytography is the transformation of information into a form which cannot be understood by anyone except to those who are granted access to it. Encryption is the act of turning plain text into cipher text, and decryption is the act of turning cipher text back to plain text. By encrypting a message, we can be fairly certain who sent it, fairly certain that others can’t read it, and we can determine that the message likely has not been altered. If someone scrambles a message to make it illegible, the original message is called plaintext, and the scrambled message is called ciphertext.

Cryptography has been in use for three millenia, during which time it has become enormously more complex (due to the success of attackers); it is now based on very advanced mathematics. It has now found many practical applications related to security and reliability in computers, especially when connected to networks. Cryptography is central to digital rights management (DRM) in computers and is important in the fields of computer science and engineering, as well as mathematics.

Prior to the early 20th century, cryptography was chiefly concerned with linguistic patterns; since then, the emphasis has shifted, and cryptography now makes extensive use of mathematics, including aspects of information theory, computational complexity, statistics, combinatorics, abstract algebra, and number theory. Cryptography is also a branch of engineering, but an unusual one as it deals with active, intelligent, and malevolent opposition (see cryptographic engineering and security engineering). There is also active research examining the relationship between cryptographic problems and quantum physics (see quantum cryptography and quantum computing).

As well as being aware of cryptographic history, cryptographic algorithm and system designers must also carefully consider probable future developments in their designs. For instance, the continued improvements in computer processing power in increasing the scope of brute-force attacks must be taken into account when specifying key lengths, and the potential effects of quantum computing are already being considered by good cryptographic system designers.

The "when literacy was rare, writing could be considered a means of obscurement" probably belongs in the history section, if anywhere, because I'm not sure it's true. (If the info wasn't written down, it was presumably memorized, at which point interrogation would be the means to retrieve it. A written message would I guess be one way of defeating that, if none of the attackers could read. So maybe it is correct.) J. Noel Chiappa 15:56, 24 October 2008 (UTC)

Quasi-outline

I'm wandering about writing stuff, mostly bottom-up and sometimes initially incoherent. It sees worth putting something outline-ish here to let others know about it.

Try to cover the main crypto primitives. I think block cipher is pretty good by now; stream cipher, and hash (cryptography) are stubs. Then the next layer up, things like digital signature and hybrid cryptosystem, both stubs now. Lots of other things like CAST-128 or Feistel cipher are currently redirects into block cipher, should likely become separate articles later.

Some stuff on attacks that perhaps should be covered in cryptanalysis, but I felt more confident writing as separate articles. Main ones are passive attack and active attack each linking to several actual attacks. There's also birthday attack. I have not tried to write linear cryptanalysis or differential cryptanalysis; I have only a general understanding of those and could not do an article that would be useful above a high school level. I added some stuff in cryptanalysis on known plaintext attacks, but have not tried to do anything like a complete classification of attacks that way, and likely will not.

I've also started articles on related things, PGP, Diffie-Hellman, discrete logarithm, RSA, IPsec, FreeS/WAN, opportunistic encryption, cypherpunk.

Next? I want to get rid of more red links, go through various articles and create at least stubs for things linked to. Also improve cryptographic hash which is currently horribly incomplete. Once the lower levels are a bit firmer, I' want to rewrite cryptography along the lines discussed earlier. Sandy Harris 01:31, 26 November 2008 (UTC)

Thinking out loud here, while we have a number of Citizens with expertise in these areas, they may not be aware of the specific talk page discussions. As I think you suggested, it might be a good idea, eventually, to have an interdisciplinary Cryptography workgroup, which pertains, at least, to Mathematics, Computers and Military, and quite possibly other areas. Maybe "practical cryptanalysis" comes under Health Sciences (use of rubber hoses to get the key) or Enginering (safecracking). :-) Alternatively, you might want to put the discussion, for now, on a talk page (or new talk page) under the Computers Workgroup, and send an email to all relevant workgroup lists. If you can get to the Forums, announce it there, or if you can't, send me text and I'll post it.

Nothing wrong with your idea, Sandy; I'm just trying to think of the best way for people to know about it and participate. Howard C. Berkowitz 12:28, 26 November 2008 (UTC)

I can reach the forums today. Posted something on computers forum. Sandy Harris 13:12, 26 November 2008 (UTC)

Since it is interdisciplinary, you might want to post to one of the non-workgroup forums; I can't think of exact names, but article and article policy? Howard C. Berkowitz 13:25, 26 November 2008 (UTC)

I'd say crypto overlaps significantly with law as well as the areas you mention. I've no idea of the procedure for starting a new workgroup or interdisciplinary group. I cannot see crypto as a workgroup on the same level as math or computers; it's not big enough or distinct enough for that. But, yes, some sort of interdisciplinary group would be good. I'm not going to follow up on that anytime soon, though. Sandy Harris 05:48, 27 November 2008 (UTC)

Here's the stuff Larry wanted moved, nowiki'd; I don't have the energy to insert blank lines or take the headings a level lower right now. See also information security.

==Underlying principles== {{r|Information theory}} {{r|Random number}} *Statistical characteristics of language *Computationally intractable problems ==Methods of proving information is correct or has been transferred== ===Authentication=== ====Sender authentication==== =====Digital signatures===== =====Key management===== *{{r|Public Key Infrastructure}} *{{r|Pretty Good Privacy}} ====Server authentication==== ===Nonrepudiation=== ===Zero-knowledge proofs=== ===Digital signatures=== ==Confidentiality and integrity== ===Existence confidentiality=== ===Traffic confidentiality=== ===Message content confidentiality=== ===Atomic and sequential integrity=== ==Methods of concealing information== ===Cryptography=== *Ciphers and codes, including basic methods *Symmetric, asymmetric, and both *Key management protocols ====Specific cipher implementations==== =====Manual===== *Monoalphabetic substitutions *Polyalphabetic substitutions **Straddling methods *Transposition *Superencipherment =====Mechanical/Electromechanical===== *Jefferson/Bazeries cylinder, strip ciphers *Vernam *Rotor and rotor-like: Hagelin, Enigma, Purple, SIGABA/Typex =====Computer (general purpose and chip) implementations===== *General characteristics of military (KG vs KW, etc.) *Non-text/data: secure voice, video, fax *DES *PGP *AES ===Steganography=== *Invisible ink methods? *Classic covert channel *Masking with graphics *Spread spectrum, frequency agility, {{seealso|electronic warfare)) ===Hybrid methods=== ==Methods of obtaining partial or full information== {{seealso|communications intelligence}} for things including [[traffic analysis]] and [[direction finding]] *Man-in-the-middle attack *Various general scenarios: brute force, chosen plaintext *Basic mathematical cryptanalysis: frequency analysis, index of coincidence, Kappa test *Advanced mathematical cryptanalysis *Red/black engineering and other COMSEC supporting measures {{seealso|communications intelligence}} *"Practical cryptanalysis" (black bag job), [[radiofrequency MASINT#Unintentional Radiation MASINT]] (TEMPEST/Van Eck, etc.), acoustic cryptanalysis *"rubber hose cryptanalysis" **"This is the most powerful handgun in the world. I can't remember if I've fired five or six times. Feeling lucky, punk?" This is an example of quantum cryptanalysis, with the .44 Magnum chamber is loaded or not loaded, but Heisenberg requires one pull the trigger to find out. Howard C. Berkowitz 04:24, 4 December 2008 (UTC)

Lots of good stuff there. I'm not sure where most of it goes, though. Both cryptography and cryptanalysis are now fairly large articles. My guess is cryptography is close to approvable, but cryptanalysis isn't yet. Some of the things you mention could go in there. It think things like "monoalphabetic substitution" and "frequency analysis" go in History of cryptography.

Cryptology is currently a one-line article. That seems OK to me; all the real meat can go in the lower levels it links to. However, I wonder if others think cryptology should be expanded into a larger article and, if so, what it should cover. WP just has cryptology as a redirect to cryptography, which strikes me as an error, albeit a minor one. Sandy Harris 07:10, 14 September 2009 (UTC)

Detailed review

Sandy,

It does look good. For procedural reasons, I'm not going to make any actual edits to the article but leave them to you. If I make any substantial edits, then I can't Approve.

Here's a start; I'll get onto the later sections later today.

The lead paragraphs, I think, need a little work. I'd call it a branch of "applied" mathematics, and immediately get into applications. Chances are that a reader is going to be most interested in current examples; I'd move the historical context and example of writing to the end of the intro. Historically, diplomatic and military use came first, as well as protection of financial and resource exploration data, so I'd mention them before DRM. I wouldn't assume that all readers have heard of DRM, but everybody knows about stereotypes of "zee seek-rit code".

You are correct that cryptology is the superclass. Are cryptography and cryptanalysis the only subclasses? Possibly, you might comment on related mathematical disciplines, with a link to information theory. Things get trickier when thinking about statistics and discrete mathematics/abstract algebra.

The first, and possibly the second, sentence of the last paragraph in the introduction either can move to the first section, and then reinforce that codes are linguistic and ciphers are mathematical. In either case, the last paragraph of the introduction may have too many ideas in it and might do well to split. Again, be sure the whole introduction mentions the major applications. I suspect it would be best to link to information security, or even subarticles, when differentiating among aspects of confidentiality, integrity, and authentication.

I'll think on these, perhaps edit. I did not write the current introduction and thought you had. Sandy Harris 17:30, 16 December 2008 (UTC)

I have now almost completely rewritten the introduction. Comment solicited.

Next It think I want to re-organise some, move "crypto is hard" up to be 2nd section, move "external attacks" and "side channel" into cryptanalysis, add some extra headings so it becomes:

• Intro
• Crypto is hard
• Principles & terms
  • Codes vs ciphers
  • Keying
• Mechanisms
  • Secret key
  • Public key
  • Hash
  • One-way
  • Stego
• Applications
  • Digital signature
  • Digital certificate
  • PKI
  • Hybrid cryptosystems

Sandy Harris 10:52, 17 December 2008 (UTC)

Codes versus ciphers

I'd merge the last paragraph into the first, and make a really strong compare-and-contrast between codes (linguistic) and ciphers (mathematical). Maybe a footnote for encicode? Yes, I agree that in principle codes produce fewer symbols than ciphers, but I have a nagging thought about padding in real cryptosystems. Probably too detailed.

done. Sandy Harris 01:30, 17 December 2008 (UTC)

Principles and terms

Gut feeling only: a little too much about side channel attacks for an article at this level of detail.

That whole section is text I originally wrote in block cipher, and have not yet removed there. It seemed too general for that article and, you're right, it is too detailed for here. Would it fit in cryptanalysis? Create a stub on side channel attacks? Sandy Harris 17:19, 16 December 2008 (UTC)

Thinking out loud here...there seem to be a group of things that relate to one another, I think, under the broad heading of signals intelligence (and maybe radiofrequency MASINT as well), not limited to communications intelligence, a subset of which is cryptanalysis.

What is it (I'm trying to think of a name for this) that these have in common?

• Electronic warfare#Electronic probing
• Cryptography#side channel attacks
• acoustic cryptanalysis I could have sworn I had written that
• Radiofrequency MASINT#Unintentional Radiation MASINT

Things get really blurry between COMINT and ELINT, when you are trying to predict things like frequency hopping, variable pulse trains, etc., which you need to know for sophisticated intercept and jamming of radar, not just communications. Howard C. Berkowitz 17:39, 16 December 2008 (UTC)

Yes, and that's not the only group. Another discussion I think we need somewhere gives the motivation for various things by going through possible login security schemes:

• no login, let anyone access — no, you want some control over resources
• password — ok, but can it be read in the file?
• encrypted password — brute force if it is short, or a dictionary attack
• encrypted password + salt — ok, but can a rogue admin decrypt it?
• one-way encryption — fine locally, but not over the net (sniff and re-use)
• challenge-response system — needs good random numbers
• or RSA key for login a la SSH

There are others.

In general, we have some good chunks of text in various places and a fair idea about gaps that need filling. However, both within this article and overall — particularly considering relations between this, cryptology, cryptanalysis, and information security — I don't have an adequate picture of what belongs where. Some things, like the broad issues around keys, could go in any of the four or in a separate article. Sandy Harris 00:41, 17 December 2008 (UTC)

At least for now, I'd say leave the section Cryptography#Keying here and make key management a redirect to it. In the long run, that might be a separate article, but it does not exist yet. Sandy Harris 01:36, 17 December 2008 (UTC)

Secret key systems

Again thinking out loud, I'm not sure if I'm being too picky to say that some relatively old ciphers were at least digraphic (e.g., Playfair that wasn't invented by Playfair. Really not fair play, eh?)

From a copy edit standpoint, it's best not to have a single subhead under a heading. It's really logical to but "types of secret keys" (or words to that effect) before stream vs. cipher.

Shouldn't key management include key revocation?

Howard C. Berkowitz 16:33, 16 December 2008 (UTC)

Done. I also added some stuff on block cipher vs stream cipher choice. Sandy Harris 01:32, 17 December 2008 (UTC)

More semirandom bits

Continuing to improve. Comments in no special order.

Generally, it's best editorially not to have a level N heading with no text under it, but just N+1 headings. For the "Legal" section, you might want to say these will mostly be national or below, but there are some international agreements such as Wassenaar Arrangement on Export Controls for Conventional Arms and Dual-Use Goods and Technologies. I can refer you to some U.S. discussion about border searches of laptops and key access, but that's probably too far afield.

I wrote an intro for the section, an added a bit to headings below it. However, there is a whole lot more that could be said. At this point, I think what I wrote as the intro is all that needs to be here. Like History of cryptography, the details on the crypto controversies belong in a separate article, not in this overview. Not sure what to call it, though. Sandy Harris 11:37, 18 December 2008 (UTC)

Within key management, at least bold revocation or make it a fourth bullet, so the reader at least knows the term of art.

In the fourth paragraph of the introduction, you make the very important distinction between secrecy (confidentiality?) and authentication. These should probably link somewhere, even a redlink to now, or to the subsection in information security. I'm not sure if it's worth distinguishing between content confidentiality and existence confidentiality (i.e., countermeasures against traffic analysis), but it's worth considering, even as a link. Perhaps this would be expanded in information security.

Did those two. Sandy Harris 11:37, 18 December 2008 (UTC)

I don't have a better answer on side channel attacks; we both recognize there needs to be a separate discussion somewhere. What could we call it that encompasses all the ideas involved.

Just deleted it here for now. Text still exists in block cipher. Sandy Harris 12:14, 18 December 2008 (UTC)

I think credentialing/Kerberos style tickets with privilege are out of scope here; it's an INFOSEC issue.

Any mention of security tokens or biometrics to get at the keying?

Should the term key exchange key be brought out, and maybe more emphasis on session key?

I'm a bit confused here. Kerberos uses crypto mechanisms, so perhaps it belongs here. I've taken it out for now, though. Arguably, security tokens & biometrics also belong in Infosec; not sure where they'd go here. There's a bit in the existing article about two-factor authentication that seems misplaced. Nothing I know of on challenge-response systems yet.

My overall feeling is we're missing something, but I'm not sure what. Another section here? In the Infosec article? Promote Cryptographic authentication from redirect to article? Create key management, which now has some red links? Once we figure out what, I think the pieces will fall together. Sandy Harris 12:12, 18 December 2008 (UTC)

Otherwise, we are pretty close to being there. Howard C. Berkowitz 15:44, 17 December 2008 (UTC)

What about the re-ordering I suggested above? Sandy Harris 00:02, 18 December 2008 (UTC)

The one under "Detailed Review"? Looks good, with one caveat: the first-level heading of "Applications" is a little misleading to a naive user, since they might think an application is protecting their credit card or email. "Implementations" is not quite right, but it's closer. Maybe "Mechanisms" isn't the right heading for the previous section, naming that something else and renaming "Applications" to "Mechanisms."

I made the two titles "Basic mechanisms" and "Combination mechanisms". Of course you are correct, "applications" is misleading. Sandy Harris 15:00, 6 February 2010 (UTC)

Next steps?

I think the main text changes left to do involve moving things to new articles. See comments above.

• Move most of the "legal issues" stuff to an independent article, maybe "Cryptography controversies".
• Promote Cryptographic authentication from redirect to article, a place to put all the mechanisms used for that, of course with heavy linking both up to Infosec for motivations and down to more specific stuff.

then, I'm not sure in what order:

• Get someone besides me and Howard to have a look, preferably another editor.
• Put it up for approval.
• Archive the talk page which is getting huge and much of which refers to older versions.

Then we're done for now. Sandy Harris 03:33, 20 December 2008 (UTC)

Here would be a start.

• Put the new article, even only titles, in Cryptography/Related Articles. It won't hurt to put in definitions. Then, we see the structure.
• It may be that we want a almost-top-level article on Authetication, probably with Information Security as the parent. Authentication, aside from defining such things as number of factors, could then have Cryptographic authentication, Biometric authentication, []Token-based authentication]], as well as hybrids (or discuss hybrids in Authentication). Remember that somewhere we want to have person/role, client, and server authentication. Somewhere, there's the plausibility-check sort of authentication (e.g., is the CEO really at his desk at 3AM?). The related articles here also go to audit, accounting, etc. It occurs to me that I may be able to pull some accounting/audit material from the network management chapter of one of my books, updating and adjusting a bit.

Definitely get other eyes. We have a shortage of editors; I know Pat Palmer and Noel Chiappa have other things on their plate, as I've had things waiting for approval for a couple of months. Dave MacQuigg and Eric Gearhart might be good readers, and we can try to recruit new people. If you think it appropriate for some of the crypto, perhaps some of the active mathematics people. Howard C. Berkowitz 04:27, 20 December 2008 (UTC)

Encryptor/Encryption device

Sandy, we need to have either a redirect here, or perhaps an article discussing the attributes, of a physical encryption device. See the draft at TACLANE for a typical usage, although I'm not completely happy with using "bulk encryptor" for a device that works on all output, but not all bits — just those in packets. The device obviously can't work on a LAN if it encrypts the frame header and trailer.

While Federal Standard 1026, which first promulgated DES, is well known, FED-STD-1027, issued at the same time, deserves better recognition. Based on 1970s unclassified criteria, it described physical security requirements for an encryption box. Today, there's much more public information against emanations security and active electronic probing, so there's even more reason to have a discussion of the encryptor itself. Key loading, and indeed network management, also are obvious issues. Howard C. Berkowitz 14:25, 23 March 2009 (UTC)

I've added a section "Cryptographic hardware" but I left out 1027 because I do not understand its relation to later standards like FIPS-140 and 140-2; not sure which we should reference.

That links to Cryptanalysis#Side_channel_attacks, I think everything now at Block_cipher#External_attacks and Block_cipher#Side_channel_attacks should move into the cryptanalysis article. Sandy Harris 02:23, 14 April 2009 (UTC)

What next?

I think this is getting close to approvable. What have I missed?

At Talk:Block_cipher/Draft#Some_remarks an editor suggested getting rid of all the "For more information, see ..." links. This strikes me as a good idea for this article too; does anyone disagree? Sandy Harris 10:55, 2 February 2010 (UTC)

Went ahead and did that. Sandy Harris 02:17, 5 February 2010 (UTC)

Added the article at CZ:Ready_for_approval. It may not be quite there, but I think it is close enough that inviting input from other editors is somewhere between useful and overdue. Sandy Harris 03:36, 5 February 2010 (UTC)

I would be comfortable with nominating it. Some suggestions:

• Be sure all abbreviations, such as PIN and ATM, are defined with first use, or at least wikilinked.
• Discourage external links and expand them, so the full citation is visible under references.
• Some basic illustrations could help; let me see if I have some in machine-readable form.

Excellent work! --Howard C. Berkowitz 19:45, 2 March 2010 (UTC)

Where you mention Shannon made it an academic discipline, I wonder if it's worth mentioning Friedman putting it, earlier, on a statistical rather than black art basis. The work of both was initially classified, although Shannon's was published earlier. Kahn certainly argues that Friedman formalized the discipline. Howard C. Berkowitz 22:45, 2 March 2010 (UTC)

I don't think a Friedman reference is needed here, though I wouldn't object strongly. He certainly needs a link in cryptanalysis. In the long run, I'd like to see a history of cryptology article, with both history of cryptography and history of cryptanalysis as redirects, that covers him and many earlier things in detail. Sandy Harris 01:55, 24 April 2010 (UTC)

Illustrations

I am missing illustrations here and looked around a bit for suitable ones. I like the design of Fig. 1 & 2 from this paper (license: CC-BY), and have uploaded the first one to Image:Public-private-key-cartoon.jpg. However, their resolution is not very good. Any better ones? --Daniel Mietchen 15:59, 22 April 2010 (UTC)

The first section of this talk page has links to many deleted illustrations. Are they usable here, or should some go in history of cryptography? Sandy Harris 00:29, 24 April 2010 (UTC)

Howard's contributions

Hi, Howard (and others) -- I see in the History that Howard made numerous edits back in '08. Are these enough, and important enough, to disqualify him from proposing the article for Approval? Hayford Peirce 18:44, 17 May 2010 (UTC)

Oh -- right. That was before Sandy was here, I think, and I tried to stay out of the general crypto articles after then, concentrating on military applications. Who else is available? Peter Schmitt, and is there one other math/computers/military that's active?

I suppose the question is whether an amount of time lapsed takes off the influence. (but if this needs to be nominated, could someone spell out PIN and ATM? Howard C. Berkowitz 18:53, 17 May 2010 (UTC)

If Peter or some other *active* Editor in an applicable workgroup could legitimately nominate this article, then why don't you ask him/her to do so and then *you* gracefully remove yourself from the Metadata -- then the nomination (and Approval) would be 100% clean. Thanks! Hayford Peirce 19:12, 17 May 2010 (UTC)

The article has been massively rewritten since Howard was actively editing. See #Rewrite.3F above for the discussion and, if required, a link to saved pre-rewrite version. Since then, Howard has commented and made suggestions, but has not been directly changing text. Sandy Harris 16:02, 18 May 2010 (UTC)

Is there no other Editor who could put this article up for Approval if Howard withdrew his name? I tell you right now that Matt and I are *very* dubious about carrying out the Approval process as things now stand. Hayford Peirce 17:05, 18 May 2010 (UTC)

A different editor would work, or two more editors from appropriate workgroups. D. Matt Innis 17:26, 18 May 2010 (UTC)

I have already promised Sandy to read the article, and I expect that it will be alright and that therefore I will be able to support its approval. But with all this Charter (and Ormus) business I do not know when ... May I ask for a little patience? --Peter Schmitt 22:07, 18 May 2010 (UTC)

Can't you just spray it with Ormus and run time backwards? Howard C. Berkowitz 22:13, 18 May 2010 (UTC)

Use of the word "crypto"

There are five uses of the word "crypto" in the text (excluding the references), such as this example: "For example, companies that implement their own crypto .....". Is that really correct usage of the word? Can you replace it with "... their own encryption ..." or some other appropriate word? Or is it accepted jargon in the cryptography field? Milton Beychok 02:51, 18 May 2010 (UTC)

Even if it *is* accepted jargon *within the field*, that doesn't necessarily make it accepted in an encycl. If this is indeed "inside baseball", then it should be modified. Hayford Peirce 03:30, 18 May 2010 (UTC)

Ah yes...familiarity breeds contempt. Apropos baseball, Hayford, I don't think Moe Berg made major cryptographic contributions, but he was a fine spy and special operator. Howard C. Berkowitz 04:01, 18 May 2010 (UTC)

But a failed assassin in Switzerland. Took some nice pix in Tokyo from the tops of buildings. And read many, many newspapers everyday. An early info-junkie.... Hayford Peirce 04:44, 18 May 2010 (UTC)

It seems quite normal to me, but then I'm in the field. In some uses, you cannot replace it with "encryption" because that term is not general enough; you'd have to say "cryptography".

Is it enough to add something under Cryptography#Principles_and_terms mentioning that "crypto" is a widely used short term? It seems clumsy and artificial to me to spell out the whole term every time when the abbreviation is widely used within the field. Sandy Harris 16:14, 18 May 2010 (UTC)

Just because a word is long doesn't mean that it shouldn't be used in the appropriate context. I'm *very* much against slang and jargon, even if it's used within the field. Hayford Peirce 17:08, 18 May 2010 (UTC)

Somewhat frighteningly, I recently encountered antidisestablishmentarianism used in context, speaking of local history. Howard C. Berkowitz 23:44, 18 May 2010 (UTC)

I've now eliminated most uses of "crypto", all except in referenced titles and the quoted phrase "crypto wars". I also added it under Cryptography#Principles_and_terms. Sandy Harris 23:17, 18 May 2010 (UTC)

Sounds good. Thanks! Hayford Peirce 23:25, 18 May 2010 (UTC)

Lead

Two remarks:

The first paragraph assumes that the reader already knows the purpose of cryptography (including "encryts" and "decrypts") and the meaning of "key".

Is it indeed "unreadable except by", or should it be "unreadable except for"?

--Peter Schmitt 13:10, 19 May 2010 (UTC)

I rewrote the lede. To me, "unreadable except by" seems fine. Sandy Harris 02:28, 20 May 2010 (UTC)

Cryptography is difficult

Three remarks:

"If a serious attacker — ..., or any other — breaks a cryptosystem, he will certainly not tell the users of that system." This does not take into account non-destructive hackers.

"The cryptography itself is usually the easy part." The cryptography -- in what sense?

The list of "well-known" papers (plus annotation) would better fit into the biblography.

--Peter Schmitt 13:40, 19 May 2010 (UTC)

I added a section in the bibliography and linked to it from the article.

I really don't see a problem with the other two. A non-destructive hacker is not "a serious attacker" if he intends no harm, and he probably won't tell you about a break either. "The cryptography itself" seems clear enough to me. Sandy Harris 02:58, 20 May 2010 (UTC)

On second thought, I rewrote the "cryptography itself" sentence. Perhaps "clear enough to me" is not good enough for approval. Sandy Harris 03:08, 20 May 2010 (UTC)

As for the hacker (it is, of course, a minor issue, with no relation to approvability): At least in Germany there were cases when hackers broke into a system and announced their success in order to proof that the system was insecure. That was what I meant. --Peter Schmitt 08:22, 20 May 2010 (UTC)

Legal and political issues

The technical side of the article seems okay to me, but I think the last section is weak and needs improvement.

It discusses digital rights management. This doesn't seem to be a cryptography issue but is rather security through obscurity masquerading as cryptography. The problem with DRM is that one is given the ciphertext and the decryption key, and the decryption key is used to produce the plaintext. The decryption key is inside the DVD player or iPod or whatever, and the ciphertext is the media. Consider an analogy: to prevent copyright infringement, the publisher of a book gives you a locked trunk containing the book, and also gives you the key. When you want to read the book, you open the trunk, take the book out and read it. When you are finished reading the book, you are required by law or contract to take the book and put it back in the trunk and lock it up. And, well, this is going to prevent you from copying the book or lending it to people or whatever. This isn't security, this is just a talisman. This is like The Simpsons and the tiger-repelling rock. Lisa holds up a rock and says that the rock is keeping tigers away. When asked by Homer, she says "I don't see any tigers here!"

With real encryption, you encrypt something and send it to me. The whole point is that only I have the decryption key. With DRM, everyone who has a DVD player has the key - but they are forbidden by law from extracting the key from the DVD player. That encryption is involved is irrelevant. You could construct a DRM scheme that involves no encryption at all: perhaps you could have a system that calls out to a trusted server, retrieves a list of SHA-1 hashes and then refuses to play any files that does not match the pre-shared hash list. Ah, but how do you prevent people from just using a player that doesn't do this? I know: pass a law banning any system that doesn't conform to this loopy standard.

Basically, the question I'm asking is does DRM even count as encryption? As far as I can see, it is a giant waste of time - technically, it does absolutely nothing at all. The only teeth it has are legal: instead of worrying about people stealing DVDs, you worry about people who produce DVD players that play stolen DVDs. It is a legal abstraction, not a useful technical category. The correct place to discuss DRM is not in the encryption article - because DRM isn't really encryption in any meaningful sense - but in a detailed standalone article on the subject. (Aside: I'm really looking forward to finding some pro-DRM editors. All the pro-DRM reasoning I've seen is totally facetious and technically illiterate and makes the homeopathy supporters look like beacons of enlightened reason.)

It'd be nice if we could squeeze some more of the history of the crypto wars into the section before approval freeze. There's a great story to be told about the interplay between PGP and Zimmerman, and the Clinton administration - with the netheads promoting strong encryption, and Clinton trying to push for Clipper, with an NSA backdoor, and the V-Chip, the global website "blackout". And then the same thing happening in the UK with RIPA. This section feels unfinished. How long have we got to fix it up before it gets frozen for approval? –Tom Morris 15:00, 19 May 2010 (UTC)

I think most of that belongs in other articles. We have one Cryptography controversy which needs expanding. Some of the issues are also mentioned in cypherpunk and at Digital_rights_management#Encryption. Sandy Harris 15:17, 19 May 2010 (UTC)

(edit conflict) For me, the article is rather too long than too short. This does not prevent the approval, but I would say that pointers from this page to "related pages" dealing with these interesting topics is the better choice. On the other hand, approval does not "freeze" the article -- with new material added it can be re-approved.

As for DRM: While your arguments are well taken it is certainly true that it uses encryption algorithms, if only to make it more difficult to "break" the system. --Peter Schmitt 15:23, 19 May 2010 (UTC)

I made the link to Cryptography controversy more explicit/obvious. I'd like to move the two paragraphs Tom added here, beginning "In the US..." and "In the UK..." into that article. What do others, especially Tom, think of that idea? Sandy Harris 02:22, 20 May 2010 (UTC)

There's also some text about this at PGP#Export_restrictions. I think cryptography controversy needs considerable work, including a link to that and various other bits of history. Volunteers? Tom? Sandy Harris 03:47, 20 May 2010 (UTC)

Kerckhoffs Principle

In "codes versus ciphers" it is said "see Kerckhoffs' Principle". Isn't this inconsistent? The principle is explained twice on the page below. --Peter Schmitt 23:40, 19 May 2010 (UTC)

Revising the Approval plan

Peter, should I remove my name from the template, without prejudice to Sandy but to ease the process?

Sandy, would you prefer to continue to make all the edits, or would it be helpful if I did some? Howard C. Berkowitz 13:30, 20 May 2010 (UTC)

I'm happy either way, as long as we are making progress toward approval, which does seem to be the case. Also, I have some deadlines looming so I'm likely to be inactive for about the next week. Sandy Harris 14:31, 20 May 2010 (UTC)

Howard, does it make a difference if you withdraw, or if I add my signature to yours? --Peter Schmitt 14:34, 20 May 2010 (UTC)

Either way will work for me. My impression, however, was that Hayford and Matt wanted you as the primary approver. This is an interesting situation -- since I haven't actively edited for some time, I think it adds strength to the approval to have a 2nd Editor, but that seems to run afoul of the rule about author/editors -- yet it would be acceptable with a 3rd editor. At some point, the EC will have to write guidance for things like this. --Howard C. Berkowitz 15:06, 20 May 2010 (UTC)