Wikipedia talk:WikiProject Cryptography/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Hash functions based on block ciphers

I am thinking of merging these three small articles Matyas-Meyer-Oseas hash, Davies-Meyer hash and Miyaguchi-Preneel hash into one single more detailed article called something like Hash functions based on block ciphers. Similar to how all block cipher modes are described in the one article Block cipher modes of operation. I will reuse some of the text about hash functions based on block ciphers I wrote in Cryptographic hash function. Any comments or point of views? --David Göthberg 01:09, 26 January 2006 (UTC)

I think it's a good suggestion. It'd be easier to compare them, rather than have to flick between several short articles. — Matt Crypto 08:06, 26 January 2006 (UTC)

Yay! As a mergist, I totally agree. Plus, this would allow us to give some coverage to important work in that area other than those three constructions, like the Preneel-Govaerts-Vanderwaal result for instance. Mangojuice 21:06, 27 January 2006 (UTC)

Ok, the merge is done, sort of. New article is Hash functions based on block ciphers. There is some more information in the old Davies-Meyer article about an attack that I did not merge since I did not understand it. If I just cut and paste that paragraph it will make even less sense since it depends on the notification established further up in the old article and I have changed that notification in the merged article. So for now I left the old Davies-Meyer article as it is (not turned it into a redirect). I left a note about it and link to it in the Davies-Meyer section of the new article. I hope some one can make sense to it and rewrite it properly and merge it some day. --David Göthberg 06:09, 28 January 2006 (UTC)

Hash template and MACs

I took the freedom of updating/extending the Template:Cryptographic hash functions and adding it to some more pages, like the obvious page: Cryptographic hash function. I also noted that there is no template for MACs. But since a MAC template would be very small and MACs and hashes are so closely related I instead suggest that the Template:Cryptographic hash functions is extended to also include MACs. Also it would perhaps encourage any one that reads about hashes to learn a little about MACs too. I suggest extending the template like this:

• Title changed to "Cryptographic hash functions and Message authentication codes (MACs) - edit". (But no change to the template name/URL.)
• "Algorithms:" changed to "Hash algorithms:".
• Adding "MAC algorithms:".

If no one disagrees I will do this extension in some days.

Oh, and a note to Matt Crypto while I am at it: Stay on your wikibreak and take care of your wife, we'll take care of this place meanwhile! :))

--David Göthberg 13:03, 2 February 2006 (UTC)

So, since no one protested I have now added MACs to the hash template and added the template to all MAC articles. While I were at it I also created a MAC category: Category:Message authentication codes. --David Göthberg 21:18, 9 February 2006 (UTC)

Template:User WikiProject Cryptography

I spent some time being silly. I designed a user box for us that edit crypto pages! I just have it at my test page for now but if you guys like it I will move it to {{Template:User WikiProject Cryptography}}. The current address of it is {{User:Davidgothberg/Test}} and it looks like this:

Most excellent, it's about time we caught up with the times (aka the Userbox fad!). Please do put it live whenever you're ready. — Matt Crypto 14:33, 3 February 2006 (UTC)

Ok, moved the template to its official place: {{User WikiProject Cryptography}} and it now looks like this:

This user participates in
WikiProject Cryptography.

--David Göthberg 16:45, 3 February 2006 (UTC)

Note, others have edited the template since I made it. I don't like the current bright colours of it. Ah well, doesn't matter much. Just so you don't blame me for the colours... --David Göthberg 18:49, 31 July 2006 (UTC)

Crypto stub template

Oh and I did a minor fix to the {{Crypto-stub}} template. I added a <br> tag so it doesn't put itself so very close to the last line of text in the pages it is used on. --David Göthberg 14:00, 3 February 2006 (UTC)

Sure. I probably preferred it without the space (in line with most other stub tags), but I don't care enough to quibble ;-) — Matt Crypto 14:33, 3 February 2006 (UTC)

Aouch, and I who thought every one must be anoyed with the stubs squesing so tight to the last row. Ah well, lets se what the others think before I revert myself. --David Göthberg 16:45, 3 February 2006 (UTC)

Smoke without fire

Just back from SASC 2006. There was some interesting discussion there about the problem of "smoke without fire" - that is, cryptanalytic attacks which have no validity, but which make the general public afraid of using the cipher because they're not able to assess that the attacks are not valid. I know that those who sell licenses to patented algorithms feel particularly strongly about this danger, but it's a difficulty for the whole community. The example everyone gave was Li An-Ping's attacks on Salsa20, but it's a general problem. Do you have any thoughts on how Wikipedia can respond positively to give an accurate impression to the public without violating the usual rules of NPOV, verifiability, and so forth? Thanks! — ciphergoth 11:12, 4 February 2006 (UTC)

(I hope you don't mind; I've duplicated this post this to Wikipedia talk:WikiProject Cryptography). If a result has been published in a reputable, peer-reviewed place, then I would think we can safely assert the result without hesitation (unless it's been challenged elsewhere, of course). If it's not been peer-reviewed, we should probably hedge it along the lines of "In 2006, Smith claimed to have found an attack on SmegoCrypt...", and then add the response to it by the algorithm's designers as soon as it's available, or any other (reasonable) skeptical claims. We could even add a clause along the lines of "the result has not yet been published" if the author of the attack hasn't got a particularly convincing reputation. One of the benefits of Wikipedia is that it can be cutting edge, but, as you point out, the flip side is that we don't want to encourage the spread of rumours. — Matt Crypto 15:28, 4 February 2006 (UTC)

I remember Bob Silverman having a major problem with this issue in the use of "strong primes" for RSA encryption: it's preventing an attack that would be dumb to worry about. Take a look at the safe prime article, where I tried to inject a little perspective on the importance of safe/strong primes for factoring. Although the view that strong primes are unnecessary for RSA has been published, I think it doesn't need to be to put two verifiable facts together: that (1) strong primes are required for RSA to make the number less vulnerable to certain factoring methods such as Pollard-rho, and (2) Pollard-rho is much less efficient for average numbers than general purpose methods like the number field sieve. What couldn't be added is that (3) therefore, requiring strong primes is stupid: that's POV and unverifiable, even if it's the natural conclusion from (1) and (2). I think a similar thing could be used anytime there's a "smoke without fire" kind of situation. Another useful point: we should never describe something as "broken:" if an attack is worth including, it's worth explaining it, which helps prevent people from getting too panicked. Mangojuice 21:22, 28 February 2006 (UTC)

Articles for the Wikipedia 1.0 project

The Wikipedia:Version_1.0_Editorial_Team is looking to identify quality articles in Wikipedia for future publication on CD or paper. They recently began assessing using these criteria, and are looking for A-class, B-class, and Good articles, with no POV or copyright problems. We have six featured articles, iirc: Caesar cipher, Data Encryption Standard, Enigma machine, Marian Rejewski, ROT13 (doh!) and Voynich Manuscript. What other high-quality crypto articles do we have? — Matt Crypto 18:16, 4 February 2006 (UTC)

Matt, The Reader project articles have had a considerable amount of effort given to them and quite a few of those ought to qualify. Perhaps several of the cryptiacs could get together and jointly vote on classifying these (and others) according to these criteria? I suspect that comment from non-cryptiacs won't be adequate to evaluate the crypto technical side of such articles. On the writing side, of course, it seems there is never an end.

Mailings to those who've signed up at the Project as members? Is there a way to do this other than manually? ww 00:06, 5 February 2006 (UTC)

Thanks a lot, it looks like you made the contacts for us! That's a good set of FAs to start with. If you want to put together a list, you could consider a worklist as several other WikiProjects have- they are a good way to track articles and encourage improvements. In the meantime, please feel free to add/edit our listing (once I get time to include it) in our table here. Thanks, Walkerma 05:38, 24 March 2006 (UTC)

Certification of voting machines

We do talk about this stuff on the Cryptography list, but seems out of scope for this project as defined. Looking for an appropriate project to clean it up?

--William Allen Simpson 15:01, 6 February 2006 (UTC)

Well, I guess this project is as close as you can come to that subject. However, it has been proven that electronic voting machines can never be made even close as secure as paper ballot systems. (And I don't mean the weird US paper systems with ambiguous hole punching etc.) So I am all against such machines. To me the notion of "certification of voting machines" is a joke, or rather a smokescreen to trick the masses to believe those machines are secure. I once worked a short time for the EU e-voting project. Their system got seriously hacked. (A city in Germany according to the machines had twice the number of votes than people with the right to vote in that city. A hacker group had previously promised to hack the system and afterwards claimed it was their doing.) Some of us who worked with it also showed the proofs that e-voting is a very bad idea. However the bureaucrats and some high politicians pressed on and want to use it all over the EU. I wonder if they are just stupid or if they have evil plans? --David Göthberg 22:47, 9 February 2006 (UTC)

In the US, the absurdity of hanging and pregnant chad in 2000 in Florida resulted in Congress requiring all states to adopt 'better' systems. Many businesses, some of them very much politically biased, saw and opportunity and began to press their political friends to award them the contracts. There has developed in the last decade+ in the US a return to an earlier time of corruption and favoritism. since Republicans are currently dominant, much of this favoritism was toward firms which supported (with $ and otherwise) Republican candidates and positions. Whether this is stupid or evil is not so clear, but I think it's corrupt if nothing else.

At least one heavily Republican voting machine company was caught with inexcusably sloppy design and coding practices for its crypto software. As they claimed their software was a trade secret, inadvenrtently making it available on their web site was unfortunate. But of course the trade secrecy meant that no reasonable or sensible inspection of the actual code was possible, so nothing could actually be said -- in an informed and so worthwhile way -- about the security, competence, and relability of the software which counted and store the votes. An appalling and intellectually bankrupt performance, defensible only as a way to avoid awkward questions about the quality of the security critical software running on the machines being pressed on the decision makers. Ghastly, simply ghastly. ww 06:21, 12 February 2006 (UTC)

PRF / Pseudorandom function

I saw PRF in a cryptography-related context and I came to wikipedia hoping to find a good definition. PRF is a disambiguation page which included Primitive recursive function but not Pseudorandom function. I just added Pseudorandom function to PRF. But Pseudorandom function is currently a redirect to Pseudorandomness and I do not find there a good definition of what PRF or Pseudorandom function means in the context of cryptography. I would guess that Pseudorandom function should be its own article and the redirect removed, but I leave that to someone who knows better the subtleties of cryptography. (It seems to me that Talk:Pseudorandom_function is the right place for this, but it seemed no one would see it there. Perhaps it should be moved there if/when the redirect is removed.) Tim Shepard 21:53, 9 February 2006 (UTC)

Ehm, the articles you are looking for are Random number generator, Pseudorandom number generator and Cryptographically secure pseudorandom number generator. So no worries, we got the info! I will fix those links etc. --David Göthberg 22:42, 9 February 2006 (UTC)

A PRF is "a family of functions with the property that the input-output behavior of a random instance of the family is computationally indistinguishable from that of a random function". It is a keyed function. A PRG (pseudorandom number generator) can generate a PRF using a contsruction known as Goldreich-Goldwasser-Micali (GGM). A PRF can be used directly as a block cipher using xor or as a MAC. The Wikipedia articles on PRNG et al are lacking at the moment. —Quarl ^(talk) 2006-03-02 04:48Z

Merkle-Damgård article?

I am thinking of making an article about the Merkle-Damgård structure.

When I made the article Hash functions based on block ciphers I noticed that that article needed an explanation of the Merkle-Damgård structure. So I copied the Merkle-Damgård section from Cryptographic hash function. However some guys in the crypto chat I spend time in read it and missunderstood the length padding so I expanded the explanation in a way they understood. Now that section has become rather large. And the same expanded explanation would be needed in the Cryptographic hash function article too. So instead of having the same long section in two articles it would probably be better to move it to a separate article and just have a short resumé in the other articles and the usual link to "Main article: Merkle-Damgård construction".

So, what do you guys think about it?

--David Göthberg 22:51, 9 February 2006 (UTC)

I agree, and thanks for bing willing to undertake it. Good for you. ww 06:23, 12 February 2006 (UTC)

Ok, the article is done. Hope you guys like it. --David Göthberg 03:43, 15 February 2006 (UTC)

Template:Public-key cryptography

I made a template {{Template:Public-key cryptography}} since I think it is needed. I don't know that much about assymetric crypto so I don't know if it has the right content now but anyway it's a start. I only added it to the bottom of the Public-key cryptography article so far. --David Göthberg 17:20, 11 February 2006 (UTC)

Good stuff. One thought: we could consider distinguishing between key-agreement algorithms, encryption algorithms and signature algorithms. Would this be useful? — Matt Crypto 18:22, 11 February 2006 (UTC)

Yes, I had the same thought and are all for such dividing. I just don't have the knowledge to do that so I will have to leave that to you guys. Oh, and I had some problems to decide between the names for the template: "Asymmetric-key cryptosystems" (used for the category) or "Public-key cryptography" (used for the main article). I guess it doesn't matter much (since only us editors ever sees the template name) but since the main article is in the top of the template I went with that name as template name too. --David Göthberg 23:02, 11 February 2006 (UTC)

dg, The very first comment here (now in archive1) bears on this issue. As there are asymmetric key algorithms which don't have the public key--pivate key property, there are good taxonomic reasons for not conflating the two terms. To the extent we can manage, the verbal map we use should match the teritory; it's worth exerting some effort to arrange it so. In addition, public key cryptography has (sloppily) acquired a penumbra of additional related meanings in lay usage which is back influencing technical meanings. As usual, English' anarchic tendencies are impediments to those with tidying minds.

On another issue, there was a proposal (at breaking, in archive1) which met with some acceptance, but which has been honored in the breach and so leaves me more or less in the same situation of disatisfaction with WP coverage as before. I STILL want to know the current break status of every algorithm (if known) for which there's a WP article. It's amajor pain not to be told, if the knowledge is available, and there should be an explicit statement if there are no results as of <date>. We WP cryptiacs really should do something more or less like that suggestion. You've been active in cleaning up things of late, so your opinion would be particularly relevant, I think. Comments? Thoughts? ww 17:49, 18 February 2006 (UTC)

Hi ww. Regarding asymmetric crypto versus public key crypto I have this to say. Some years ago I used to teach computer security both in the industry and sometimes as guest lecturer at some universities. I noticed most people have huge problems to keep the terms symmetric crypto and asymmetric crypto apart. They simply sound too similar and can be misunderstood in any number of ways. So after trying many ways to teach it I resorted to first use the terms traditional crypto versus public key crypto and then later on start to mix in the terms symmetric crypto and asymmetric crypto. Here on Wikipedia our readers are both beginners and old security geeks. So I suggest we too should use both sets of terms and mix them to make it easier to read for the beginners but at the same time teach them the advanced terms for it.

And regarding the lack of information in the articles as to how broken or not each crypto is. This is Wikipedia, YOU can edit it!

I agree that such info in the crypto articles is very nice, but it obviously is a lot of work to find such information. So feel free to research it and add it. I think most of us will like that info.

--David Göthberg 07:52, 21 February 2006 (UTC)

dg, I agree the terminolgy is a dog's breakfast re asymmetric, symmetric, and public key. The trouble with your proposal, with which I have some sympathy, is that none of us cryptiacs have daily or thrice weekly, or three of four times a term in exams, contact with readers, and so cannot disabuse them of the (wild and wonderful) ways they can get tangled in the tarball of crypto, including the terminology. I hold no brief for any particular terms, save that we should use them consistently in such a way as to avoid entangling our less than security geeky readers in the giant yarn ball of confusion. So whatever we use, I suggest strongly that we should be encyclopedic -- ie, non confusing. We're not in an interactive teaching situation. I've not heard anything better than asymmetric includes all public key-private key ciphers as well as those without the public key-private key property. Secret key seems reasonable for traditional symmetric ciphers, but lacks the clarity of contrast with asymmetric key ciphers. This distinction is, ahmm, the key one.

As for being bold and doing the research myself, thanks for the thought. I've concentrated in the crypto corner and, in the crypto corner, on at clarity of presentation, including conceptual clarity. I've stayed away from crypto technical articles in part because I'm not current with the literature, have little access to a reasonable academic library, and my math is some years rust encrusted. We have several folks here who are current with the literature (Matt and arvindn, for two) who are much more likley to get the information correct than I. I refrain, not from being insufficiently bold, but from a well-founded conviction I'll manage to introduce errors which may have an unfortuantely prolonged life if not caught by, for instance, Matt or arvindn. And to top it all off, I've had to dial back my contributions to the crypto corner as other things have increased their calls on my time. I'm not the ideal choice to be bold in this instance. But thank you for the nomination. ww 20:13, 21 February 2006 (UTC)

Disambiguation naming

What generic class should we use to disambiguate? For example,

• Enigma machine
• Hebern rotor machine
• Mercury (cipher machine)
• NEMA (machine)
• Omni (SCIP)
• Pinwheel (cryptography)

List of cryptography topics seems to be all over the map! What seems to have happened in another area, "V4 engine" is used for the main title, and "V4 (engine)" as a redirect. I propose that we do the same with "machine" here.

But what about cipher (cipher), (cryptanalysis), cryptography (cryptography), (cryptology), (security), et alia? No consistency in words, let alone Naming conventions....

--William Allen Simpson 18:39, 19 February 2006 (UTC)

Hi William. Well, different subjects need different naming. So I think we can not use one single word for all such disambiguation. But first some basic naming as far as I understood that most of us like it:

• A cipher, not a cypher or a crypto.
• Cryptography, not cryptology or crypto.

So for a cipher that has a name that can mean many things this form seems best to me: Solitaire (cipher). And for a hash then the form Tiger (hash) seems good since Tiger (cryptographic hash) seems a bit long. Calling them Solitaire (cryptography) and Tiger (cryptography) would be too general I think. Although that depends on from which "distance" you look at it. However for more general articles that is definitely a nice form, like this: Key (cryptography).

For things like secure communications protocols and other such methods it is a bit more complicated. For instance Kerberos. Should it be named Kerberos (protocol), Kerberos (cryptography), Kerberos (security) or perhaps even Kerberos (computer security) since it is not about physical security? Well, (computer security) is a bit long so (security) might still be better but less correct. But it is a protocol so (protocol) might be ok too. But protocol can mean MANY things, even things outside computer science. In this case I personally would prefer the more general Kerberos (cryptography) but I think many of you might disagree.

For cipher machines I think either the normal name we usually use should be used or the ending (cipher machine). For instance Enigma machine is ok since that is the common name for it and there could be separate articles named Enigma algorithm or Enigma (cipher). Although Enigma (cipher machine) would be very ok for me too. I find NEMA (machine) wrong since (machine) is way to general, it should be NEMA (cipher machine). But Pinwheel (cryptography) I find correct since it is not a whole machine, just a part of a machine. And Pinwheel (cipher machine part) would be way to long. Your Omni (SCIP) example is scary. That should probably be renamed to Omni (cipher machine).

Well, that was my ten cents on the matter. --David Göthberg 08:57, 21 February 2006 (UTC)

was and dg, The business of <whatever>(cryptography), and similar, was begun to distinguish such things as key(music) from key(cryptography). And since cypher names seem to be chosen for amusement (eg, blowfish, serpent, pike, square, loki, safer, assorted pharoah names, ...) there was also some need to avoid indirection dientangling disambiguation articles. As dg points out, the (rubric) tag is a little hard to choose since it can have many values. But, I suggest that, as this sort of thing is mostly invisible to readers, as long as we cryptiacs can straighten out the intent, there may not be a real problem, however irritating to those of a neat bent. Perhaps a librarian, with both inborn and trained neat genes would be a good consult?

As for cipher and cypher, there is a long record of a teapot tempest on the subject. See the cypher v cipher link on the Project page. In fact, both of you might want to contribute you y's worth to the discussion. Cryptography v cryptology was settled, for WP crypto corner purposes, not long after I registered on WP, by the crypto folk then active. We decided to fold the then extant cryptology article into the cryptography article and to use cryptography as the highest level noun for WP crypto corner purposes. The intent was to save confusion and duplicate articles, and my memory of the reason for choosing cryptography is that was more common in civilian discussions (eg, Schneier's books). A pragmatic decision only. ww 20:29, 21 February 2006 (UTC)

David's suggestions seem pretty sensible to me. — Matt Crypto 20:44, 21 February 2006 (UTC)

My feeling is, the (topic) thing we put on ambiguous titles is there as a last resort: Nirvana, for instance, is really the only title you can have for an article about the band Nirvana (band), but "Nirvana" can't be used as the title because that title is taken. We can avoid this whole thing by being descriptive. For example, don't use Tiger (hash) but rather Tiger hash function. Don't use Solitaire (cipher), use Solitaire cipher. Only when the conflict is unavoidable, such as Pinwheel (cryptography), should we use the parens. Mangojuice 21:09, 28 February 2006 (UTC)

Cipher vs cypher

And re:cipher vs. cypher, that discussion has clearly died, so let me make a proposition: as "cipher" is the overwhelmingly popular form, we should always use it, except to note that the unpopular form exists and is accepted. I have no problem with "cypher" on redirect pages, just in case. Furthermore, it may make sense to use "cypher" in some circumstances if there's a good reason for it (for instance, if quoting the name of a book or paper with "cypher" rather than "cipher" in it. Mangojuice 21:09, 28 February 2006 (UTC)

M, A few points:

First, this comment really belongs at Wiki_roject_Crytography at cypher v cipher not here.

Second, 'unpopular' isn't really the right take on lesser used but accepted variants of English words.

Third, there is a not insubstantial group of WP cryptiacs who favor and would use cypher and its various forms in preference to cipher et al. They include me, a writer on the subject, jon a professional cryptographer who worked at PGP Inc with Zimmerman and earlier with Elgamal and others who would use cypher save that his editors harass him into cipher, and jdf now on the Metawiki board if I understand the table of organization properly, who is a student (or was) at U Wqrwick and prefers and uses cypher (save a pusillanimous cave due to pressure from others, see the summary of position listing at cypher v cipher). The matter is not thus, as claimed, dead. Or settled.

Fourth, the matter is not of sufficient moment to ride roughshod over those who prefer cypher. It is conceded to be a teapot tempest after all, by all involved. The general tone is one of protest letters to the Times in high dudgeon over nothing much. So I disagree that this matter rises to the importance of something for which there should be a formal WP policy or even a formal WP crypto corner policy.

After all, ALL the dictionaries allow both as variants and acceptable. And WP is not about setting correct usage of words like Merriam-Webster's Second International Unabridged. WP has, instead, taken a non-prescriptionist policy, rather as did Merriam-Webster's Third International Unabridged. Recall that both British (ie, Commoonwealth) usage and American (ie, Websterian) usage (vocabulary, spelling, etc) are both explicitly permitted on WP. And this is indeed a formal WP wide policy (except for the non English Wikipedias). ww 22:12, 28 February 2006 (UTC)

Two points. One, forked discussions that cool off should be abandoned. There have been a total of about 6 edits to that page in the last 16 months, and I've made THAT mistake before. Second... who needs a crypto policy? I haven't seen "cypher" usage as a problem before and I don't now. Personally, I would change away from "cypher" whenever I see it, because I've never encountered that spelling in reputable, modern writings, so to me it looks odd and alternative, NOT like an encyclopedia entry. But that's just me. Heck, I don't think this wikiproject has enough members or activity to even HAVE policies, other than just guidelines for helping each other out. Mangojuice 00:36, 1 March 2006 (UTC)

ww invited me to comment on the ci / cy discussion - possibly because I used 'cypher' in a note about the Cardan grille; but I was referring to the way that Francis Bacon spelt it in 1600. Nowadays I tend to use 'cipher' except in historical quotations. For example, the British G. C. & C. S. was founded in 1919 as The Government Code and Cypher School. --Steve 05:51, 29 May 2006 (UTC)

1,000 articles

As of yesterday, I believe we now have over 1,000 articles on cryptography listed in list of cryptography topics. The English Wikipedia itself is rapidly approaching 1,000,000 articles (998,475 now). Of course, quantity isn't a substitute for quality...— Matt Crypto 09:06, 1 March 2006 (UTC)

Yay! We are 1 percent! Still, I bet we have better average quality in our articles than average wikipedia articles anyway.  :Mangojuice 06:09, 2 March 2006 (UTC)

Yay! We are 1 permille! And that is a LOT for a wikiproject as ours with such a small number of editors. I guess the hero of the day is Matt Crypto who seems to have made most of those articles. So Matt, bask in the glory of the day! --David Göthberg 23:44, 2 March 2006 (UTC)

I'm sure that I can't have created more than 30-50 of those articles, so I really can't take the glory, I'm afraid! — Matt Crypto 11:27, 6 March 2006 (UTC)

Matt certainly does deserve much credit for his work in the crypto corner. Much of the crypto editing support stucture is of his design and implementation, he has consistently patrolled all the articles I look at with an eye for non-WP surplusage, and done so over an extended period.

As one who has been plugging away in the crypto corner for now (acckkk!) 5 years more or less, I think he deserves three cheers from those of us who still haven't figured out the WP scaffolding behind the curtains. A good job, mc, and I endorse dg's comment. ww 12:03, 24 March 2006 (UTC)

Deletion discussion alert

• Wikipedia:Articles for deletion/Nicolas Courtois. — Matt Crypto 11:17, 6 March 2006 (UTC)

MIX nets

I tried finding an article that talked about the subject of MIX-nets, but don't see one. I'm not knowledgible enough to write one but would like to see it added as a consideration for the crypto project. Here's the initial paper by David Chaum from 1981 and there has been much work since: David Chaum. Untraceable electronic mail, return addresses, and digital pseudonyms. Communications of the ACM, 24(2):84–88, 1981.

Ah yes, Mix nets is an important concept. We do have articles about Onion routing and Tor which are more or less the same ideas. Since I have some knowledge in the area I might look into it properly some day. For now I think redirects from Mix net and/or Mix networks to Onion routing would be ok. Do the rest of you guys think that would be ok? --David Göthberg 10:43, 22 May 2006 (UTC)

Smithy code

The article on Smithy code seems rather limited and borders on trivia. Would it be better incorporated into an article on the variant Beaufort which doesn't seem to exist at the moment? GraemeLeggett 14:48, 28 April 2006 (UTC)

I wouldn't think so. The Smithy code is probably not important enough to cover very much in an article on the variant Beaufort, if one existed, and there are links to this article from The DaVinci Code and from the judge's page. The article seems decently written and sourced, and WP is not paper, so it might as well stay. Mangojuice^talk 14:52, 28 April 2006 (UTC)

Elementary Cryptography

Please enter some information for the beginners on this page:Elementary Cryptography

For the beginners

I dont understand why this huge project does not involve anything for the beginners!!! I am sure that many beginners surely refer to wikipedia... and what they would have found is nothing but codes and algorithms that are totally beyond their reach!! Please help the Newbies. This is a humble request

Because Wikipedia is an encyclopedia, and thus striving for precise and factual information; Wikipedia is not an indiscriminate collection of information (a book, a collection of tutorials, manuals, FAQs or guides). Anyone is, of course, welcome to write an introductory book about cryptography on Wikibooks and refer to it on Wikipedia (from relevant articles). However, that's out Wikipedia's scope. -- intgr 13:10, 10 November 2006 (UTC)

I wouldn't be so quick to dismiss the "humble request". Obviously much of cryptography is highly technical, but I think there is room to make basic articles more accessible.--agr 14:15, 10 November 2006 (UTC)

I might have been overly critical since I assumed that a request for "something for the beginners" implied practical cryptography. That is, practical "howto"s or guides, which I can't see fitting into an encyclopedia. As for accessibility, I agree. Every article on Wikipedia has room for improvement, and articles about cryptography in particular tend to be quite technical. -- intgr 14:29, 10 November 2006 (UTC)

Actually guys, I think I disagree. There are several articles, albeit mostly on what we call classical crypto, which are suited to beginners. I know I've been tugging in the direction of accessible by the Average Reader in the crypto corner the entire time I've been here, and though I often seel like Sisyphysis (sp?), there are probably some other folks who have been doing so as well. Try Cryptography, History of Cryptography, Substitution cipher, polyapphabetic cipher, and so on. All that said, I tend to agree with Intgr above about how-tos being not good WP fodder. ww 22:32, 10 November 2006 (UTC)

Simple cryptography

Could someone put the most basic of stubs on the Simple cryptography page and remove the {{inuse}} tag. The tag was not intended to be the only content for a page while someone got around to writing it. Thanks, Ansell 10:13, 15 April 2006 (UTC)

I have no idea what an article on Simple Cryptography would be about.. perhaps Classical cryptography? Anyway, I've put a speedy tag there, there's no content on that page. Theeditor1, the only editor of it, is a new editor who had some difficulty understanding ownership of articles at first, which may explain this. I left him a message. Mangojuice 12:09, 15 April 2006 (UTC)

-- I'm new to this as well and can't find a page on Simple Cryptography. My interest is in historical ciphers, some of which are not too simple.

When Mangojuice suggests a possible general title Classical cryptography, what period should it cover? Antiquity to the 1920s? --Steve 12:36, 2 June 2006 (UTC)

Mangojuice & Stevebkk, Here on WP, the term Classical Cryptography was first used in some major edits by Matt_Crypto to Cryptography. The article had been arranged, conceptually, to sketch the historical development as an aid to understanding the in the Average Reader. MC' motive for excising a good bit of hte history was, as nearly as I understand, that much of that history was now irrelevant. There was some disagreement at the time, but little willingness to reverse the bulk of his changes and so they have more or less remained. His term for pre-1976 crypto, and certainly for pre-Machine Age crypto was meant to make this distinction and to reduce space allocated to such crypto (outside explicitly historical articles), thus concentrating available space on crypto of current interest.

I agree that 'simple cryptography' is inappropriate for some pre-WWII crypto, and would favor removal of the implied categorization. I think the intent, however, was to contrast with modern practise which is, effectively, so un-simple as to require high capacity electronic asistance.

I remain, as one whose intent here is the plight of the average Reader, not entirely tranquil with the state of things, but unwilling to insist on my position without indication of more widely shared disquiet.

Either or both of you may have views on this which suggest that revisiting that structuring might be appropriate.

Does this cover the ground (and figure too) adequately? ww 01:42, 3 June 2006 (UTC)

pre-1976 crypto? I stop in 1918 when the subject was still in the hands of linguists and not mathematicians.

--Steve 10:27, 12 June 2006 (UTC)

Guys, this isn't really relevant anymore. Simple cryptography was deleted as being devoid of content about 2 months ago. Currently we have Cryptography and History of cryptography for this kind of thing, and possibly some other article I'm not as aware of. Mangojuice^talk 18:45, 12 June 2006 (UTC)

All reference material to be deleted from Wikisource

I would like to alert this community to the fact that Wikisource has decided to delete all reference data, some of which is of interest to this project. This raises the question of whether some of this material should be hosted at Wikipedia. See [[1]] for a list. There aren't that many of them and I think they have value here. Articles to be deleted include some Elliptic curve algorithms, test vectors for Blowfish and RC4, and Diceware word lists in English and German. I have a personal interest in the last two (I am the compiler of the English list) so it would be best for me to stay out of that discussion.--agr 15:30, 20 June 2006 (UTC)

AR, I've reviewed the discussion which resulted in the exclusion policy under which these articles are being deleted. Twice. And i find myself lost. If the FIPS Pubs related to crypto are included I can't see the problem. They are public domain, important to public policy (at least in aggregate) and some of them are very important (eg the DES and AES standards). I think the decision to exclude maths got out of hand. I didn't see that policy defended in the discussion, and the summary voted upon (or its interpretation a few commments later) seems to have gone awry. Very odd. Should one protest at WS? Should one just transfer the material (much of which is gone when I looked) to WP? Extremely odd. When I end up in this lost condition, I usually find there's an internally contradictory situation. And I think the same has happened here, the contradction being between a remit to include Sources and some hostility to complex stuff (like math and its typography). ww 08:31, 21 June 2006 (UTC)

I'm not happy with the situation, but the editors who maintain Wikisource have decided to delete reference material that was previously considered part of the Wikisource mission. Their best argument is that they do not feel competent to maintain material that isn't essentially a book. That said, FIPS PUBS would appear fall under what is still allowed, as I understand things. Were there FIPS PUBS on Wikisource before? If so, do you know happen their title?--agr 11:35, 21 June 2006 (UTC)

Yes any transcriptions of a publication (with acceptable license of course) are still allowed. The data listed for exclusion had no such sources listed. I believe it was user compiled. If it was a publication however I would be happy to restore it. There are links to lists of what was deleted in the Scriptorium disscussion. There may be red links to things that were not necessarily deleted, as no one ever cleaned up the index pages on many of these topics after the language split. I am not sure that that situation necessarily applies to cryptograpy though. Any titles you are unsure of I can examine for deleted edits.--Birgitte§β ʈ Talk 11:46, 21 June 2006 (UTC)

Would the http://cryptodox.com/ be an appropriate place for such cryptography-related things that are apparently unwanted elsewhere? --70.189.73.224 15:55, 28 September 2006 (UTC)

Crypto navigation boxes (templates)

I took the liberty to slightly change the layout of our navigation boxes. I moved the "edit button" on them from the top center position to the top right corner instead. I tried the layout on some people and they prefered that. I hope you guys like it too. You can see the boxes on the bottom of our main project page. --David Göthberg 22:32, 31 July 2006 (UTC)

I like it. Cheers! — Matt Crypto 15:58, 1 August 2006 (UTC)

I noticed that Authenticated encryption and all its modes kind of need a navigation box. But I thought it preferably could be added to an existing navigation box. Since it is both about block cipher modes and MAC modes it kind of fits in both the "Block ciphers" box and in the "Cryptographic hash functions and Message authentication codes (MACs)" box. Since the block cipher box already is very big and more is about ciphers than modes and the MAC box is much smaller and do list MAC modes I think Authenticated encryption best fit there. So I will add it there. --David Göthberg 11:36, 8 August 2006 (UTC)

Project internal categories and our userbox

I just discovered that other projects use categories for their project internal pages and for their templates. So I created two new categories and added all our project pages and all our templates to them: Category:WikiProject Cryptography and Category:WikiProject Cryptography templates. (I added all I could find. There are probably more hidden somewhere.) --David Göthberg 02:53, 1 August 2006 (UTC)

I also made it so that users of our project userbox {{User WikiProject Cryptography}} are automatically included in the Category:WikiProject Cryptography members. --David Göthberg 15:39, 6 August 2006 (UTC)

A minor point occurs to me in connection with your innovation. There has been a convention that new participants are added to the list at the end. This loses alphabetic ordering, but it's a small list... Does your clever change follow this convention? ww 22:53, 8 August 2006 (UTC)

Well, the userbox does NOT add people to the participants list on the Wikipedia:WikiProject Cryptography page. Instead it adds them to the Category:WikiProject Cryptography members which is an automatic category page. And category pages automatically sort items in alphabetic order.

I made that extension to the userbox mostly for fun. I noticed that many of our participants were using the userbox so I thought it would be neat to use that to automatically categorise them. (And no, it is not my invention, I have seen other projects doing it.) However I added a twist to the code so that only when the userbox is added to a user page does that page get listed in the category. So if the userbox is placed on other pages (such as on our project page that informs about it) then those pages do not get listed in that category. Our userbox are used on a whole bunch of other pages and that was cluttering the list on the category page.

--David Göthberg 23:40, 8 August 2006 (UTC)

DG, sorry about the confusion. I was understanding something rather different than was actually meant. Oops. ww 15:07, 9 August 2006 (UTC)

On suggestion from Mike Selinker I moved Category:WikiProject Cryptography members to Category:WikiProject Cryptography participants and updated our userbox and other pages accordingly. It seems to be a more consistent naming with other projects and with that we ourself used the title "Participants" on the section of our project page already before I made the category. --David Göthberg 16:38, 15 November 2006 (UTC)

High quality

Just dropping by here to note that I'm impressed by the high quality I almost invariably encounter when stumbling across cryptography-related articles in Wikipedia. Kudos to all contributors. Is there still active work on the cryptography WikiReader? Fredrik Johansson 10:15, 19 August 2006 (UTC)

Slashdot on CryptoDox

http://it.slashdot.org/article.pl?sid=06/09/17/1522236 — Matt Crypto 07:39, 18 September 2006 (UTC)

Thoughts on possible additions

I do not feel competent enough to add much to the crypto pages, although if basic stubs are fine, then I guess I'm as competent as any to do that. Anyways, these are the things I've noticed when browsing around:

1) The crypto modes page lacks many of the modes listed on the [NIST] website for modes under evaluation. There are a LOT, and they're divided into multiple categories, which would imply the crypto mode page would need to reflect those categories somehow, if some/all of these were to be added.

2) [eCrypt] seems to list some cryptographic functions not mentioned elsewhere.

3) The Hashing Function lounge certainly lists a whole host of hashes that range from the normal to the obscure (hashing with fast fourier transforms?) to the totally bizare (and what do you do with the cellular automata?). At the very least, the hashing pages here should have a section on the role of mad scientists in hashing.

4) The alternative asymmetric cipher page seemed to miss a few options. [HFE], [TTM], [GPT]. Some of these are broken, but establish a clearer picture of what people have tried and why certain approaches just don't seem to work.

5) Although I saw some stuff on IPSec, I didn't see a mention of Sun's SK/IP protocol, which (as best as I can recall) was intended to be better than IPSec on recovery over unreliable connections.

6) There were a few other ciphers which seemed to be missing. For example, although SEAL was listed, I did not see an entry for FEAL on the block cipher page. (Although it does have its own page.) I didn't see Rainbow listed at all, though I may have just missed it. (Addendum: Ok, this point is probably not valid, as noted by Matt Crypto. However, I will now obsess over the next week or so on finding general categories of block ciphers not covered.)

7) References! More references and external sites need to be given on those pages with limited content. [Hyperelliptic Curve Cryptography] is one for, well, the hyperelliptic curve cryptography page. It links to many more. Personally, I'd cite the lot rather than cite just one and let others dig through. There's only one interesting new paper on [Torus-based encryption], but it looks like a good study of the original case and lists some practical improvements to the method. There is also a [study comparing CEILIDH and XTR] (two torus-based asymmetrical crypto systems) which would be worth adding as a reference.

8) There is no 8. That way, I can index my suggestions in a single digit of octal.

--70.103.67.194 19:09, 18 September 2006

Thanks for the feedback. To address point 6, few specific designs are mentioned on block cipher (although a lot are indexed in the navigation block at the bottom -- including FEAL). That's probably OK, as we're only really interested in generalities at that sort of level. — Matt Crypto 20:29, 18 September 2006 (UTC)

Hi, who ever you are. You really should consider to log in and sign your comments. Any way, I think I happened to address point 1 when I added a section I called "Other modes and other cryptographic primitives" to the Block cipher modes of operation article. I had been thinking of adding that for some time now and actually did not read your comments until after I did that addition. :)

--David Göthberg 00:19, 20 September 2006 (UTC)

8) (or 10 if we're sticking to an octal index) Should the Heilbronn Institute for Mathematical Research get some mention? The links with GCHQ and the type of math they talk about makes me think it should. Also, the Elmer_Rees page has a dead link to a WP Heilbronn Page. The lack of information in the public domain about Heilbronn would make any article tricky to write. DanBeale 12:12, 4 February 2007 (UTC)

Cryptography Portal box

{{Cryptography portal}} I have noticed that lately Frap has been adding a "Cryptography portal" box to a lot of crypto articles. See for instance the "See also" section of the RSA article.

However he used the generic "portal template" for that box and I did not like the image size and layout it caused. So I made a dedicated template for the box instead. Thus we can discuss and change the design in that template and it will then look the same on all pages where it is used.

The box you see to the top right of this message is the new dedicated one. Here is a link to it if you want to look at its code or edit it: {{Cryptography portal}}

Another issue is in what articles to place the box? Frap seems to put it in all kinds of crypto articles. Perhaps it should be in all articles, or perhaps just in the "main" articles?

Yet another issue is where in the articles to place the box. The normal place for portal boxes is in the "See also" section just like in the RSA article. However some articles do not have any "See also" section and Frap then placed the box in the top of the article. See for instance the RC4 article. Perhaps the box should then better be placed in an empty "See also" section?

So the three questions I have are:

• How should the box look?
• In what articles should it be used?
• And where in the articles should we put it?

--David Göthberg 17:09, 19 September 2006 (UTC)

Yes, I noticed that the image isn't aligned so good. I saw the portal link in some article, and decided to put it in other articles related to cryptography. I tried put it on pretty much every article so that people easier can find the portal. I placed it under the "See also" section for articles that had such a section, as that is the place that I deemed made the most sense. Not all articles had an "See also" section, so I put it elsewhere, mostly at the top. -- Frap 18:08, 19 September 2006 (UTC)

Hi again Frap! I have done some thinking and experimenting and I think I now have at least come to a conclusion what I myself want to answer to my own three questions:

• I am now happy with the design of the portal box. I hope the rest of you like it too. (But feel free to edit it more if you want, this is a wiki...)
• I think we can put the portal box in pretty much any/all crypto articles if we like too. Although I think that portal first perhaps should be expanded with more stuff. I myself am not a fan of portals and think that the cryptography page is a better starting point than the portal for a new user. So personally I think it is more important to link to that main article somewhere in each crypto article. For instance by using this as the first sentence on crypto pages: "In cryptography, salt is/means ...". (But note, I have nothing against portals, I just don't use them myself.)
• I think that normally the portal box should be placed in the top of the "See also" section of articles. But when there is no such section I do NOT think it should be put in the top of the article, instead in the "External links" section. And in worst case in whater is the last section such as the "References" section. If there is no last section (other than normal article text sections) an empty "See also" section could be added like this:

    == See also ==
    {{Cryptography portal}}
    <!-- Add "see also" items here. -->
    <br clear=all>

That "<br clear=all>" tag makes it so that any other things that comes below it (such as "Crypto stub" or navigation boxes etc) doesn't end up in weird places. It also makes it possible to add an empty "See also" section before other sections if you like, without the box interacting weirdly with the next section header.

Sorry for being pedantic about this portal box but since it is going to be added to a lot of articles I think it is worth some discussion.

--David Göthberg 16:18, 21 September 2006 (UTC)

A note to every one. I now think we have a better solution than using this "portal box". I think we instead should use the "generic crypto navigation box" which is discussed and shown in the next section below. --David Göthberg 01:55, 24 September 2006 (UTC)

Generic crypto navigation box

Note, the boxes below now have been changed to the real deployed ones, they are not from my test pages any more. --David Göthberg 13:26, 25 September 2006 (UTC)

I came up with an idea. Most of our crypto articles do not have a navigation box. For new readers it might be hard to find the main crypto pages where they can read about the basics. The category system partially solves this, and so does the crypto portal and its crypto portal box. However, how about having a generic crypto navigation box at the bottom of all crypto articles that do not have a specialised navigation box? And use it instead of the crypto portal box on those pages. Here is a draft of what I am thinking of:

What do you guys think? --David Göthberg 17:19, 21 September 2006 (UTC)

The box itself looks OK to me, but how do you plan to deal with articles that are linked from your box, but already have their own boxes (e.g., block cipher)? I'd think that users expect to see the same box on all referenced articles, but two boxes on top of each other would look silly as well. -- intgr 18:04, 21 September 2006 (UTC)

Hi intgr. Well, I think articles that has a specialised navigation box should then not have this generic box. They can instead have the small crypto portal box and then perhaps the portal can have the generic box at the bottom. Or we could perhaps add the items from the generic box into a special section in the specialised boxes, perhaps below a horisontal line in those specialised boxes. This probably needs some thinking and testing. I added some tests of that in the comments section of my testpage but I didn't like the result. Oh and by the way, feel free to edit the generic box even though it currently resides on a test page below my userpage. --David Göthberg 18:45, 21 September 2006 (UTC)

Yeah, I like the idea of having a generic section in the specialized boxes. The second example on User:Davidgothberg/Test5 looks pretty good to me. I suppose we'll need two templates then, though? One with the frame of the new cryptography box, and another that will get included in the frame, as well as specialized boxes. -- intgr 12:33, 22 September 2006 (UTC)

Yeah, it seems we will have to resort to double transclusion. I have already done some tests so I think I know exactly how to code it. I'll do a little more work on those combined boxes to see how nice I can make them look. Although that will be in some days from now since I am going out all this weekend. --David Göthberg 12:49, 22 September 2006 (UTC)

Hi again intgr. I finished the coding and you gonna like this: The stream cipher navigation box right over here uses some magic. It transcludes in the generic crypto box into its lower half but tells the generic box to loose its borders and edit button, so it doesn't look like a box in a box. So I did not have to use an extra template. And all parts of it even stretches out correctly in all screen resolutions. Neat isn't it?

So what do the rest of you think of the layout etc?

--David Göthberg 17:36, 22 September 2006 (UTC)

That's great! I can see some slight but noticeable margins on the "inner box", though (the at the right and left of the heading in particular) - perhaps it's possible to get rid of those as well? -- intgr 19:45, 22 September 2006 (UTC)

Ah, glad you like it. And yeah, the lower blue bar is 1-2 pixel shorter on each side than the upper bar. I didn't think you guys would notice it, darn. But I think I know how I can fix it, but it will cause yet another table inside the box which will make the code more messy. But I will try it. By the way, the extra space above the lower bar I have put there on purpose, otherwise it kind of disturbed the text above it. --David Göthberg 20:42, 22 September 2006 (UTC)

Ok, tested fixing that margin. Looked great in Firefox but made it look very ugly in my Internet Explorer. So the old version seems best with the slight extra margin. --David Göthberg 21:28, 22 September 2006 (UTC)

Don't bother then, I guess. :) I also noticed that the centered titles aren't aligned to each other since the upper one has an 'edit' link in the right, but if it can't be fixed cleanly, I don't think you should resort to hacks. I think the boxes are ready for use. -- intgr 23:34, 22 September 2006 (UTC)

Well, there are several reasons I removed the edit link from the lower box. (And I understand that you did not suggest to put it back). It looked better without, it is confusing if the two edit buttons go to different pages, that generic box won't be edited that often any way, it will have the edit button on all pages where it is alone any way and I intend to have a link to it in the explanation below the other boxes on their template pages. So it will be easy enough for editors to reach it. But it is easy to fix the symmetry if people notice it too much. We can add some extra "& nbsp ;" blanks to the left of the titles. But I prefer to keep the code in the boxes as simple as possible to not confuse later editors of them.

Thanks for thinking the boxes are ready for use. However, yesterday I went crazy and tried something even more advanced! As you might know there are a handful of pages that have use of two or more of the boxes. Say both the block cipher and stream cipher box. So I have come up with an even more advanced design: Instead I start with the generic crypto box, and then instead insert one or more of the other boxes above it. But still within the same frame since we always want the generic box too. So say you want to combine the block and stream box, then you could use this "command": {{Crypto navbox|block|stream}} Which results in a combined box with the stream box on top, then the block box and then the generic crypto box at the bottom. The "|block|stream" part are parameters to the generic navbox and tells it to insert the other two boxes in its top. I already tried it and it works. I just need to tinker a bit more with it before it is ready for use. I think this will be a more flexible aproach that will make all our crypto editors happy.

--David Göthberg 12:25, 23 September 2006 (UTC)

Above is an example of the new "main crypto navigation box" with two other "specialised navigation boxes" inserted above it. When this is deployed the example above should be the result of this code:

{{crypto navbox | stream | block}}

Go read Template:Crypto navbox and Template:Crypto stream for a description of how I plan these boxes should be used. Notice that the code on those pages are not exactly the "production code" since that code is adapted to run from my testpages.

For technichal reasons and for easy deployment I intend to use this naming for our new boxes:

Template:Crypto navbox

Template:Crypto block

Template:Crypto stream

Template:Crypto public-key

Template:Crypto hash

Template:Crypto machines

Template:Crypto classical

I am now ready to deploy these new boxes. And I know how to deploy them smothly and easily. All I need is the go ahead from some of you crypto editors and I will do it. --David Göthberg 00:39, 24 September 2006 (UTC)

Looks neat! Thanks for the hard work. You have my approval. :) And it seems that you managed to fix the extra margins around the title of the generic box after all. -- intgr 01:22, 24 September 2006 (UTC)

I couldn't wait any more. I have gone boldly ahead and deployed this. You can see the result on any of our articles that use our old navigational templates. Or at the Wikipedia:WikiProject Cryptography. (The page that this page is the talk page of.) Hope you guys like it. Now what is left to do is to clean up the about 300 articles that use the old templates, so they use the new templates directly instead of double transclusion through the old templates. And adding the main template to all the other 800 cryptography articles... --David Göthberg 19:03, 24 September 2006 (UTC)

Guess I am crazy, but I have just updated about 300 pages. And fixed a lot of other small things along the way. --David Göthberg 12:02, 25 September 2006 (UTC)

Navigational template usage

Hi everyone! As you might have seen I have made some rework of our navigational templates. I'd like to have some feedback/comments/views on how they should be used. Everything I am talking about here is visible in the Wikipedia:WikiProject Cryptography#Navigational_templates. Here are my suggestions and questions:

1: We now have a "main crypto navigation box" below all the other navigation boxes with links to the main/basic pages. I hope every one like that?

2: We of course need to ponder exactly what that main box should contain. So far it just contains my suggestions. But I suggest we keep it fairly short and don't fill it with many links.

3: I suggest we use that "main crypto navigation box" on ALL crypto pages.

4: Regarding the small "Cryptography portal" box (the one with the yellow key in): I should mention that I don't use portals anywhere so I have no feel for portal stuff. So I have no idea how and how much we should "advertise" the portal. We now have a link to the portal from the main box so all pages with a crypto navigation box do link to the portal. However I have realised that link is not especially visible. So perhaps we should use that portal box in many or even all "See also" sections on all crypto pages? It seems to be inline with what Frap has been doing lately. But my only point of view is that we should NOT add it to the top of articles, instead only to the "See also" section and if there is no such section to one of the other lower sections or in lack of that even skip the box on that page.

Well, that was all. Sorry for filling up this page faster than it seems you people have time to answer. --David Göthberg 13:05, 25 September 2006 (UTC)

Nice work with the templates, keep up the good stuff. Although (1) I like it, (3) I don't know if we should use a navigation box on all pages. It wouldn't hurt. Maybe just those that would fall within a "topic" (like "stream" or "hash" etc), which, of course, is still a large proportion. (4) I think we should avoid promoting the crypto portal heavily. I agree that it shouldn't be on the top of crypto articles. Personally, I feel we shouldn't use it in many articles at all (exceptions being Cryptography, and maybe a couple of others). — Matt Crypto 17:51, 29 September 2006 (UTC)

Project directory

Hello. The WikiProject Council has recently updated the Wikipedia:WikiProject Council/Directory. This new directory includes a variety of categories and subcategories which will, with luck, potentially draw new members to the projects who are interested in those specific subjects. Please review the directory and make any changes to the entries for your project that you see fit. There is also a directory of portals, at User:B2T2/Portal, listing all the existing portals. Feel free to add any of them to the portals or comments section of your entries in the directory. The three columns regarding assessment, peer review, and collaboration are included in the directory for both the use of the projects themselves and for that of others. Having such departments will allow a project to more quickly and easily identify its most important articles and its articles in greatest need of improvement. If you have not already done so, please consider whether your project would benefit from having departments which deal in these matters. It is my hope that all the changes to the directory can be finished by the first of next month. Please feel free to make any changes you see fit to the entries for your project before then. If you should have any questions regarding this matter, please do not hesitate to contact me. Thank you. B2T2 00:02, 26 October 2006 (UTC)

Disk encryption reorganization

The articles about disk encryption really need to be reorganized. Right now there is a considerable amount of redundancy in their content. The list of articles follows:

• Disk encryption (Takes a mathematical/scientific approach, not very friendly)
• Full disk encryption
• OTFE
• Filesystem-level encryption
• Encrypted filesystem (currently disambiguates between 'disk encryption' and 'filesystem-level encryption')
• Disk encryption software
• List of encrypting filesystems
• Disk encryption hardware
• Deniable encryption (discusses the container-based approach as well as layered file system approach to plausible deniability)
• Steganographic file system

In my view, there should be three main articles: one would explain the difference between 'full disk encryption' and 'filesystem-level encryption', and introduce the common concepts. The other two articles would explain each of the two in detail (since the approaches share very little conceptually).

Cryptographically, there is a great difference between (1) decrypting file, using it, and encryption back; and (2) transparent encryption of a writable block device. In the former case one uses CBC or CTR mode, in the latter LRW or XEX. AFAIK, there is no such difference between filesystem-level encryption and block-device encryption: if one wants to be able to update file in place, he must use the same techniques. There is a difference in user experience between pre-boot encryption of disk, encryption of a non-system partition, storing encrypted volume in a file system, and encryption of separate files. But this difference is not cryptographically significant—each of these methods should use the same underlaying techniques. GBL 11:16, 3 December 2006 (UTC)

Thanks for your response. I agree that there isn't a big difference from the cryptography perspective, but there is a significant difference in layering, the functionality that can be provided and the complexity of implementations (see filesystem-level encryption if you want some examples). I can't see why you're only emphasizing differences from the cryptographic perspective; Wikipedia is supposed to be a general-purpose encyclopedia. That said, I think there is a bigger difference between filesystem-level and raw block device encryption, than there is between different raw block device approaches (whether they encrypt the whole disk, individual partitions or are backed by a file on a file system, or whether it is initialized before the operating system, as thes are a difference in the features and not the concept). Also, the filesystem-level encryption article is currently forced to link to "disk encryption" – while it doesn't in fact, encrypt the disk, but individual files on it, so I think the "disk encryption" article is currently misnamed if it is supposed to apply to both (although I cannot come up with another title at this point). -- intgr 14:40, 3 December 2006 (UTC)

I guess there are two broad categories of people who come to Wikipedia to read about disk encryption: the first category want to know what software they need to download to encrypt their data, the second category want to know what cryptography is under the hood of disk encryption. Clearly, to make all of them happy we should provide good disambiguation. I don't think it is very important what are the exact names of articles, as far as after reading the first paragraph the readers know what page they want to visit. Originally I thought that it is not too bad to have disk encryption theory under disk encryption, but we can also rename "disk encryption" to "disk encryption theory" and make "disk encryption" a purely disambiguation page with links to "place of encryption layer", "disk encryption software", "disk encryption hardware", and "disk encryption theory." GBL 11:16, 5 December 2006 (UTC)

Also, what to do with the current disk encryption article? I don't think it would make a good generic article in its current shape. The different modes of operation would probably go into their own article? Or merge with block cipher modes of operation? Ideas? See also: Talk:Full disk encryption#Merge with OTFE -- intgr 22:56, 2 November 2006 (UTC)

Disk encryption describes techniques used to encrypt and decrypt data on a block device. IMO, after the recent clean up it is quite good in describing this. It is possible to move LRW, XEX, CMC, and EME to separate short articles, but these modes used only for encryption of a block device, so IMO it is better to leave them together. Btw, I don't think that maths in cryptography articles should be considered "not friendly" :-) GBL 11:16, 3 December 2006 (UTC)

I was thinking of moving all the modes to a single article, like has been done with block cipher modes of operation (I agree that they do need a separate article from block ciphers). I think it's not friendly in the sense that people who are looking for information on practical disk/filesystem encryption are likely to encounter that article – as it has a pretty generic-sounding title – and probably end up scratching their heads. Instead, I think, such a generic article (although not necessarily with the same title) should introduce different approaches to encrypting things on a disk (and of course also link to the article discussing different modes of operation). -- intgr 14:40, 3 December 2006 (UTC)

I doubt that they will scratch their heads if they read the first paragraph that contains links to relevant topics. Probably, making disk encryption a purely disambiguation page is a good idea. GBL 11:16, 5 December 2006 (UTC)

Thanks for the response, GBL. Seems that we agreed on everything now. ;) Just to get a clear overview, here's what I understand we agree on:

• The distinction between filesystem-level encryption and block device encryption has to be made (in articles describing the subject as well as the "list of" articles).
• Generic-sounding articles that could refer to either, such as disk encryption and encrypted filesystem, should be disambiguation pages.
• There should be a third article discussing the differences and similarities between the two approaches.
• Current disk encryption article should not be merged with either of the above, but just be moved to a more appropriate title.
• No big distinction should be made between OTFE and full disk encryption; the two would be merged into an article on general "block device encryption".

Any further comments? I would like to get the opinions of anyone familiar with the topic. -- intgr 19:34, 11 December 2006 (UTC)

---

What hasn't been discussed yet:

• Is "block device encryption" too obscure to use it as the title of an article? What are the alternatives?
• What to do with what's in the relevant parts of deniable encryption article? It currently documents two techniques of plausible deniability that can be (and often are) used in encryption solutions (the "container-based" approach in block device encryption and "layered" approach in filesystem-level encryption). Are they fine as they are currently? Would the two techniques be moved or copied to the relevant articles discussing the approach it applies to? Or to the one contrasting the two approaches? -- intgr 19:34, 11 December 2006 (UTC)

---

I moved disk encryption to disk encryption theory and fixed some links (you are right, “block device encryption” is too obscure; by the way, I guess block device encryption, if created, should redirect to encryption layer in storage stack). Disk encryption is now a disambiguation page that links to theory, software/hardware, and encryption layer in storage stack (any idea about a better name before we create it?). Instead of creating this page we can move full disk encryption to it (FDE already has some content about distinction between encryption on different layers) and then merge in all related stubs (OTFE and filesystem-level encryption). GBL 13:47, 12 December 2006 (UTC)

What I mean under "block device encryption" is what's currently covered by the full disk encryption and OTFE articles – a layer that transparently encrypts any block-addressable device (either physical or loopback), providing another virtual block device that can be used as a base for normal file systems. So I don't think it should redirect to "encryption layer in storage stack". Perhaps "mass storage encryption" is a better name (inspired by USB "mass storage device" that exports a raw block device instead of a USB file system)? This is what I would like to contrast to filesystem-level encryption.

As for the "encryption layer in storage stack" article, perhaps it can take the place of disk encryption? As you created it, it currently already disambiguates between the two concepts, and links to disk encryption theory that generally applies to both. -- intgr 14:35, 12 December 2006 (UTC)

I guess we use the same words to denote different things. What I denote encryption layer in storage stack is an article that explains that: There is a stack of storage (logical block addressing or cylinder-head-sector (CHS) abstraction in the bottom, partitions as the next layer, filesystem as the top layer). The encryption layer can be inserted between any pair of layer, on the top, or in the bottom. Depending on the placement we get FDE, partition encryption, or filesystem encryption (in addition loopback can be used to start a new stack using a file). And after this introduction we merge all the related stubs and add (if not already present) comparison between different placements. I don't think it's a good idea to leave a separate article for each such placement—there are too much common background and comparisons. GBL 08:38, 13 December 2006 (UTC)

I was thinking of somewhat the same thing, just without the distinction between full disk and partition-level encryption – as I figured that both of these as well as the differences could be covered by the article that talks about these in general (what I've been referring to as "block device encryption" and later "mass storage encryption").

I still think that filesystem-level encryption, as done by the file system implementation, is fundamentally different, since it is (can be) deeply intertwined with how the file system operates, and is not just an layer of encryption by itself, but rather a class of file systems.

What do you think? -- 10:37, 13 December 2006 (UTC)

I am not sure that it is important to come to any conclusion about "whether filesystem encryption is fundamentally different than block device encryption?" (well, to answer such a question we need to define "fundamentally" first :-) ). Whatever we think about it, it does not change the fact that we have more to say about their pros and cons related to each other than about them themselves. This is the main reason why I think it is a good idea to put them all in the same article. The distinction between full disk and partition-level encryption is also not that important: we should say that there are such things, but it does not mean we should create a separate article for them. GBL 07:37, 14 December 2006 (UTC)

Damn misunderstandings again. :) My idea was that the difference between "filesystem-level encryption" and "block device encryption" would be explained on the current "disk encryption" disambiguation article (instead of your proposed "encryption layer in storage stack"), while the difference between full disk encryption and partition encryption would be explained on the "block device encryption" article. This would seem the most logical to me, as the latter are variations of raw block device encryption. I hope I made more sense this time. :) -- intgr 10:44, 14 December 2006 (UTC)

---

The new status: I made encryption layer in storage stack and have merged into it full disk encryption, OTFE, and filesystem-level encryption. I wrote about storage stack and terms, and copy/pasted the content of the merged pages (this have to be cleaned up, of course). I also moved implementation (something about TPM) from FDE to disk encryption hardware talk page -- this have to be checked (probably it is more relevant to software) and merged in. GBL 16:54, 14 December 2006 (UTC)

See your talk page please. -- intgr 17:06, 14 December 2006 (UTC)

It has been over 24 hours since you made the changes, and as you have not yet responded to my inquiry, I have reverted your changes for now, and marked the "encryption layer in storage stack" article as uncertain. I do not understand why you decided to ignore my opinion, or why you are rushing these changes. I really hope it was done due to misunderstandings. Perhaps I was not as clear on my positions as I could have been, but I did repeat them several times, and I cannot understand how they could have been misinterpreted. -- intgr 20:37, 15 December 2006 (UTC)

This is very strange: your post "Damn misunderstandings again. :) My idea was ..." seems to imply that you had some idea in the past, but now you agree that the merge is reasonable. If you object to some proposal, please, state this explicitly.

My reason to merge full disk encryption and filesystem-level encryption is that they share a lot of background and a large part of each page should be the comparison of the notions—apparently this is in line with Wikipedia:Merging_and_moving_pages#Merging. What exactly do you disagree here? GBL 20:58, 15 December 2006 (UTC)

I did state that I had the idea in the past, but to my knowledge, I did not indicate any changes of opinion. The "This would seem the most logical to me [...]" part of the given post also implies a present state.

While the filesystem-level encryption article indeed does not currently say anything more than comparisons to disk encryption, I was planning to turn it into a full article. But before doing that, I decided that a reorganization was necessary in order to avoid wasted effort. There was also no suitable article on which to point out the differences of the two approaches. (And I was forced to compare it to full disk encryption only due to the lack of a more suitable article to link to)

I was repeatedly and specifically stressing that in my opinion, there would be three articles:

• One discussing what I referred to as "block device encryption"
• Another discussing filesystem-level encryption
• A third article pointing out the similarities and differences.

And I was proposing that the third article would be placed instead of the current "disk encryption" article. I also figured that it would take more than two people to reach a "consensus", or the lack of participants (silent agreement) for a week or so.

Instead, you merged all articles into one, and picked a name that I had not agreed with. -- intgr 21:16, 15 December 2006 (UTC)

I hope now I understand your POV. I was not aware that it was you who have created FLE and still have plans to expand it (similarly, my apologies to Saqib from Seagate for his FDE).

Actually, I have no objections to your plan, except making disk encryption a non-purely-disambiguation page, that is I think that none of the topics listed on it now, is much more important than others (I guess this is a reasonable criterion for turning a disambiguation page into a normal one).

To apply the agreed part, the FLE/FDE comparison article (encryption layer in storage stack, please, do not just object to the name—I like it no more than you—propose something!) can be simply stripped from the FLE and FDE copies, and FLE and FDE can be stripped from the comparisons. Right?

Frankly, I very much doubt that there is much to say about FLE and FDE except their comparison, but probably you know better GBL 22:03, 15 December 2006 (UTC)

My reasoning for using the current disk encryption article for comparing the two approaches is that:

• The current disambiguation page exclusively deals with these two topics. Disk encryption theory talks about the theory that these two approaches employ. Disk encryption hardware exclusively talks about hardware that supports block device encryption (or more specifically, FDE). Disk encryption software lists software packages that do either (although the introduction currently only touches block device encryption; I've had thoughts about splitting this article too). Encrypting file systems is also a disambiguation article for the two topics. Finally, encryption layer in storage stack would compare the two approaches in your plans.
• As the article has the most generic name for both, I think it would be reasonable for it to introduce common concepts as well as the differences – be a kind of "starting point" for both.
• Disambiguation pages typically disambiguate between articles with similar titles, but talk about different things. Similar, but distinct concepts are sometimes discussed in generic-named articles using the {{main}} template.

What do you think? -- intgr 23:42, 15 December 2006 (UTC)

I guess this reasoning has a flaw: Let us consider some abstract phenomenon, say apples, and this phenomenon has several aspects, say A (e.g., color), and B (e.g., size). None of this aspects is more important than the other: one cares that an apple is red and not that much cares about the size, while another person wants a big apple and does not care if it is green. Every apple has both properties (one from A and one from B), that is always if we talk about the phenomenon we can say that we are talking about one of the aspects, say color, but it does not mean that color is more important than size, because, symmetrically, when we are talking about apples we should consider their color and thus color is more important.

Getting back to our disk encryption, you say that FDE/FLE distinction is more important because disk encryption theory talks about theory that is used by FDE/FLE; but using exactly the same reasoning one can say that the definition of the disk encryption problem and the used modes are more important, because any implementation (FDE, FLE, software, or hardware) implements one of the modes to solve the defined problem. In fact, this was exactly the reasoning I had used when I had created what is now disk encryption theory under a general name "disk encryption." Unfortunately, there is no way to get to a consensus which aspect is more important, and each of them is too large to combine them on the same page.

IMO, as far as disk encryption only lists different aspects of the problem that reader can chose from, it is irrelevant which template to use. GBL 22:16, 17 December 2006 (UTC)

Sorry for taking so long to respond; I can see your point that disk encryption theory and applications are of equal importance, consider me convinced. (and see below for what's next) -- intgr 13:57, 19 December 2006 (UTC)

As for FLE, I do think there's a lot to talk about it. While block device encryption is quite "straightforward" in the sense that it is essentially a single layer that encrypts and decrypts raw blocks, FLE is more complex as it implements the structure of a file system. FLE can also do file-based key management, "stacked layers" with different keys and hidden layers for deniable encryption (arguably better than the container-based approach), visibility/file system permissions based on cryptographic primitives, implicit signing of files/changes, and it has to worry about not giving away too much information with the disk layout. But it could, in theory, also escape the limitation of file systems on top of encrypted block devices, that leak information through file system modification patterns (if the attacker has snapshots taken at different points in time). -- intgr 23:41, 15 December 2006 (UTC)

There is no argument on this topic: if you say that you are going to add content—go ahead and add it. It will be too hard to prove that you will fail with this, thus I am not even going to try to prove it—future will show anyway. (My guess was based on an observation that after three months and almost 20 edits FLE is just a stub.)

IMO, spending time on endless discussion is not the best way to improve Wikipedia. If we do not have a consensus on some topic, let us just skip the topic—probably in the future it will be more obvious to everyone—and do what we already agreed to do. GBL 22:16, 17 December 2006 (UTC)

Well, I can't guarantee that I'll be working much on it, but it's on my list. My edits are rather unpredictable even to myself. -- intgr 13:57, 19 December 2006 (UTC)

---

Now, what do we do with full disk encryption/OTFE? The term "full disk encryption" does not apply to all cases of block device encryption, so I guess first OTFE would be merged to "full disk encryption", and then moved to a more general title when we have a good enough one? "OTFE" itself should probably redirect to disk encryption, as all these approaches happen transparently and on the fly. If you agree, I can do this myself, otherwise you'll be doing all the hard work. ;)
I've previously used the phrases "block device encryption" (which is pretty obscure for non-Unix people) and "mass storage encryption" (which might imply something related to USB). A more generic name would be "storage encryption" or "encrypted storage" (or do they imply that the encryption happens in hardware?). "Encrypted volume"; "volume encryption" ([2]). I don't really like any of these. Do you have any ideas? -- intgr 13:57, 19 December 2006 (UTC)