Talk:Cryptography/Archive 3

Possibly stupid question

From the article: It's for this reason that while computing power is approximately 2,000 times greater than it was just one decade ago, the current 128-bit key-length limit imposed by US export regulations around 2000CE are still sufficiently long today.

If NSA can't break 128-bit encryption, why would they impose a limit at 128 bits? Why not remove any limit, or set one where they can break it? Isn't it reasonable to assume that they can break it, or they'd not have imposed the limit? -- Pakaran 18:13, 1 March 2006 (UTC)

The limit exists to restrict export of key-lengths they either cannot break, or that would take too much time to break. Dr1819 15:54, 26 March 2006 (UTC)

On another note, I find it interesting that 192 bit AES is required for top secret information. If 128 bit is unbreakable, why not use it themselves? -- Pakaran 18:15, 1 March 2006 (UTC)

I don't think they're concerned about anyone brute forcing the 128 bit key space. Rather, they want improved safety margin against non-brute-force attacks, mathematical or otherwise. E.g., if some weakness in the cipher or an implementation leaks half the key bits, AES-128 becomes vulnerable but AES-192 is still in good shape. Phr 09:24, 15 March 2006 (UTC)

Because things may change in the future. Arvindn 18:49, 1 March 2006 (UTC)

I guess that makes sense. If someone makes a quantum computer in 2015 and uses it to decrypt my credit card number now, I probably don't care. there's military issues where they would care deeply. Is that what you're saying? -- Pakaran 18:52, 1 March 2006 (UTC)

Actually, it doesn't make sense. I think we have here an artifact of bureaucratic regulation mongering and an inability to think clearly about engineering issues. Too many lawyers and wannabes involved, I think.

Given predictable changing conditions that apply to The Adversary as well as to all others (eg, most notably More's Law, but perhsp some advance in factorign theory or some such), the correct stucture of such a regulation (presuming one is needed at all, something the regulators are unlikely to spontaneously hit upon as a real issue), the correct regulation will use something liek the following: some competent (NB this concept!!) person, organization, or group should be charged with making periodic evaluations of such things as necessary key length. Whatever it estimates will become the new regulation. Changing, say, once a year or more often as enginerring concerns indicate.

That won;t be possible, partly because it's the sensible thing to do, and such regulators rarely do the sensible thing. But also because lawyers don't understand engineering contingency and can't think about it clearly. So I think thet's the answer to your question, P. ww 09:33, 2 March 2006 (UTC)

Governments want to keep some of their secrets secret from the most powerful adversaries over time scales on the order of several decades. As you point out, most people don't have secrets that need the same level of protection (or paranoia...). There are ways of extrapolating trends in increasing computer power, and you can get estimates for what year it becomes practical to break various key lengths by brute force. See, e.g., this website. I presume that the NSA (or whoever) undertook an analysis of this nature and judged that 128 bits presented too much of a risk to be breakable too soon. — Matt Crypto 10:05, 2 March 2006 (UTC)

Certainly your first observation is so. In the US, there have never been any limits on crypto 'stength' available to the Federal government. The limitations on crypto 'strength' was designed to prevent those outside the US from getting access to really good crypto. We who are rather better infomed than the bureaucratic committe which adopted this policy have had little toruble understanding the futility of this attempt, and in any case since the 70s, really good crypto algorithms have been published outside the US which made such policies more than feckless. In any case, as long as one kept the 'strong' crypto one had (eg, PGP in the famous case) within the US borders (and Canada too, wasn't that kind?) these regulations didn't apply.

Whether my secrets or yours aren't as worthy of protection as NSA's or the FBI'ss or the CIA's or whatever, is a matter of opinion. I personally feel my secrets are very important in comparison to the CYA efforts of many in government. You may have less regard for yours.

As for who chose 128 bits (the current more or less acceptable limit), I really don't think it was anyone in particular, as a result of close analysis of the securiyt levels to be reached or anything similar. For symmetric cyphers, the long-standing 40-bit limit was absurd to anyone who understood a bit, 64-bits (a power of 2) was clearly either not good enough or soon to be, and the next power of 2 was 128-bits. Lots of the literature discussing the necessary length of keys from a security perspective has 40-bit, 64-bit, and 128-bit analysis points. I think the policy people merely took the next line entry from one of these analyses, given the discredited performance of NSA's recommended lengths. Keep in mind that NSA's proposed Clipper algorithm, for around this time, used 80-bit keys. Since it's widely thought that NSA had the ability to break the cyphers (or cypher key lengths) it allowed (aside from the planned key escrow feature), this may be a hint as to NSA's brute strength break capacity in this period. ww 13:51, 5 March 2006 (UTC)

The main reason behind the export restriction is that it makes it a felony to export any aspect of the technology, including an example (message) encrypted with the technology. Thus, even though nearly-uncrackable (if not uncrackable) encryption exists outside the U.S., it's a felony for anyone to send unbreakable encrypted messages outside the U.S. This puts people in the position of either playing ball, or risk going to jail. - Dr1819 16:04, 26 March 2006 (UTC)

The rules were never anything like that even in the ITAR era, and they're considerably relaxed now compared with those days. See Bernstein v. United States for one of the court cases. Phr 20:42, 26 March 2006 (UTC)

My own personal opinion is that we're overthinking this just now and above. If there is no rational reason behind a policy, no amount of strenous and talented tea leaf reading will produce the non-existent reason after the fact.

I suspect that some committee (recall the definition of committee -- honorable exceptions such as the orignal Algol committee excepted), understanding that 'codes and stuff' were important to winning WWII, and further understanding that Allied brilliance at this code stuff was the edge in that respect, decided not to allow any of that brain power product off the reservation. So someone at NSA presumably had a watching brief to keep the rules such that NSA could, if it really wanted to, brute force break what it wanted among the legally permitted. Faster NSA machines, more bits allowed in keys. All of course in the deep dark dank secret dungeons of NSA. Burn before reading, if we tell you we'll have to kill you, ...

There's a saying to the effect that one should never attribute to malice what can be accounted for by simple stupidity. And another, "Stupid is as stupid does". And still another, this one from G Santayana, "Those who do not learn from history are condemned to repeat it". All of which would apply to this bureaucratic instance of disengare brain, formulate policy. ww 07:20, 27 March 2006 (UTC)

The politics and legal stuff of the export restrictions (and the Clipper chip) are discussed at some length in Steven Levy's popular book "Crypto" which is very readable and pretty good all around. More extensive treatment including many source documents is in "The Electronic Privacy Papers: Documents on the Battle for Privacy in the Age of Surveillance", edited by Bruce Schneier and David Banisar. Wikipedia should include good coverage of this stuff but the main Cryptography article IMO should only gloss on it. Phr 07:41, 27 March 2006 (UTC)

Improving the article

I just did a major edit here. I still think the article needs a lot of improvement, though. I tried to restructure it; before, it was something of a mish-mash. The structure, and reason for it, is now: (1) intro, (2) terminology (so that the terms we use later don't have to be defined inline, and they won't confuse people: plus it clarifies the whole code/cipher thing, which people will want to know), (3) history (so that the discussion of modern cryptography can have historical context), (4) modern cryptography, broken down into subsections, and (5) legal issues. Now that I've added (5), I think it should be expanded more generally into a section "Cryptography and society", in which we talk about the effects cryptography has had on human society in general, beyond simply the governmental regulations issue. Modern cryptography (4) is broken down into sections. Right now it's

• Symmetric-key cryptography
• Public-key cryptography
• Cryptanalysis (of both symmetric-key and public-key)
• Cryptographic primitives
• Cryptographic protocols

I think it's best to cover symmetric before public-key, so that the motivation for public-key can be explained in context. The difference between symmetric and public-key cryptanalysis is better explained afterwards, and it is here that a discussion of the computational assumptions used in cryptography can be discussed, as well as key size issues. Cryptographic primitives could perhaps be titled "Theory of cryptography": my main point there is that some cryptographic work is concerned with the connections between various cryptographic applications in terms of solvability (for instance, the existence of OWFs implies the existence of PRGs). We could probably stress the precise definition thing a bit in that section. Finally, under "cryptographic protocols," we can discuss just about everything else. We could, perhaps, have a section on "secure computer systems", in which we note the emphasis on actual implementation and deployment, but I'm not sure that's really core cryptography.

A few things that need doing:

• Condense writing in all sections
• Incorporate history of PK crypto into history section? This may be awkward in the current structure, though.
• Expand "legal issues" to "Cryptography and Society" and give broader treatment.
• Give an overview of cryptography standards: at least, what they are and some important examples.

Also a few notes about how I used terminology: (1) I stick with "cipher" over "cypher" as it is the more popular usage. I feel strongly that the same form should be used consistently -- if we don't do this, it looks random. (2) I try to use "cryptosystem" over "cipher" when referring to modern techniques: because block ciphers aren't full encryption systems, it's not right to equate the two in the modern setting. For instance, in the sentence "DES can be used in CBC mode to provide a secure cryptosystem", it's important to use "cryptosystem" rather than "cipher," though "encryption scheme" would be okay. For this same reason, I usually avoid using "cipher" when referring to public-key techniques, although I didn't avoid it completely. Mangojuice 03:09, 4 March 2006 (UTC)

I more or less agree with this work. I think it has improved the article by restoring some context (historical, largely) for the benefit of the reader's understanding. A review of the earlier content of this talk page will turn up the history of soem previous debate on this question. it is still relevant. ww 13:32, 5 March 2006 (UTC)

Burial

Recently added: "(Note that some people much prefer the terms enciphering and deciphering as in many cultures 'encrypting' has unfortunate connotations related to burial.)"

Is this a particularly notable fact? I've read it in Schneier's Applied Cryptography, but haven't heard of it anywhere else; maybe it's just a witty aside by Schneier? — Matt Crypto 19:58, 15 March 2006 (UTC)

Dunno, you could email him.WolfKeeper 20:02, 15 March 2006 (UTC)

All dictionaries point to "encryption" with its use in Cryptography. I can't find any references to it as a burial term. Perhaps Schneier was being playful? "Entomb" would seem to be the word for burial. --- (Bob) Wikiklrsc 21:46, 15 March 2006 (UTC)

"Encipher" isn't used much in current technical literature. I dunno about popular usage. I'd really like to de-emphasize the terminology section and the article's endless hairsplitting about how these different words have been used throughout history. Remember that cryptography has traditionally been done by organizations that operate in secret, so there hasn't been that much sharing of vocabulary, and different organizations have internally used the terms in differing ways. In current technical usage, there's rarely any confusion, and popular usage is generally imprecise by definition.

I can't resist another funny story. Frank Rowlett was an underemployed math instructor who took a civil service test and did well enough to get a job offer from William Friedman as a "junior cryptanalyst" in the 1920's. He was delighted to finally get some steady work, and eagerly checked his dictionary to find out what a cryptanalyst was. The dictionary didn't say, but Rowlett knew what a "crypt" was, so he showed up for work expecting that the job had something to do with statistical problems related to the govt's managing all those WW1-era military cemeteries. (Source: "The American Magic" by Thomas Parrish). Phr 22:26, 15 March 2006 (UTC)

Which book are you referring to ? The American Magic: Codes, Ciphers, and the Defeat of Japan by Ronald Lewin (1982), or The American Codebreakers by Thomas Parrish (1987), or The Ultra Americans by Thomas Parrish ? Or ? Can't find "The American Magic" by Thomas Parrish. --- (Bob) Wikiklrsc

Sorry. The American Codebreakers, by Parrish. "The Ultra Americans" is the earlier title of the same book. Phr 05:44, 16 March 2006 (UTC)

Thanks, I had gotten a bit confused. Some articles in Wikipedia need to be fixed in that respect, like Ultra, etc. I just fixed the Ultra article's reference to the non-existent book. --- (Bob) Wikiklrsc 09:19, 16 March 2006 (UTC)

Thanks for the fix. The incorrect cite was put there by me, as I'd gotten the title confused with that of the Lewin book. I better check whether I did the same thing anywhere else. Phr 11:00, 16 March 2006 (UTC)

You're very welcome, Phr. I think the incorrect reference was in a few places. --- (Bob) Wikiklrsc 17:21, 16 March 2006 (UTC)

Apparently enciphering and deciphering are the correct phrase according to the ISO 7498-2 standard (see http://www.proz.com/kudoz/1227608).WolfKeeper 01:56, 17 March 2006 (UTC)

Heh, interesting. Note that 7498-2 is an OSI standard, which is to say, dead as a doornail. The convenient 7498-2 diagram at the first google hit [1] (other than the ISO ordering page) definitely says "encryption". OSI was a Euro-thingie and may have been trying to make prescriptions for the sake of non-English speakers, but it never went anywhere. I still think in the article we ought to straightforwardly use the terms that are normally used in English-language technical literature, and relegate all the less common terms to a glossary. (FWIW, I also found some references to "Naval Cypher #3" etc. from the WW2 era, but I think that series dates back to the 19th century, so that spelling is still pretty old). Phr 02:09, 17 March 2006 (UTC)

OK, I did some edits

that might be contentious. Don't shoot, comrades. Phr 10:37, 2 April 2006 (UTC)

To ww--can we chop the stuff about codes and data compression? It's reasonable to describe it in History of cryptography but it's a completely obsolete subject and should get just the briefest mention in the main article, especially up near the top where it is. Phr 03:56, 4 April 2006 (UTC)

Not a problem. I had, if memory serves, merely attempted to rephrase something another poster had left obscurely. The content is someone else's. I actually agree with you that it (the datqa compression stuff) needn't be here. As an article of first resort, this point is more than bit off the main line.

As for codes being obsolete, certainly it is largely so, but this is WP, not a popular treatise on how things is done nowadays. For our writing, there is virtue in relying on an historical account to help build understanding in our Average Reader, since, if nothing else, our predecessors started with simpler and more easily understood matters and only developed complexity (of practice and theory) over time. Since we are not preaching to the crypto choir here, but attempting an encyclopedic thing, to wit informing the uninformed, we cannot slight this or that as "obsolete'.

So I would say that an introduction which starts with substitutions cyphers, and transposition cyphers, and codes, only then progressing to polyalphabetic cyphers and then asymmetric crypto, protocols, crypto system design and advanced matehematical proofs of vulnerability of this or that cypher under these ot those conditions, generally will be a help to our Reader.

I do agree though, that the primary emphasis should not be historical in this article, but rather on contemporary crypto given its importance to all. Assorted maliciousosity is best (or soley) thwartable using properly chosen crypto, so it's a pretty important issue. And that's a point worth making for our Readers liveing and working with computers and the Internet today. 71.247.110.21 02:27, 10 April 2006 (UTC) actually ww 02:31, 10 April 2006 (UTC), got logged off

I think what you said about protocol design is true, but the way you said it was kind of messy, so I tried to clean it up. I think it's hard to tread the line between pointing out that ad hoc protocol design is error-prone and yet not being critical of it (note: "ad hoc" protocol design can mean two things: not doing proofs or doing sloppy, ineffective proofs, or doing good proofs but doing them "by hand." The former really is a bad idea and badly error prone: the latter is not nearly so bad.) I removed the claim about "most deployed protocols" because "deployed" can mean almost anything. Also, I removed the discussion User:Ww just added about data compression: we don't need to be so informative there; we should de-emphasize the terminology section. There's a link to code (cryptography) where a reader can learn more about codes. And like Phr says, we could cover it in the history section if it can be fit in without disrupting the flow. Mangojuice 04:03, 4 April 2006 (UTC)

Thanks for the "code" fixup. By deployed protocols and ad-hoc analysis, I meant things like TLS, which took several iterations (SSL versions 1,2,3) and still isn't quite right. I don't know of any protocols of that much complexity that have proofs at all, "hand" or otherwise. Also, I think just about all proofs of real-world protocols that do exist today are "by hand", i.e. automated proofs aren't so practical yet. There's work being done on that but it's still a "holy grail" (per the last slides of [2]). By a "hand" proof, I mean proofs like the ones for RSA-PSS, etc. Even 10 years or so ago, real-world practice was very primitive compared with today. As one example, see the evolution of RSA, from the early deterministic versions (believed to be a good thing as late as ~1990 when deterministic RSA signatures were pitched as better than DSA because of the absence of potential subliminal channels), to the original PKCS #1 that fell to Bleichenbacher's "million message attack", to RSA-OAEP ("proved", but the proof had an error), to RSA-PSS (generally accepted now). Of course there's been much worse stuff than that too, like the weird and insecure special DES mode once used in Kerberos. I'd hoped to get something into the protocol section that conveys that things really have gotten better in the past decade or so. Can you suggest some alternative wording? Phr 06:18, 4 April 2006 (UTC)

Phr, I agree with your main trend, but would note that in this article, a frist resort one, the point about protocols that should be made is probably something like, this is a protocol, they're very important to security and real world crypto systesm, some (few) are proven to be secure as protocols when properly caried out, and further details to be left to other articles. For instance, a protocls article. some useful points here, but perhaps not in this article. 71.247.110.21 02:27, 10 April 2006 (UTC) actually ww 02:31, 10 April 2006 (UTC), got logged off

• What we should really be doing is writing a section about standards. Talking about trends when we're really talking about one or two algorithms is dicey, but all those issues are worth talking about separately; it's not always the most important part of the academic discipline, but standards are very important and we should cover them. I think whether things are getting better depends very deeply on which algorithms you consider to be "deployed," so I think it's not the kind of claim we can really make here without a specific, reliable source, and I don't even think a published paper is likely to be good enough for that. I would argue things aren't really "getting better" in terms of how we design protocols, it's just that we're finally getting good ones for the really important protocols, after working on them for as long as we have. Mangojuice 13:11, 4 April 2006 (UTC)

• But I think things really are getting better (am I wrong?). If you read a 1990's book like Applied Cryptography, it's full of dire warnings (valid at the time) about how fraught with peril protocol design is, with not much advice about dealing with the peril beyond "leave it to experts". The subject is better understood now; provable security is part of mainstream practice instead of being ivory-tower academic research. We're "finally getting good ones" not because there was so much work that it took this long to do, but rather because the methods of developing "good ones" are now more widely known and applied. Stuff got approved in the 80's and 90's that would be rejected now. Stuff gets trusted now (because of rigorous analysis that's possible today) that would have been considered way too complex and suspicious back then (example: imagine OCB mode being presented in the 1970's alongside CBC, CFB, etc. Nobody would have believed it). I'm hoping we can improve Wikipedia's coverage of these topics which right now is fairly thin.

Btw, is Matt or Ciphergoth still around or can anyone suggest some cites? I'm not really expert with this stuff, I'm still learning about it. Phr 02:56, 5 April 2006 (UTC)

Interesting discussion here. Before I debate the facts, I want to point out how hard it would be to include any of this material in an encyclopedia article without it being original research. Research papers are unreliable, as they're academic and tend not to have a proper view of what is "in use" as opposed to the subject of active research. Books, on the other hand, have relatively fewer authors, whose opinions are worth noting, but they are slow to be produced and can be out of date. Our best approach is to factually cover the differences between then and now. And "leave it to the experts" is still absolutely critical advice, and definitely the kind of advice that belongs in a book like Applied Cryptography.

Crypto standards bodies in the 80s and 90s had their problems; one of them was being too heavily controlled by industry without enough influence from academia. This hasn't exactly changed, but they do tend to retire broken protocols. Also, standards bodies are becoming less important. It's still critical to how we do encryption and authentication, but a lot of research these days is into more complicated protocols that don't need to be standardized. There, it's the academics who rule, because they get to decide whatever is the best solution... but there's still a question of who chooses to use those results. It's been my experience that there's a lot of crappy security-related research going on, because (effectively) people who aren't crypto experts continue to design protocols by hand, with vaguely defined goals, without knowing the crypto literature.

I think it's fair to say that in cryptographic research there has been a clear trend over the last two decades towards rigorous proofs; I believe this HAS improved the quality of protocol design. However, formal approaches (non-"ad hoc") are still a bit immature. In some cases there are theorem proving tools that can help, but there are so many variables that the process remains clearly error-prone.

Some references on formal analysis of crypto protocols: Abadi & Rogaway ('91, I think), Many papers by subsets of Backes, Pfitzmann, and Waidner, some recent work by Jon Herzog and Joshua Guttman (and some others I think), and finally there's work by Dawn Song that's relevant. I don't think there are any books that cover these results, at least not yet, but there are probably some relevant PhD theses, for instance, Herzog's and Song's. All those papers will talk, to some degree, about how difficult and error-prone crypto protocol design is, and how formal methods offer the promise of something better.

However, it's not the formal approach that has had real impact on the quality of cryptographic protocols. Rather, it's a mix of trial and error and better understanding of the ad-hoc method. Mangojuice 04:10, 5 April 2006 (UTC)

Thanks for those references. I think your point is well taken that industry didn't listen to academics enough in the 80's and 90's. But these formerly exotic research results are now really less avant-garde than they used to be. The issue about "leave it to experts" was that in the past, knowing the crypto literature wasn't enough. Reading Applied Cryptography is like reading a medical textbook on brain surgery--you might know all the same facts as a surgeon knows afterwards, but you're not ready to operate on patients because of the sense of subtleties and exceptions and weird special cases that only comes from experience. Block cipher design is still like that: a black art, that few people (maybe nobody) have the right skills to do securely. The usual guideline is that any cipher designer must first "make their bones" by breaking other people's ciphers. But we don't even know (because P vs. NP is still unsolved) whether secure block ciphers can exist even in principle.

But with protocols (maybe I'm using that term loosely, I mean crypto schemes made by combining primitives, which would include things like symmetric encryption modes), we're now at a point where it's just normal math, and any geek with a reasonable CS theory background who can read and write proofs, can slog through "Foundations of Cryptography" or Rogaway and Bellare's lecture notes, and then be reasonably confident that s/he knows what s/he's doing. Materials like this didn't exist 10 years ago AFAIK, except in research papers.

Also, we may be using "proof" for two different things: formal, model-theoretic proofs (BAN logic and things descended from it), and informal reduction-based proofs (these are similar in spirit to NP-completeness proofs). I've heard these described as "red cryptography" and "blue cryptography". Red cryptography is still mostly academic, but blue cryptography is being used to design stuff that makes it into standards. I don't know much about the model-theoretic stuff and I'm currently trying to study the reduction-based stuff, mostly by web surfing. I'm hoping to write a few articles since we don't have much yet. I've started advantage (cryptography); it has a ways to go, and I think it has some mistakes right now, but it would be great if you could let me know if you think it's headed in the right direction. The idea is to add articles about PRP's, PRF's, encryption modes, etc., and work backwards towards connecting with the overview articles.

Also, if you think I'm drinking Kool-Aid, please go ahead and say so. It's great to have an actual crypto discussion on the crypto discussion page, instead of going on about cryptography versus cryptology. Phr 13:16, 8 April 2006 (UTC)

Concur on good to get past ..ology v ..ography as the main content of this talk page. But I would note that, for our Average Reader (the target audience for the present article), the 'better than 10 years ago' you speak of is elusive, evn though true. How the untutored, or even the expert in hash theory, can reliably distinguish in practice between really good crypto, and plausible but leaky crypto, is unclear. It's part of the peculiar nature of crypoto engineering as opposed to most other kinds in which the Opponent to be outwitted is consistent (so far) and doesn't change approaches and techniques. Even with source code, being one's self in a position of reliably distinguishing between them is not at all straighforward. Expertis4 in program design, programming (syntax and semantics), numberic programming, OS security considerations, some hardware oparationsl issues, ... It's a tough problem, and is not really settled in a useful sense by relying on 'branding' (ie, NIST has annointed AES as good, so if my crypto system uses AES, I'm home free...) as a sensible test crterion.

In earlier edits in this article, I had taken the position that this is a point WP may reasonably make, and was revised sufficiently often and completely to make clear others' disagreement. Rather than get involved in edit wars, I went on to other work. But I still feel, very strongly, that this is a fundamental issue EVERY newcomer to modern crypto must understand, lest choice of product and attitude be made more or less by popularity of dart. Not so reliable an ensign to which to repair, however useful in respects. Our Reader is ill-served if they read this article with little hint of the presence of theis 600-pound gorilla in the crypto world. And there is little such content remaining in this article (at my last close read, anyway). 71.247.110.21 02:27, 10 April 2006 (UTC), actually ww 02:31, 10 April 2006 (UTC), got logged off

Todo list

I removed this page from the "todo priority 1" category, since there's no formal todo list, and it makes it sound like the article needs urgent attention. Of course the article could use various improvements that we'd all like to get around to sometime, but its current state is fairly reasonable. Feel free to restore the category if you think it's appropriate, but in that case we should also make an actual todo list, since the todo category is intended to attract other editors to work on the article, in which case they expect a list of tasks. Phr 02:59, 16 April 2006 (UTC)

I added it back. According to the explanation I ready, priority has to do more with the visibility of the article rather than the importance of the items on the to-do list. Since cryptography is referenced by a whole lot of articles (over 1000 pages in "What links here" for the article), it's appropriate for it to be category 1. See Category:To do, by priority. Mangojuice 16:30, 17 April 2006 (UTC)

But being in the category means we're supposed to have an actual to do list, and as far as I can tell, we don't have one. It would be at Talk:Cryptography/To do, I believe. See Template:To do and its talk page. Should we start putting a list together? Phr 17:03, 17 April 2006 (UTC)

You don't see it? There is a list, at Talk:Cryptography/to do, and it's included near the top of the page under "tasks". I added those to do list items after my major rewrite a month or so ago. Mangojuice 17:08, 17 April 2006 (UTC)

I see it now. I guess I saw it before but didn't realize it was the to do list, since it says "pending tasks" instead of "to do". Thanks. Phr 18:43, 17 April 2006 (UTC)

Featured status

I'd like to move this article towards featured status. Based on the feedback the article received when it failed to get featured status before, the main concern has been citations. I'm going to take a pass through the article and add some citations, but I'm sure there will be large segments (particularly of the history section) that I won't be able to source properly. If we all help, hopefully we can get the article in good shape, and then try to get it featured. This is one of those articles that really ought to be featured. Mangojuice 18:00, 20 April 2006 (UTC)

I think I can help with sourcing, but I've also been thinking we should give up on FA and just make it a summary/overview article, and instead try to get the secondary articles featured (like the Enigma article already is). I'm imagining we should shorten all of the longer sections by about 50% each, and add some new short sections on crypto hardware, crypto theory, and crypto-related standards. Re sourcing, "Contemporary Cryptology" (ed. Simmons) has some good papers to use for the refs that you just added. My copy is in storage but I can try to dig it out if you don't have it. Phr 18:32, 20 April 2006 (UTC)

Why give up on FA? I think it's more important for this article to become very good than most of the other ones. This is a gateway article, it introduces people to the topic... if we think of WP as a book, this is that critical introduction chapter that people will read to decide if they want to keep reading more. I agree with your ideas for improving the article; I may give it another pass at some point but not just now. Mangojuice 20:30, 20 April 2006 (UTC)

Well, we'll see. Meanwhile, I just changed the cite for the first DH public key paper to one that predated "New Directions". It explained the concept of public-key but didn't say how to do it (because they hadn't figured it out yet), except they added a sentence describing DH key exchange at the at the last minute. They went on to write "New Directions" a while later. Let me know if you think that's right; again, I think both these papers are in Simmons' book but I don't have it here. This might also be of interest:

In 1870, a book by William S. Jevons described the relationship of one-way functions to cryptography and went on to discuss specifically the factorization problem used to create the "trap-door" in the RSA system. In July, 1996, one observer commented on the Jevons book in this way:

In his book The Principles of Science: A Treatise on Logic and Scientific Method, written and published in the 1890's, William S. Jevons observed that there are many situations where the 'direct' operation is relatively easy, but the 'inverse' operation is significantly more difficult, One example mentioned briefly is that enciphering (encryption) is easy while deciphering (decryption) is not. In the same section of Chapter 7: Introduction titled 'Induction an Inverse Operation', much more attention is devoted to the principle that multiplication of integers is easy, but finding the (prime) factors of the product is much harder. Thus, Jevons anticipated a key feature of the RSA Algorithm for public key cryptography, though he certainly did not invent the concept of public key cryptography.

Solomon W. Golomb, On Factoring Jevons' Number, CRYPTOLOGIA 243 (July 1996) (emphasis added).

(From [3] near the end). Maybe we can mention this in the history article. Phr 20:52, 20 April 2006 (UTC)

I'd never heard of that. Cool beans. I figure we should cite the later paper for DH key exchange, and under "Symmetric key" when we say only symmetric stuff was known until 1976; theorizing about it is a step beyond showing it can be done. But we should cite this earlier one for the concept of asymmetric crypto. Mangojuice 20:54, 20 April 2006 (UTC)

IIRC the published version of "Multiuser cryptographic techniques" did describe DH key exchange, just very briefly (a sentence or two added just before it was submitted). This is significant because they gave out preprints at a conference more than a year before the DH patent was filed, arguably making the patent invalid (by the time this got dragged through the courts, the patent was about to expire, and I think the suit settled without a judicial finding). The New Directions paper went into more detail. Phr 20:59, 20 April 2006 (UTC)

<---

Gentlebeings,

I very strongly feel that we must avoid turning this article into a collection of paragraphs with pointers to the real content in other subarticles. This subject is an especially twisty one, and we owe our readers the best assitance in untwisting it we can render. Settling for a collection o fpointers would fail that responsibility.

I VERY strongly feel that this article, one of 'first resort' as it were, should serve as conceptual orientation and introduction to more detailed coverage of particular topics. I once attempted to use its history as a way of introducing readers to the concepts (see prior discussion in here, now in archived form from a couple of years ago) but soem other editors disagreed without really explaining quite why.

What we have, at this writing, has largely been stipped of that contextual background and is a lesser article as a result. It is not even remotely near featured quality at this time, for that reason alone. I think it should be built in such a way as to qualify for FA status. And it should nto be all that hard to get there. But on WP, since all is hostage to all, it is difficult to jointly reach that level of quality. Nevertheless, I think we should strive to do so.

As for the anticipation of DH, we should note the GCHQ anticipation of some years before. Jevons's work is interesting, but I think is not evidence of priority. The actual application of one-way functions to crypto was not, in fact, accomplished, though it could very easily have been done, at the time there being no tec hnical imedimenta to do doing so in theory. In practice, of course, the lack of high speed computation posed a certain limitation in actual practice. In US law, at least, an invention has not occurred until one has reduced an idea to practice. A mere idea is often not sufficient. ww 19:07, 21 April 2006 (UTC)

The Jevons thing was for the history sub-article rather than the overview article. I'd say Jevons didn't come close enough to describing public key crypto to need mention in the overview. However, what the law says is an invention isn't terribly relevant to the history of an idea; mentioning Jevons in the crypto history article is maybe like mentioning Leibniz in an article about computing history, or mentioning Jules Verne in an article about rockets or submarines.

I think I see your point that we should have more basic introduction to crypto concepts but I think we can do that in modern terms rather than dwelling too much on history. I'll see if I can improve on what we have. The airplane article IMO has about the right amount of historical coverage, though it could use some organizational improvements.

Mangojuice is doing a good job adding references. That will help in the quest for FA. Phr 20:13, 21 April 2006 (UTC)

Inline footnotes

Should we switch the article to inline ref-style footnotes? Those are easier to update, I think. Phr 03:04, 21 April 2006 (UTC)

=> User:Cyde took care of it with an automated program. Thanks! Phr 16:24, 21 April 2006 (UTC)

Looks good this way. It would be nice, though, if the references could go back in alphabetical order. Mangojuice 17:06, 21 April 2006 (UTC)

large block deleted. Why?

On 3 June 06, Scircle made an edit and in the process deleted much of hte article. Without an explanation, I'll be back and roll the article back to its prior state. Have to figure that out first, but the loss was large. If someone else has better facility with the WP machinery, please have it!

Alternatively, there may be a reason for doing so, though the edit summary is unedifying. So, an explanation, or I (or hopeuflly somenone who knows what they're about) will roll things back. ww 17:08, 3 June 2006 (UTC)

=> Sorry for that and thank you for reverting back the article. This was a mistake (first step in wikipedia) I will be very careful in my next contributions. (Scircle 20:58, 6 June 2006 (UTC))

References

I just got rid of the last few {{fact}} tags. One I removed without putting in a citation; the request was for a citation for the rise in popularity of elliptic curve crypto; I'm sure it's covered in the sources we already have somewhere, and we really don't need inline citations for EVERYTHING. :) I'm going away for a few days; when I come back, I'm going to take this article to WP:FAC and see what happens. Mangojuice^talk 01:04, 15 June 2006 (UTC)

Good job, Mango. I do have some diffciulty with one edit however. The US export status of this or that crypto product is still controlled by the laws whihch define it as a munition and require an export license. The difference from the prior regulatory regime is that there is now an expanded waived class of products. Used to be 40-bit keys were permissible (for symmetric algorithms), and anything larger was required a munitions export license. The limits are just larger now, but the definitions still apply. If I export an RSA or AES product to N Korea I will be charged under the munitions export control laws with an offense. ww 19:24, 23 June 2006 (UTC)

In 1996, control of the export of cryptography was preempted lumped in with the Commerce department (after this point, it isn't really fair to say that crypto was "classified as a munition"). Until 2000, basically, "weak" crypto could be used for export while strong crypto could not, but this was rolled back as well. But in 2000, the restrictions were eased again. Now, basically ANY crypto product may be exported without a license, except if (1) it's going to an embargoed country, like N Korea (but this is no different from ANY other export to those countries), or (2) if the end-users are foreign governments, rather than individuals. In the latter case, licenses can be obtained. So you're right about exporting to N Korea, but that's because N Korea is under a US embargo, not because the crypto is strong. You could send that product to, say, Japan without any special permission, though. Mangojuice^talk 21:19, 23 June 2006 (UTC)

Which bureaucracy administers a statute or regulation doesn't much change the underlying regulation, though it may, as it did in this case, result in moving the boundaries of definition without changing the underlying rubrics. It's my understanding that anyone attempting to export a crypto product beyond the currently permitted boundaries requires a license and without one is subject to prosecution. Any crypto to N Korea etc requires a license, which will be I gather routinely denied. ww 02:43, 24 June 2006 (UTC)

That's true. However, if you look at what the boundaries are, they're basically the same as any other product someone would want to export. It may be illegal to export crypto to N. Korea, but it's also illegal to export blue jeans or soap there: it's an embargo that's the issue there. Anyway, returning to the article: we could make this all a little more clear, but I think that saying "crypto is still a munition" requires more to back it up than we have; I'd want to see a source from legal experts describing it that way, deliberately, after the 1996 change. I'm not sure whether the Munitions Act of 1954 was repealed with respect to crypto, or just overridden. Mangojuice^talk 02:52, 24 June 2006 (UTC)

M, Leaky memory reports here. The changes in 96 were prompted by complaints (largely from the financial industry) and were lmiited to those with approved uses. Anything more than the previous limits for other than the approved uses, was still verboten. The next relaxation (in 2000) I think, was to extend that same permission to nearly all users. I agree about the embargo to say, N Korea, except that some exports are allowed (as for instance food after a particularly poorly managed harvest there). No permits will be granted, irrationally given access elsewhere to good cryto, for crypto to N Korea. The 54 Act is still in effect (neither repealed nor overridden), and it was that I was concerned to get at. The permitted bounds have been extended, but they could be (in principle anyway) retracted again. I wanted Readers not to take away that the US has a free market in crypto. It doesn't, though this has little practical effect for the moment. ww 20:54, 3 July 2006 (UTC)

The relaxation in 2000 was due to the govt mostly-losing Bernstein v. United States and beating a strategic retreat by relaxing most of the restrictions before the courts did it more completely. The stuff about exporting to North Korea is sort of pointless since NK's main trading partner is China, and you can buy pirated Windows XP disks (containing 128 bit SSL) in Chinese computer shops for about 50 cents a pop. There is nothing any government can do about it any more on the client side; the toothpaste is out of the tube. Further attempts to control private communications will likely involve crackdowns on the internet as a whole, rather than on specific types of software. I put something into the article about ubiquitous browsers with TLS; I also should have put in something about email clients (MS Outlook and Mozilla Thunderbird) that can speak IMAP or SMTP over TLS, and can also exchange S/MIME messages, but I should probably check on the details first. --Phr (talk) 06:47, 10 July 2006 (UTC)