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.

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.

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.

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.

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.

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.

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