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)

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 [1]. That is out of date and much more advocacy than encyclopedic in tone, but perhaps useful.

The standard reference on crypto laws worldwide is [2]. 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)

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)

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)