Talk:Cryptography/Archive 1: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Howard C. Berkowitz
(Sandy Berger's recommendation seems a fine compromise)
imported>Howard C. Berkowitz
Line 86: Line 86:


:::I like that approach, Sandy. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 21:47, 5 August 2008 (CDT)
:::I like that approach, Sandy. [[User:Howard C. Berkowitz|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. [[User:Howard C. Berkowitz|Howard C. Berkowitz]] 11:16, 8 August 2008 (CDT)

Revision as of 10:16, 8 August 2008

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

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)