Wikipedia talk:WikiProject Cryptography/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Notice of FAR

Voynich manuscript has been nominated for a featured article review. Articles are typically reviewed for two weeks. Please leave your comments and help us to return the article to featured quality. If concerns are not addressed during the review period, articles are moved onto the Featured Article Removal Candidates list for a further period, where editors may declare "Keep" or "Remove" the article from featured status. The instructions for the review process are here. Reviewers' concerns are here. Cheers. Zidel333 (talk) 18:29, 12 February 2008 (UTC)

Clifford_Cocks

Clifford Cocks got an honorary Doctor of Science from Bristol University recently. I added information to the talk page but no-one has added it yet. He was also added a CB this year, and that has just about managed to find its way into the article. I'm unwilling to edit the article for COI reasons. Perhaps someone here would like to have a look? Dan Beale-Cocks 11:32, 6 March 2008 (UTC)

I've added them, with the references you provided. Hut 8.5 15:48, 7 March 2008 (UTC)

Trusted timestamping

Professionally I work with Trusted_timestamping and see a lot of room for improvement in that wiki page:

• Except for mentioning the Hooke anagram, the rest of the page assumes trusted timestamping = PKI signatures. This is wildly inaccurate, for example Wouters 2002, Towards an XML format for time-stamps provides a great taxonomy to look at.
• Besides RFC3161 there is also work being done by LTANS, can anyone summarize this and connect it to the topics of Discovery_(law) and Sarbanes-Oxley_Act?
• Is it possible to provide at least some sort of inventory of market players except IETF and PKIX? Such as for example IAC and it's members.

Since the company I work for provides a RFC3161-compliant massively scalable binary linking scheme to provide portable and independently verifiable timestamps... you could argue a COI and that I shouldn't be the one to improve the article :-). CarlJohanSveningsson (talk) 12:48, 7 March 2008 (UTC)

Oh yeah, and besides RFC3161 there are

• ISO/IEC 18014-1: "Information technology - Security techniques - Time-stamping services - Part1: Framework"
• ISO/IEC 18014-2: "Information technology - Security techniques - Time-stamping services - Part2: Mechanisms producing independent tokens"
• ISO/IEC 18014-3: "Information technology - Security techniques - Time-stamping services - Part3: Mechanisms producing linked tokens"

And besides linking-based time-stamping there is also "distributed time-stamping", based on completely different principles... —Preceding unsigned comment added by 88.196.208.18 (talk) 14:18, 30 July 2009 (UTC)

Featured Article Review of Caesar cipher

Caesar cipher has been nominated for a featured article review. Articles are typically reviewed for two weeks. Please leave your comments and help us to return the article to featured quality. If concerns are not addressed during the review period, articles are moved onto the Featured Article Removal Candidates list for a further period, where editors may declare "Keep" or "Remove" the article from featured status. The instructions for the review process are here. Reviewers' concerns are here. Thanks, Cumulus Clouds (talk) 17:14, 11 June 2008 (UTC)

It was kept. Hut 8.5 19:53, 19 July 2008 (UTC)

New SHA released

Hello, Crypto people. (Kryptonites?) I know very little about crypto in general, but I did create my own version of SHA for this "commitment to user identity" thing. If you visit that portion of my userpage, you'll find a link to the algorithm. Hope it's of interest. Feedback would be most welcome. Oh, and my tiny bits of math class were more years ago than I care to admit, so surely the notations are incorrect. Unimaginative Username (talk) 06:55, 12 June 2008 (UTC)

This is frivolous nonsense.--agr (talk) 14:19, 4 August 2008 (UTC)

Yes. Also known as "humor". I took a chance in posting it -- just sort of a "roll of the dice" (pun intended) -- in my own userspace, and am sorry that no one here enjoyed it. I won't let that fact suggest support for any sort of stereotype. Keep up the good work on Crypto, and sorry to have been a distraction. Best regards, Unimaginative Username (talk) 03:06, 5 August 2008 (UTC)

A discussion

An important discussion on " Should WikiProjects get prior approval of other WikiProjects (Descendant or Related or any ) to tag articles that overlaps their scope ? " is open here . We welcome you to participate and give your valuable opinions. -- TinuCherian ^{(Wanna Talk?)} - , member of WikiProject Council. 14:51, 8 July 2008 (UTC)

Asymmetric Key Cipher

I'm looking for 2 asymmetric key ciphers: 1. Does not involve variable exponents nor large one preferably exponents of 2 and does not involve prime numbers.
2. Does not involve variable exponents nor large one preferably exponents of 2 and does involve prime numbers.
Melab-1 (talk) 01:31, 19 July 2008 (UTC)

What's wrong with this php

I have my php installed on this computer. The html and php are in the same folder. Here is the php page:

<?php
    $n=$_POST['n'];
    print "Your prime number is $n.";
    ?>

And here is the HTML page:

<html>
<head>
<title>Prime Number</title>
</head>
<body>
<form method="post" action="prime.php">
<input type="text" name="n" id="n"/>
<input type="submit" value="Submit" />
</form>
</body>
</html>

Whats wrong with it my PHP Designer said Undefined index n in C:\Users\Public\Public Documents\prime.php on line 2

Melab-1 (talk) 01:31, 19 July 2008 (UTC)

This doesn't belong here. You'll want to take it to Wikipedia:Reference desk. Ntsimp (talk) 13:47, 19 July 2008 (UTC)

Password strength meter

I created a password strength meter to be used on the account creation page. Discussion is centralized at Common.js. I think it would be best to have some people from the cryptographic community look over it. — Dispenser 07:05, 27 July 2008 (UTC)

Rename SHA hash function

Based on a discussion on its talk page, I am proposing to rename SHA hash functions to Secure Hash Algorithm family per WP:NAME. As this is a widely linked article, I'd like to get wider discussion. Please respond on Talk:SHA hash functions.--agr (talk) 14:24, 4 August 2008 (UTC)

Question

I know, I'm supposed to go the the reference desk for questions but I won't get such a good answer there if any, so please forgive me for this but...
Is there any way of decrypting files with a signature algorithm of sha1RSA? I won't go into details but an encrypted file's certificate became deleted from on my Windows XP. -- penubag  (talk) 06:24, 25 September 2008 (UTC)

I'm a little unclear on what you are asking. If you are asking whether a file can be determined efficiently using only a signature, then the answer is likely not. You cannot do much better than enumerating all possible files and checking their signature against the one you have. If the file is 10bytes or larger, enumerating becomes infeasible. Also, there are likely an infinite number of files with the same signature (rather, hash value) as the one you are missing. Skippydo (talk) 13:01, 25 September 2008 (UTC)

Elonka Dunin

There was a bit of emotion regarding her bio on WP:AN/I, due to some WP:COI issues. Some neutral, and hopefully well-informed input would be appreciated. VG ☎ 22:49, 4 November 2008 (UTC)

Proposal: remove all crypto navboxes

Crypto navboxes are mostly massive shopping lists of primitives. They duplicate the work of categories and the circumstances in which readers will find them useful are almost outside my imagining. There seem to be no good grounds for deciding when a primitive goes into a navbox. I know a lot of work has gone into them, but really, are they useful? I think we should deprecate the lot of them in favour of a single link to the cryptography portal. ciphergoth (talk) 08:55, 5 December 2008 (UTC)

Dunno. I'm happy to go with the consensus, but personally, I quite like them, on balance, simply because it gives a handy way to navigate around pages on related topics. Browsing via categories can be quite a bit more hard work, and the portal isn't quite specific enough. On the other hand, we might easily get (or have gotten) to a point where we have too many articles on particular specific algorithms to sensibly jam into a box. — Matt Crypto 18:07, 5 December 2008 (UTC)

Can you give a more specific example of when you imagine them being useful? Why might I want to know about MUGI when I'm looking at Py, for example? ciphergoth (talk) 18:31, 5 December 2008 (UTC)

If you're interested in learning about a variety of stream cipher designs. It's no different, in that sense, from the nav-boxes you get in, say, cars, or countries. — Matt Crypto 11:08, 6 December 2008 (UTC)

I'll drop this unless I can find anyone else in the world who agrees with me :-) but I think that's a pretty rare use case, and when I'm that person, I'm happy to use the category; I've done that with Category:World War II deception operations for example. It seems crazy to have a huge, attention-grabbing box cluttering up every crypto-related page for such a rare use case which is so easily satisfied another way (a way which is useful on all of Wikipedia). Also, the category is maintained semi-automatically, while ciphers must be added to the navbox by hand, and we still have no good way to decide what ciphers should go in there; what's there at the moment has no relation at all to what might be the most "important" or "representative", but relates solely to who was motivated to add their cipher.

The same arguments may well apply to the car/country navboxes; I'm not involved in those projects and I haven't seen the navboxes so I don't know... ciphergoth (talk) 16:10, 6 December 2008 (UTC)

One thing we can do is to make them minimised by default, so that they aren't so huge and attention-grabbing by default. — Matt Crypto 20:52, 6 December 2008 (UTC)

Yes, that sounds like a good idea, and if you happen to know how to do it I'll be happy to modify the relevant templates. Thanks.

I know I should resist, but: with this change the other related entries are a click away. But that's already true of the categories; they are one click from the article. You say "Browsing via categories can be quite a bit more hard work" and I'd like to understand the advantage you see in navboxes over categories here; I browse via categories quite a bit. ciphergoth (talk) 00:52, 7 December 2008 (UTC)

BTW, Wikipedia:Navigation templates may provide some points of discussion. ciphergoth (talk) 00:58, 7 December 2008 (UTC)

Going to bed now but also good: Wikipedia:Categories, lists, and navigation templates ciphergoth (talk) 01:08, 7 December 2008 (UTC)

For what it's worth, I think this is a great idea. The extreme complexity of the things rather outweighs their usefulness. There's no real need to have such a complicated set of interlinking templates for the relatively mundane task of adding a few relevant links to the end of articles. Chris Cunningham (not at work) - talk 16:03, 19 December 2008 (UTC)

Thanks - I'd love to hear from other people about this! ciphergoth (talk) 14:58, 1 January 2009 (UTC)

I think that the guidelines back me on this. From WP:CLN:

They are particularly useful for small and more or less complete sets; templates with a large numbers of links are not forbidden, but can appear overly busy and be hard to read and use.

We have large and necessarily incomplete sets, resulting in overly busy templates just as it says.

The article links in a navigation template should have some ordering, whether chronological or otherwise. Alphabetical order does not provide any additional value to a category containing the same article links. It is not enough that it is possible to organize the elements of a series into a structure—that structure should itself be useful.

There is no suitable ordering for eg lists of stream ciphers

Ask yourself, is the subject of this box something that would be mentioned on every article in it?

If the answer is "no", a category or list is probably more appropriate.

The answer is no here. Now moving on to WP:NAV:

The goal is not to cram as many related articles as possible into one space. Ask yourself, does this help the reader in reading up on related topics? Take any two articles in the template. Would a reader really want to go from A to B?

No.

They should be kept small in size as a large template has limited navigation value.

Impossible with lists of primitives.

For complex topics in science, technology, history, etc., a navigation box can provide a comprehensive introduction to a topic.

Reading a lot of disparate primitives is a terrible introduction to the topic.

If the group of articles overlaps significantly with an existing category, consider using {{otherarticles}} instead. Of course, since the category is already linked within those articles, {{otherarticles}} may not even provide extra navigational value.

The navbox here is doing nothing that categories don't do - categories have their shortcomings (see WP:CLN again) but since we don't and can't use ordering or annotation, we're providing nothing they don't provide.

Finally, they are so ugly! Look at MD6 - is that article really improved by the big ugly navbox at the bottom? I really don't think it is. ciphergoth (talk) 15:07, 1 January 2009 (UTC)

My 2¢: That hash function navbox (in the MD6 example)) is bloated. Do we really need SHA-3 candidates, right now? It's distracting without providing content/context to the article. Plus, someone who's not already technically competent won't gain much from a table of links. In this example (MD6), I'd vote for the simpler crypto navbox on bottom, and a separate descriptive page/list of the detailed info. Mmernex (talk) 13:02, 18 March 2009 (UTC)

Keep - Navboxes are a long standing practice here on Wikipedia. They are used by many WikiProjects on all kinds of articles. If navboxes are going to be abolished then that should be brought up at Wikipedia:Village pump (policy), not here at this WikiProject.

To me navboxes are an extension of the "See also" section. They make it possible for us to update the list of see also links in one place, instead of manually having to edit several hundred articles.

For us who have a slow connection and/or an old computer the navboxes save a lot of time, since having to load one or more category pages to find an item takes much more time than simply clicking a related item in a navbox.

Categories serve a different purpose, they contain lists of all items of a specific kind. That makes it hard to find out which items are the more relevant ones.

If using the example of the MD6 article: A navbox can contain both a list of related algorithms, relevant background (the "Misc:" section), standardisation, and links to the main areas of cryptography (the lower "Cryptography" box). Those things can't be found on a single category page, instead one would have to spend about an hour clicking around the category tree to find them.

Yes, our crypto navboxes are currently bloated, they should not list all items (that's what categories are for). The navboxes should only contain the more relevant links, but enthusiastic editors tend to add "their" articles to the navboxes. Thus we have to constantly prune the navboxes. So the boxes don't need deleting, instead they need more pruning. For instance, I think we can remove most of the "Attacks:" list from the hash navbox, and move whats left of it to the "Misc:" section.

Mmernex: Right, the SHA-3 candidates list should be removed from the hash navbox. We already link to the "NIST hash function competition" in the "Standardization" list in the same navbox.

Our crypto navboxes currently don't look as good as they could. We should update the crypto navboxes to use the new navbox design standard, that is put the group titles on the left side in purple cells. And the crypto navboxes currently have extra padding around the cells in the upper box which makes them look more bloated than they are. That seems to be a bug in the navbox code that needs to be investigated. But most of us here who have enough template coding skills are busy with more urgent things.

And I have a question for those of you who want to abolish navboxes: Do you really think that the small main {{crypto navbox}} should be removed too?

Ciphergoth: Please don't use shortcuts in text, that's not what they are for. Using shortcuts makes it hard to see what you are linking too. WP:NAV is Wikipedia:Navigation templates which is not a guideline, it is just an essay.

And remember that screen area is cheap, there is no lack of article space. And the navboxes are set to not print: When you print to paper the navboxes are automagically removed. Since paper is a limited resource, and link lists are not very useful on paper.

--David Göthberg (talk) 18:09, 18 March 2009 (UTC)

Cipher or coincidence?

I am working on an Article in my Sandbox; User talk:Stephen2nd/Sandbox (c); For which this is a technical question on de-ciphering processes involving historical Cryptographies.

In two (connected) mottoes, there are two hidden ciphered names which can be de-ciphered by using fingers as a pivot, and pointer. Can anyone tell me the mathematical odds of either of these ciphers being a coincidence? Also, what is the correct terminology for these cipher-mottoes, and the de-cipher process?

Cipher in the Royal Garter: (left and right)-(seven times)-(L:R:L:R:L:R:L): = STEPHEN

Cipher in the Royal motto: (right and left)-(seven times)-(R:L:R:L:R:L:R): = DERMOTT

Thank you for your time and considerations.Stephen2nd (talk) 16:18, 4 January 2009 (UTC)

S, I've only just noticed this, but I'll risk some derision by answering the query, kind of. First, though, I applaud some of work in progress in using the 'y' spelling of cypher; there has been some back and forthing about the correct spelling here on WP.

Heraldry and the meaning of its various signs and arrangements are a kind of code, not a cypher. They are not a rearrangement or substitution of elements of a representation of meaning. Thus, if dog is enyphered as eph (using the obvious substitution scheme), or if dog is encyphered as god (using the obvious transposition) we have a cypher. If on the other hand, the animal (ie, Rover over there) is signified by a recording of his (anonymous to many) bark or by a maple leaf or some other unrelated thing, we have a code. In the classic case, this is a different word, such as the concept "attack at down" being encoded as "apple pie".

In the case of hidden meanings in healdric phrases, it is unclear whether either exists, absent some contemporaneous comment by the devisor of the supposed crypto scheme. It has been not unknown to find hidden meanings enciphered (or perhaps encoded or both) in important texts. The entire Bible Code business of recent years is an example. There are obvious difficulties in many cases, as for instance the difficulty of determining the Number of the Beast from the Book of Revelations (see the comment in our History of Cryptography article for a brief mention). Is it 666 or is it 616 or even something else? Translations, scribal errors, typesetting errors (at least one early English Bible version is best known by an amusing typo), and 'helpful' editing, as in the cleanup of Shakespeare's work by Bowdler, or by assorted actors, pirate printers, or his friends during his life and after his death raise even more. There is a long history of blunder and goof and blind insistence on the unlikely in the case of alleged hidden meanings in Shakespeare. In fact, the important cryptographer William Friedmann got his start in crypto due to one instance of the business and many years (and a few wars) later wrote a magisterial book on the subject.

Considering the long-extant generally anarchic state of spelling in English (perhaps especially during Shakespeare's time?), the situation is still worse. Probably irretrievably so.

Combined with the logical impossibility of proving a negative proposition ("Prove to me there's no secret message in this text!"), much of this has had an entirely unjustified extended life.

In the case of your conjectured cipher and another prescribed method for it's cryptanalysis, I think there is a misconception here. There are indeed rules which are followed during encryption of plaintexts using particular cyphers. And there are rules which are followed in embedding any text (encyphered or not) in some background text (termed steganography) using any specific stego method. But these are distinct matters and one is very rarely connected with the other. obviously so, as may be seen by thinking about the situation a bit. A cyphertext is necessarily random looking (and the less random it actually is, however it looks, the easier it will be to decypher) and so embedding it in otherwise readable text will be different each time. Consider steganographically embedding two encryptions of dog in readable text; if one is god, the task will be quite different than for another cypher which produces eph as the cyphertext. Even in English, knitting in the second may tax ingenuity.

For all these reasons, and more, the cypher suggested by various folks and believed by some Mowbrays and McDermotts, seems unlikely on its face. Possible, as proving a negative is not possible, but...

All that said, one of the first known uses of cryptography in human affairs was not for concealment of meaning, but more likely a jest or deliberate put on. I refer to some incised inscriptions fom several thousand years back in Egypt. Clearly important enough to assign some one with a chisel (not free even if a talented slave -- they do have to be fed and housed), clearly not time sensitive (the stone was almost certainly intended to hang around for a long time), and not very distant either (carved stone is a lousy medium for carrying messages to remote locations). These limitations suggest something else, perhaps something that might be expected to be significant to those who noticed it (not everyone could read in those days, of course); humor is an obvious possibility. Some of Chaplin's stuff is still funny today, these many generations later and despite lack of sound.

I regret to say I think there is a reason I am the first to respond here. I don't think there are answers from the technical or theoretical crypto side. Perhaps from history? ww (talk) 18:57, 18 March 2009 (UTC)

Merging dead ciphers into NESSIE

Following a discussion in Talk:Q (cipher), we propose that merely being part of a competition that allows any entrant isn't a mark of sufficient notability to have an article, and so those ciphers that never made it past the first round of these contests and have no other claim to notability should be merged into NESSIE. I think that's Q (cipher), Nimbus (cipher), NUSH, Grand Cru (cipher), Hierocrypt, LILI-128. Please discuss at Talk:NESSIE#Merger proposal - thanks! ciphergoth (talk) 12:56, 18 January 2009 (UTC)

MOSMATH

Please: Wikipedia:Manual of Style (mathematics) really does exist!!

I keep finding cryptography articles with things like

$GHASH(A,B,C)\,$

instead of

${\text{GHASH}}(A,B,C)\,$

and

$len(X)\,$

instead of

$\operatorname {len} (X)\,$

and lots of other uncouth usages. Michael Hardy (talk) 17:13, 2 March 2009 (UTC)

{{sofixit}}? Frankly, it doesn't look like much of a benefit to me to make those changes, unless one's going for a WP:FA. Mangojuice^talk 15:02, 3 March 2009 (UTC)

So what's wrong with that? ;) I vote 'go for it'. Mmernex (talk) 13:07, 18 March 2009 (UTC)

"Sofixit" works if it's just one article. I said it's a pattern. A deficiency of respect for WP:MOS and WP:MOSMATH in the cryptography community. (Nowhere near as bad as in some other subjects, like management and maybe computer science, both of which have trouble understanding that lower-case initial letters exist.) Michael Hardy (talk) 17:16, 24 April 2009 (UTC)

I see something in WP:MOSMATH addressing your second example (len), but not your first one (GHASH). There's nothing there to even say the first GHASH syntax is more "uncouth" than the second one, let alone why. Maybe WP:MOSMATH needs to say what you think it does before you start criticizing deviations from it. Ntsimp (talk) 18:12, 24 April 2009 (UTC)

For GHASH: Wikipedia:Manual of Style (mathematics)#Functions. Skippydo (talk) 18:19, 24 April 2009 (UTC)

I stand corrected. I was looking for something recommending the \text syntax there and missed the more general guidance. Ntsimp (talk) 18:25, 24 April 2009 (UTC)

Enigma machine FAR

I have nominated Enigma machine for a featured article review here. Please join the discussion on whether this article meets featured article criteria. Articles are typically reviewed for two weeks. If substantial concerns are not addressed during the review period, the article will be moved to the Featured Article Removal Candidates list for a further period, where editors may declare "Keep" or "Remove" the article's featured status. The instructions for the review process are here. Cirt (talk) 07:45, 7 April 2009 (UTC)

Alan Turing Year

The new page titled Alan Turing Year is moderately orphaned: probably more pages should link to it. Michael Hardy (talk) 17:13, 24 April 2009 (UTC)

Japanese cipher machines

I have just finished an article on the RED cipher, and would invite examination of it. I am now going to go back and work over Purple (cipher machine), which has many issues. Again, I wouldn't mind some help on the latter. Mangoe (talk) 13:50, 29 April 2009 (UTC)

Merging key management with symmetric key management

I wanted to write an article on the java keystore but found we already have a small article on key management which can be expanded. It is however a merge candidate with Symmetric key management. I thought I would rather wait until a decision is reached on the merger before I start writing. Can you vote on Talk:Key management#Merge symmetric key management. Jay (talk) 08:19, 12 May 2009 (UTC)

Socialist Millionaire Example is insecure

As I have found out some time ago the example shown in the Socialist millionaire article is vulnerable to poisoning. To put it simple: if Alice chooses a2 and a3 to be zero the final check will always be 1^n = 1/1 . Bob can do the same by choosing b2 and b3 to be zero. That means that the assumption "which means that the test at the end of the protocol will only succeed if x equals y" is wrong. —Preceding unsigned comment added by 80.187.100.56 (talk) 20:05, 31 May 2009 (UTC)

EAX mode---what does it stand for?!

Just a quick question, hoping someone might know and update the relevent page. What does EAX stand for/where does the acronym come from? Jack joff (talk) 11:12, 5 June 2009 (UTC)

Why not just ask the people who have developed it (EAX paper)? 80.187.105.218 (talk) 15:57, 5 June 2009 (UTC)

Merkle-Hellman knapsack cryptosystem

I have added an example to the Merkle-Hellman knapsack cryptosystem page. Please review. I know it is correct, but since it is a large addition, could some people copyedit it?--Michael miceli (talk) 00:26, 6 August 2009 (UTC)