Wikipedia talk:WikiReader/Cryptography
From Wikipedia, the free encyclopedia
Contents |
[edit] Ratings are counterintuitive
Er, isn't the measure of "Work required" kind of counterintuitive when the other measure is "include?" That means a perfect article for this Wikireader would be 10, 0. Wouldn't it be better to have one be 10, 10? So perhaps reverse the sense of that category to be "completeness." Fuzheado | Talk 06:22, 14 Jul 2004 (UTC)
- I think you're right; I've reversed the ratings so that (10, 10) is the "perfect" WikiReader article — thanks for the suggestion. — Matt 06:34, 14 Jul 2004 (UTC)
[edit] Proposed articles
I'm not sure where to suggest including an article, but I liked Rot13. It's interesting and accessible to the layman, and somewhat humorous as well. Isomorphic 03:23, 17 Jul 2004 (UTC)
- I agree (I've added your suggestion to the various stupidly-convoluted sections on the main page!) — Matt 17:02, 17 Jul 2004 (UTC)
I think something about the Web of Trust and keysigning parties would be useful to include in the Reader. Lunkwill 19:39, 29 Jul 2004 (UTC)
- I don't see why not; while they're not major topics, they're not overly technical, and don't seem like they'd need a great deal of work (though a diagram for Web of Trust might be nice). Any objection to adding these? — Matt 03:16, 31 Jul 2004 (UTC)
[edit] Front cover
Perhaps I'm jumping the gun a little here (Phase IV material?), but at some point we'll have to think about having a front cover for this WikiReader. I haven't found any discussion of it so far (as I said, maybe too early?) but I propose people submit suggestions (candidate images, layout) to Wikipedia:WikiReader/Cryptography/Front cover.
Compare the elegant http://de.wikipedia.org/wiki/Bild:WR_Schweden_Titel.jpg with http://de.wikipedia.org/wiki/Bild:WikiReader_Portugal_Erste_Seite.png which looks like they forgot about the front cover until the last minute... ed g2s • talk 20:27, 30 Jul 2004 (UTC)
- It's certainly something we're going to have to do at some point; maybe some of User:Wapcaplet's work, e.g: Image:Enigma rotor set.png? — Matt 23:09, 30 Jul 2004 (UTC)
[edit] necessary name change
I've noted the irritant often before, but am distressed to find no pearl developing. Thus, I think the irritant needs to be dispensed with. Purple was not a code and the article title should not be Purple code. If anything it should be Purple (cryptography) as, within crypto, it's never confused with anything else, including the artist formerly known as and now know again as (?). But, the change will require considerable effort to not derange assorted pointers to the article, redirects, and such. Since I have managed to evade learning much about what happens behind the curtain, I think I'm not the best choice to address this. One of our wizards would likely do a much better job. Volunteers? (Hoping, hoping, hoping, ...). Or maybe it should go to an invitation at the general articles needing work page? ww 16:03, 10 Aug 2004 (UTC)
- I've moved it to PURPLE and made Purple (cryptography) a redirect. The change doesn't require considerable effort: renaming pages is often straightforward, as old links often don't require changing (a redirect is created at the old name). — Matt 01:00, 11 Aug 2004 (UTC)
- Matt, Bless you, my son, bless you. Ommm, Ommm, Ommm. I did this once with plain text and plaintext and clear text and cleartext and ended up with some hours of hand adjustments. It was the anticipated pain of that which had deterred me from removing this royal irritant. Perhaps I'll be bolder in future. But (nitpicking never ends you know, and I don't think I should expect again pearls, really) the American military practice of capitalizing everything in sight (has to do with inability to work the shift key on old typewriters I think) doesn't apply in this case. Does the British military do the same idiot thing? The name is not an acronym, but a color (of a paper storage binder, no less) and should be Purple. The preceding Red, Jade, and Coral were also only initial caps. ww 14:09, 11 Aug 2004 (UTC)
- David Kahn uses "PURPLE", and Newton's Encycl. of Cryptology entry starts "Spelled as both PURPLE and Purple;", so I think we're OK — it seems to be military style to capitalise codewords. — Matt 02:50, 17 Aug 2004 (UTC)
- Matt, Bless you, my son, bless you. Ommm, Ommm, Ommm. I did this once with plain text and plaintext and clear text and cleartext and ended up with some hours of hand adjustments. It was the anticipated pain of that which had deterred me from removing this royal irritant. Perhaps I'll be bolder in future. But (nitpicking never ends you know, and I don't think I should expect again pearls, really) the American military practice of capitalizing everything in sight (has to do with inability to work the shift key on old typewriters I think) doesn't apply in this case. Does the British military do the same idiot thing? The name is not an acronym, but a color (of a paper storage binder, no less) and should be Purple. The preceding Red, Jade, and Coral were also only initial caps. ww 14:09, 11 Aug 2004 (UTC)
[edit] AOTD needs updated
I'm not sure quite how to do it, so could somebody please update the article of the day list? I found it quite helpful. Lunkwill 20:07, 20 Aug 2004 (UTC)
- Oops, I overlooked this note; I didn't realise anyone but me found it useful! I've a feeling, though, that getting an article up to scratch each day is going to be too optimistic; perhaps an "article of the X", where X is the appropriately long period of time would be better?
-
- I liked the fact that new articles came into view every day. I only contribute to a fraction of articles, so serious edits only happened every few days anyway. So maybe we could do it daily, but then cycle through all the articles several times. Lunkwill 20:38, 10 Sep 2004 (UTC)
- Sure, I've reactivated it now that I've got a script that does most of the grunt work for me! — Matt 13:57, 16 Nov 2004 (UTC)
- I liked the fact that new articles came into view every day. I only contribute to a fraction of articles, so serious edits only happened every few days anyway. So maybe we could do it daily, but then cycle through all the articles several times. Lunkwill 20:38, 10 Sep 2004 (UTC)
[edit] Scope?
Hmm...the articles aren't improving as fast as I'd hoped; maybe we've selected too large a number, or we don't have a sufficiently solid starting point? I'd much rather slow down the project or trim the selection of articles than release a mediocre WikiReader. Does anyone have thoughts on how we might best proceed? — Matt 01:55, 8 Sep 2004 (UTC)
-
- Matt, I've gotten somewhat tied up with other things and so my WP activity has tailed off a bit. I can't speak for others, of course. However, on the general subject of schedules I should perhaps point out the 90/10 rule which has applied to all projects of which I have personal knowledge, and is said in the literature to apply to all projects, so even those I haven't been involved with would seem to partake. 90% of the work takes 10% of the time and the remaining 10% takes 90% of the time. A corollary is the something like 90% of the time the last 10% doesn't get done at all, though I personally think that's a bit much. The amount of work that's been done since the beginning of the Reader project is, I think, stunning considering the situation.
-
- Perhaps the schedule was a bit ambitious? ww 19:40, 9 Sep 2004 (UTC)
-
-
- Yes, I think so; I thought initially that the articles wouldn't need more than a little tweaking here and there, but during the "Article of the Day" scheme, it quickly became apparent to me that it would take much more work to get them up to scratch. It'd probably be a realistic timescale if we were to be happy with "mediocre", but I think we need to insist on top-notch articles for a project like this. What would be a realistic timescale; article of the month? Article of the fortnight (one of those Brit-speak things, sorry)? — Matt 22:21, 9 Sep 2004 (UTC)
-
[edit] Revision of TOC
I'd like to propose a revision of the TOC. Here's my suggestions:
- Drop El Gamal — not a central crypto topic, and our article is apparently beset by problems anyway. Skip it?
- Add Voynich Manuscript — a Featured Article and of general interest
- Drop Beale ciphers — I think we should have only one article on an "unsolved crypto mystery / hoax", and I think the VM is a better option.
- Add M-209 — this article is pretty good; if we have a strong article, I think we should include it
— Matt 05:20, 22 Nov 2004 (UTC)
Matt, Sorry to just notice this. I'm not able to spend as much time prowling as I was so more than before escapes. El Gamal is an important alternative to RSA and at the core of the DSS and others. There is an argument for retaining it, but I would agree not an overwhelming one. As for Voynich Manuscript, there is too much possibility that it is/was actually a hoax to act as though it's an actual unsolved cypher example. I agree that we should probably not have several crypto mystery/hoax examples, but the Beale business is both clearly a cypher (even if a hoaxed one) and the other two messages are still unsolved (though possibly hoaxes) and, to boot, have been the subject of considerable amount of media attention. In this respect the VM is rather less notable, as being obscure. I would retain Beale and not add VM. ww 18:28, 2 Feb 2005 (UTC)
- Oh, I would have thought VM would be more notable; maybe it's higher profile in Europe than in the States? In the last year or so I've seen a TV documentary and browsed a recently-published book on the at Amsterdam airport, both on the VM, but I haven't heard much noise about the Beale ciphers. But I think the fact that the VM article is Featured (and full of pretty pictures) while the Beale article needs tons of work probably argues it best. — Matt Crypto 11:59, 14 Feb 2005 (UTC)
[edit] Need a "big numbers" article
Early in the semester, I give my students a list of "big numbers", because on paper 2^64 doesn't look that much smaller than 2^128. AC has a great list, and we could also use some discussion on how those apply to computers (esp wrt Moore's law). Too many laypersons think 2^128 means you just wait a few more years or run it a little longer, or that a table of primes < 2^1024 is a good idea. I wrote a little in Key (cryptography), but we need a whole article. Lunkwill 22:46, 22 Nov 2004 (UTC)
- I think something like this would sit well in key size, which is in the WikiReader TOC. I did like your addition to Key (which I think got lost somehow):
- It is currently estimated that any cryptosystem which requires approximately 2128 or more mathematical operations to break will be secure for the forseeable future. 2128 is an extremely large number; all the computers in the world combined have computed far less than 2100 operations, and 2128 is hundreds of millions of times larger than 2100. Consequently, if a cipher can only be broken by trying all possible keys, a 128 bit key length is sufficient, since there will be 2128 possible keys to try.
- We should certainly add this to (at least) key size (do you have a source for "all the computers in the world combined have computed far less than 2100 operations" by the way?) — Matt 23:36, 22 Nov 2004 (UTC)
- Ah ha! Large numbers already exists. I just added a section on computing; perhaps that section, at least, should be added to the reader TOC. (BTW the 2^100 value seemed safe to me considering the md5 cracking estimate that 2^64 would take a few thousand PCs a few years). Lunkwill 01:45, 23 Nov 2004 (UTC)
- Yes, that would fit in with distributed.net breaking a 64-bit key in under five years. But "all the computers in the world combined have computed far less than 2100 operations" — I'm also thinking here of microcontrollers in all sorts of electronic equipment and the like — it's not inconceivable that there are billions of these things ... I just don't know, but I wouldn't like to add it as an indisputable fact without citing a source. — Matt 14:28, 23 Nov 2004 (UTC)
- Agreed, although I don't know where we'd find such a source. 2^100 would be 64 billion times a 2^64 workload, which seemed reasonable to me, assuming there aren't too many acres of classified supercomputing laying around. If 2^64 takes 1000 modern PCs a year of work, then a billion machines would still take 64000 years to do 2^100, or a trillion /current/ machines 64 years (which would have been about the beginning of the computing era) Lunkwill 22:19, 23 Nov 2004 (UTC)
- Yes, that would fit in with distributed.net breaking a 64-bit key in under five years. But "all the computers in the world combined have computed far less than 2100 operations" — I'm also thinking here of microcontrollers in all sorts of electronic equipment and the like — it's not inconceivable that there are billions of these things ... I just don't know, but I wouldn't like to add it as an indisputable fact without citing a source. — Matt 14:28, 23 Nov 2004 (UTC)
- Ah ha! Large numbers already exists. I just added a section on computing; perhaps that section, at least, should be added to the reader TOC. (BTW the 2^100 value seemed safe to me considering the md5 cracking estimate that 2^64 would take a few thousand PCs a few years). Lunkwill 01:45, 23 Nov 2004 (UTC)
-
-
-
- I like the point Lunkwill makes here, though I'm not any more able to see how best to make it. Our Gentle Reader Reader will likely be like most, and miss the import of things outside his/her normal ken. The difference between large and (much) larger key spaces is one such readily missed thing.
-
-
-
-
-
- Another is the immense difficulty (although too subtle to be seen by nearly all) of assuring adequate entropy in random numbers. Just past evening I had a wrangle, with an ex programmer / consultant to US financial industry firms, about the inadequacy of choosing random account numbers for daily purchases of positions in specific securities (to conceal knowledge of them which might distort the market). Eg, Merrill Lynch buying 10M shares of AT&T (being acquired as this is written by one of its former parts), which if known would cause reactive activity (buy/sell call/put) by others. He maintained that generating a random 'account number' by taking the time in seconds, the date, a process ID, etc and stirring was sufficient. Obviously not a Bondian! I am afraid that explaining that it was not, using the example of Netscape's Web browser SSL key generation blunder of many years ago (discovered by Wagner and Goldberg at UC Berkeley), may not have been persuasive. He's a remarkably intelligent man; perhaps I'm merely a remarkably incapable explainer. This is remarkably hard stuff to get across. Again, I've no magesterial suggestion on how to succeed in doing so. ww 18:43, 2 Feb 2005 (UTC)
-
-
[edit] Kerberos
Wow, firstly: fantastic job! I ws wondring if you guys would cover Kerberos or not as part of Cryptography. - Ta bu shi da yu 08:34, 16 Dec 2004 (UTC)
- Yes, good suggestion -- it's quite an important protocol. — Matt Crypto 08:46, 16 Dec 2004 (UTC)
[edit] Revision of TOC 2
More TOC thoughts: I suggest we
- Drop Classical cipher — Currently a stub, I think the material would be covered well elsewhere, such as in substitution cipher, transposition cipher and history of cryptography.
- Drop Polyalphabetic substitution — the topic is also treated in a subsection of substitution cipher, which covers it in more depth than Polyalphabetic substitution at present.
- Add Kerberos (protocol) — as suggested by User:Ta bu shi da yu.
— Matt Crypto 15:09, 22 Dec 2004 (UTC)
- Matt, Now that I've noticed the first TOC Revision post (above) I might as well throw in my 2 hundredth Euro here as well.
- Our readers will, I assume, not have over much crypto perspective. If so, it will be of value to them to make clear (and not by inference in several articles) the progression of complexity in cypher construction, as this will ease understanding of modern cyphers by giving a comprehension nugget around which to orient as a defense against being drowned by detail. (Rather like, "Aha! This insane shuffling in the DES diagram is just a really complex and messy transposition cypher with some substitution cypher business going on now and then. Not so impossible to make any sense of after all!") Simple substitution --> polyalphabetic --> modern -- at the most schematic.
- I agree the polyaphabetic substitution article is rather stubby and probably unsuited to the Reader in present form. The substitution article is better, though to be fair it's rather long which may be seen to be the opposite vice. I don't think it can be much shortened w/o too much damage (a looonnng edit session sometime ago leads me to hold that opinion most firmly), so perhaps this perspective point might be best made in a (revised and destubbified) classical cypher article?
- As to Kerberos, I agree it's an important protocol, but I fear that any adequate article on it will be over detailed for the Reader (both sorts). Our Enigma article is getting there. The article itself is now getting so detailed that I expect it will be further divided into subarticles as has happened already several times. Perhaps an article on authentication/access control protocols is indicated, and if adequate, should be included in the Reader (only one kind this time)?
- Comments? From others as well? ww 18:58, 2 Feb 2005 (UTC)
[edit] Suggestion for the final product
I am aware it was just a prototype, but the example reader made it very hard to tell from a given random page what article it was a part of. Ideally articles should have more of a separator, such as a line, or even as separate chapters. At the least, the top of each page on the right (for book form, or instead all pages) should say what article the page is a part of. Otherwise it is looking good overall and is making progress. Thanks for all of your work. - Taxman 21:06, Feb 21, 2005 (UTC)
- Thanks, those are good suggestions for the final formatting (which I'm not looking forward to..!). — Matt Crypto 20:24, 24 Feb 2005 (UTC)
[edit] Wikipedia:Stable versions
You can use Wikipedia:Stable versions to select your articles. -- Zondor 14:50, 7 January 2006 (UTC)