Wikipedia talk:WikiProject Cryptography/Archive 2

From Wikipedia, the free encyclopedia

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Contents 1 Hash functions based on block ciphers 2 Hash template and MACs 3 Template:User WikiProject Cryptography 4 Crypto stub template 5 Smoke without fire 6 Certification of voting machines 7 PRF / Pseudorandom function 8 Merkle-Damgård article? 9 Template:Public-key cryptography 10 Disambiguation naming 11 Cipher vs cypher 12 Deletion discussion alert 13 MIX nets 14 Smithy code

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:

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

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)

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)