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. |
Archive 1 | Archive 2 |
This should probably be combined with Asymmetric key algorithm or vice-versa. Rasmus Faber 15:39, 8 Dec 2003 (UTC)
Rasmus, I think I disagree. Not because there is any content issue here, but because public discussion of the subject has become perverted by -- well, let's blame them, it's probably their fault anyway -- the journalists. As with the hijacking of the word hacker, public key has come to mean asymmetric key. In fact, some asymmetric key algorithms are not public key, and vice versa.
Perhaps the best option is to have an entry 'public key' pointing to the 'asymmetric key' article. At least then the Wikipedia would not be contributing to the distortion of content in this area.
ww
The actual situation, if you'll permit me to be a little pedantic, is that asymmetric key algorithms are tools used in public key cryptography. Merging these two articles would be like merging block cipher and symmetric key cryptography. Public key cryptography includes more than just asymmetric key algorithms - it includes key agreement algorithms and digital signature algorithms, not to mention the actual protocols in which these algorithms are used. I disagree with the merge -- leave them separate. Decrypt3 21:27, Jul 10, 2004 (UTC)
Ed Felten conducted a "Wikipedia quality check", examining a handful of articles; he said
— Matt 01:38, 6 Sep 2004 (UTC)
Should RSA be in the highly regarded section? I thought that significant flaws existed compared to ElGammal User:Watsonladd
There isn't any word about Diffie-Hellman key exchange algorithm in the history section, I think it is the first public asymmetric-key cryptography algorithm. Gbiten 02:55, 24 Dec 2004 (UTC)
I guess I'm inclined to agree on this. Perhaps a pointer to a D-H article would be appropriate? ww 19:27, 19 Jan 2005 (UTC)
Why is DH cited as an example of public key? Isn't it a symmetrical key algorithm?
Parakan, in a recent edit summary suggested such an article may be needed. Given the way things have developed regarding cryptography topics here, he's probably right. I think we need one, and pointers to it from, eg, cryptosystem and perhaps cryptographic engineering. ww 19:27, 19 Jan 2005 (UTC)
I am very much outside my area of expertise here, but is it not true that public key cryptography (in general) would be in serious trouble if an efficient algorithm were found to solve the Diffie-Hellman problem? The article on this (as yet unsolved) problem is new and, I think, very good; perhaps someone with more knowledge of the subject could briefly discuss this vulnerability here and link to Diffie-Hellman problem. Regards Bryan 14:42, 29 November 2005 (UTC)
I am writing my Security+ test tomorrow and need a clarification about one issue in regards to PGP. My question is "What does PGP uses to encrypt data....Asymetric or Symetric algorithms? —Preceding unsigned comment added by 24.83.1.79 ( talk • contribs) 07:17, 30 November 2005.
The tone of this section seems a bit paranoid:
(from Practical considerations → Weaknesses)
I can see that this could be a practical concern to have, but I can't remember the last time I saw an exclamation mark in an encyclopedia...
There is something that has been bothering me in many descriptions of public key encryption. I see that it is possible to use a private key to encrypt a message and the public key to decrypt same. This seems very insecure since anyone intercepting the message can then use a person's public key to decrypt it? What am I missing?
Thanks Simon PS. As you can tell I am a cryptosystems newbie :-(
In reference to using private key encryption for authentication and non-repudiation in the Application section, is there a difference between authentication and non-repudiation in this case or not? --
Etienne
03:56, 30 July 2006 (UTC)
The discussion of interception/falsification weaknesses for public key approaches (the last paragraph in the weakness section) would be greatly helped by mentioning that these vulnerabilities can be avoided by using a secure connection such as SSL.
By grouping interception/falsification vulnerabilities together with weaknesses that are truly unknown and not preventable (due to the nature of algorithms) it makes these problems sound equally unavoidable when in fact modern implementations of public key cryptography require approaches that prevent most forms of interception and falsification (for example SSL makes man-in-the-middle attacks impossible based on what I know about it).
Also, mentioning that gaining control of the users system and by extension their private key is another potential security risk which, while obvious, rounds out the list of weaknesses. Since currently I'm learning about cryptography I'd rather leave this to more qualified editiors to consider and potentially implement. Antonrojo 14:52, 14 May 2006 (UTC)
Pointing specifically at the government as the corrupter of CA signing authorities is both biased and short sighted. Any number of entities might blackmail or convince a CA to sign bogus certificates (kidnap CEO's kids, bank holding loan on CA or who has potential large legal suit for losses due to CA error, etc). Further this overlooks social engineering of applications (as happened to Microsoft), internal attackers at the CA (for profit, revenge, etc) and CA servers simply succumbing to intrusions. —Preceding
unsigned comment added by
70.230.251.78 (
talk •
contribs)
In the last paragraph of the Weaknesses, the last two sentences about government coercion are very unclear. Right now it's written as follows:
This attack is especially interesting when the attacker is the government as they potentially have the power to persuade a Certificate Authority to sign a bogus public key. Then the government can plug off the cable at Bob's ISP and insert their bogus web server. The function of this server is to present itself as Alice (validated by the certificate obtained by coercion), log all messages and forward them to the "real" Alice web server.
I started rewriting it as,
This attack is especially interesting when the attacker is the government as they potentially have the power to persuade a Certificate Authority to sign a bogus public key. In this case for instance, if Bob's ISP was sending a message to Alice, they could intercept the message by posing as Alice (validated by the certificate obtained by coercion), log all mesages and then forward them to the "real" Alice web server.
but I think this is wrong. I'm really having trouble understanding what the original text meant. -- Etienne 05:10, 30 July 2006 (UTC)
I made some diagrams for this article. I put the first draft version of the diagrams into the article. I hope you like them. I have some ideas about how to extend them but not sure that is necessary. For instance adding the Alice and Bob users in the encrypt and sign images just like I have in the shared secret image.
I made the images in .svg format which usually works fine. But this time Wikimedia rendered them wrong. I tried several ways to fix it but failed. So I put .png versions into the article instead. The .svg versions of the images are available here: User:Davidgothberg/Test_area. If any one can fix them so they render correctly I would appreciate it.
-- David Göthberg 09:45, 7 August 2006 (UTC)
Just before your comment I updated the images again. I removed the (ASK) and (AVK) to make the images less cluttered. And I added "Big random number" to the first image to make it self-explanatory and not dependant on the image caption. Regarding the Alice/Bob labels I am unsure myself. To me they seem both good and bad. Depends on what one wants to explain. Let's leave them in there for a while and see what other Wikipedians think about it. I will ask the people in the crypto chat I hang out in too, they often have some good comments/ideas. -- David Göthberg 01:39, 8 August 2006 (UTC)
The literature usually describes the private key operation as sign/decrypt and the public key operation as verify/encrypt. Yet the diagram/image that shows the signature scheme shows the private key operation as sign/ENCRYPT and the public key operation as verify/DECRYPT. I think this is confusing at best. But is it wrong or dangerous for any specific public key scheme? 163.181.251.9 ( talk) 22:11, 24 September 2009 (UTC)
I tried following the diagrams and the article but I can't understand why I'm able to read sent emails I've encrypted in Outlook Express since I shouldn't be able to according to the diagrams and this statement "a message encrypted with a recipient's public key cannot be decrypted by anyone except the recipient possessing the corresponding private key. This is used to ensure confidentiality." I am not in possession of the recipients private key, only their public one, so how come I am able to read the emails I sent to them in my sent items folder? As far as I know digital signing and encryption used in Outlook Express is public key cryptography. 121.209.117.2 21:43, 28 September 2007 (UTC)
This article seems to claim that private key encryption cannot be made safe against a brute force attack. However a private key encrytion placed over another private key cannot ever be cracked by someone without at least one of the keys. Why has this been overlooked? Symmetric Chaos 13:18, 20 September 2006 (UTC)
I have never seen the term "Key Making Function" used in any cryptography paper - the standard term is Key Generation function. If no-one objects, I will change the diagram to reflect this. Birkett 15:17, 21 November 2006 (UTC)
The external link for note 4 ("The NSA has also claimed to have invented public-key cryptography, in the 1960s; however, there is currently (as of 2004) little supporting public evidence for this claim") is broken. I suspect it was attempting to link to something called "NSA Memorandum 160" -- could someone with actual knowledge of this subject confirm that? (The text of that memo is available online; this may be exactly what was being linked to.) Jd4v15 19:30, 1 February 2007 (UTC)
Reading this article is annoying because of the dorky demands for citations every 6 words. Stop making demands for citations for simple statements. It detracts from the readability. -- 61.9.138.145 23:53, 12 March 2007
The following text seems dubious:
It appears that when a private key high in the hierarchy (which probably means a key of a certificate authority) is disclosed then this key must be revoked and certificates signed with that key must be reissued. But I can't see any need for revoking keys signed with that key. This text seems to be some kind of false advertising for the company offering transient key crypto. 85.2.94.204 ( talk) 22:28, 11 December 2007 (UTC)
<--
You state the case exactly, but do not draw the practical conclusion. A compromised CA means that all certificates depending on that CA (or any CA lower in the heirarchy) must get a new certificate from some other CA. This is the entire problem CAs are supposed to assist with and solve. When they fail, users are thrown back to the Wild west condition of being unable to be sure any key belongs to anyone in particular, thus stopping protected communications abruptly and permanently until new certificates are obtained and published. The problem is not with the user's encryption/decryption which as you point out may be perfectly sensible and secure in practice, but with the system on which communication relies, namely an uncorrupted CA in a PKI system. Both are required for successful secure communication and either alone is insufficient.
I'll look into the article again to see whether something can be done to make clear the point to our Average Reader. ww ( talk) 00:23, 13 October 2008 (UTC)
<--
Failure to authenticate a piece of information does not invalidate that piece of information. Certificates exists precisely to avoid man in the middle attacks. They are independent of the security of the actual scheme, where public keys are assumed to be communicated through an authenticated channel. There is absolutely no reason to discard a key when a certifying authority of this key is compromised. I cannot see any theoretical or practical reason why one would wish to discard the key in this case. Skippydo ( talk) 06:18, 20 October 2008 (UTC)
The UK has a law ( Regulation of Investigatory Powers Act or RIPA) that requires you to either provide clear-text versions of encrypted data, or to provide a decryption key upon receipt of a "Section 49" notice. Recipients are also bound from telling anyone apart from their lawyer that they have been issued the notice. This power, whilst originally passed in 2000 was activated in 2007 [1].
Is it not possible for someone to decrypt data that has been encrypted with other people's public keys. To do so would require access to the other person's private key. It is therefore a problem to use public-key cryptography if you are not keeping a clear-text version of everything you encrypt.
For example: say you use a friend's public key to encrypt a message to him - say your bank details to repay you some money you lent him. There is no surrounding text on the message to make it clear what the message was about. 5 years go past. He has changed his keys in this time, or has moved away, or has died, or lost his private key for some reason. Should you ever be asked to tell the police what the message in my Outbox was about, or to provide a cleartext version, you would be unable to comply as you could never have decoded it. That gives you an automatic 2 year jail sentence.
This has not yet come to court, although it has started to be used by the police [2] - and not against al-Qaeda or child porn creators, either.
The analogy given: "In an asymmetric key system, Bob and Alice have separate padlocks. First, Alice asks Bob to send his open padlock to her through regular mail, keeping his key to himself. When Alice receives it she uses it to lock a box containing her message, and sends the locked box to Bob. Bob can then unlock the box with his key and read the message from Alice. To reply, Bob must similarly get Alice's open padlock to lock the box before sending it back to her."
is flawed in that it is subject to a man-in-the-middle attack. If a malicious third-party were to intercept Bob's open padlock in transit, and then sends their own open padlock to Alice, Alice will send her secret message back with the attacker's padlock, which the attacker can easily remove. Once the attacker has finished with the message, he can simply replace Bob's padlock on the message, and send it to Bob, who believes it has come from Alice untampered.
The second analogy with two different padlocks is also flawed:
"In another kind of asymmetric key system, Bob and Alice have separate padlocks. First, Alice puts the secret message in a box, and locks the box using a padlock to which only she has a key. She then sends the box to Bob through regular mail. When Bob receives the box, he adds his own padlock to the box, and sends it back to Alice. When Alice receives the box with the two padlocks, she removes her padlock and sends it back to Bob. When Bob receives the box with only his padlock on it, Bob can then unlock the box with his key and read the message from Alice."
The problem again lies in a third-party with their own padlocks. When Alice sends the message with her padlock to Bob, the attacker intercepts and places his own padlock on the box, and sends it back to Alice, who dutifully removes her padlock, and sends it off to the attacker, who can now unlock and read the message and possibly change it maliciously. Now, similarly, the attacker can send the box off to Bob with his padlock on it, and Bob, believing it to have come from Alice, places his padlock on it, and sends it off again. The attacker removes his padlock and sends it to Bob, who removes his padlock and reads the tampered message.
In both cases, the main problem is the fact that there is no verification of identity. Bob and Alice have no idea what the other's padlocks should look like, and even if they do, have no way to verify that it is in fact the senders.
I think these weaknesses should be detailed in the Weaknesses section, as there is no clear (from what I can see) expression of the weaknesses of the actual analogy. Sorry for the lengthiness, but I felt the analogies needed to be picked apart in detail.
Matwilko ( talk) 17:08, 9 March 2008 (UTC)
Another issue I see with the example is - when it says "First, Alice asks Bob to send his open padlock to her through regular mail, keeping his key to himself. When Alice receives it she uses it to lock a box containing her message". How is that possible, when Alice does not have the key, but only has the padlock Bob sent her. She cannot lock a box with only the padlock. I don't think the postal analogy holds true for asymmetric keys because its difficult to find a real life equivalent to the mathematical concept underlying this technology. —Preceding unsigned comment added by 17.227.143.125 ( talk) 20:35, 28 July 2009 (UTC)
In the security section, the following statement I think could use more elaboration: "To achieve authentication, non-repudiation, and confidentiality, the sender would first encrypt the message using his private key, then a second encryption is performed using the recipient's public key."
Namely, does it really matter which encryption is done first and which is done second? If if does, it would probably be good to add a sentence explaining why. If it doesn't, to add a sentence saying the actual ordering of the two encryptions is unimportant. —Preceding unsigned comment added by 70.17.114.124 ( talk) 20:19, 22 June 2008 (UTC)
This article contains a diagram showing the possibility of two parties each combining their own private key with the public key of the other party to yield a new shared secret. I assume that this is done without exchanging any messages (which would make it easy). I see that this is possible with some public key schemes (notably ElGamal), but I have no idea how (and honestly doubt that) it could be done with RSA for example. Could someone please give more information about this (in short: Citation needed)? —Preceding unsigned comment added by 141.3.32.141 ( talk) 08:36, 10 July 2008 (UTC)
<-- DG, I now understand the point you had in mind when you reverted. I agree with your comments above. What I disagree with is that the fourth image suggests what you think it does. I took it to mean concatenation of secret key with other material as that's what the image shows. Other processing, as you suggest would clearly be sensible, which is the import of the comment I added. I was trying for brevity and a note of caution. If we revise the image to suggest additional processing, I'd have no problem. With the image as it was, there is sufficient imprecision that it can lead to confusion. It certainly misled me, and I'm a little less credulous re crypto than the Average Reader can be expected to be. ww ( talk) 02:43, 22 July 2008 (UTC)
I have a problem with understanding this section so it appears to me that there's an error in writing. It says:
...in such [hybrid] cryptosystem, a shared secret key ("session key") is generated by one party and this much briefer session key is then encrypted by each recipient's public key. Each recipient uses the corresponding private key to decrypt the session key. Once all parties have obtained the session key they can use a much faster symmetric algorithm to encrypt and decrypt messages.
Now it appears to me that all an attacker may need is a public key from a recipient (which is public, therefore available) to gain the session key and break any security. Another thing which I can't understand is whether the session key is encrypted by all recipents' public keys combined or using a corresponding public key for each recipent (it only says "encrypted by each recipient's public key).
I hope you understand what I mean. -- Darko Maksimović ( talk) 13:16, 24 July 2008 (UTC)
The renaming of the category was not suggested by me and I disagree with the suggestion. I just report it here so more editors can join in the discussion. (Follow the "discussion" link in the box above if you want to discuss it.)
-- David Göthberg ( talk) 15:40, 2 August 2008 (UTC)
Category:Public-key cryptography is itself a category within Category:Cryptography. — Robert Greer ( talk) 15:34, 6 March 2009 (UTC)
I'm reading this article and the diagrams are nice and all, but they lack any description of how this works mathematically. How is it possible to encrypt with one key and decrypt with the other? A math section would add to this article.
I concur - without reducing to practice, the article devolves into hand waving. You can write an algorithm from any of the diagrams on: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation This article should achieve at least that depth. —Preceding unsigned comment added by 69.254.42.143 ( talk) 02:25, 19 January 2010 (UTC)
I'm having a problem with the following:
The first time I read this, it appeared to say that D & H's work was based on the GCHQ material. Following sentences clarify it, but what I'm looking for is a way of rewording the sentence so that it's referring to the the type of the inventions, rather than the specific work. How about, "...1970s; these inventions were {the same as, similar to} what later became known as..."? Since I'm not familiar enough with either work, I don't feel comfortable just plopping it in without checking with others.
GuiderBob ( talk) 20:21, 27 May 2009 (UTC)
I'm not exactly familiar with their work either. But it's safe to say that they were developed independently. I took a stab at rewriting the paragraph in question. Also, I moved it to the end so that it has a better context. Please tell me what you think. Skippydo ( talk) 02:09, 28 May 2009 (UTC)
Introduction needs to be rewritten for accessibility by nonspecialist readers, and to change from a description of behavior - "a form of cryptography in which" - to at least include a description of context - "a form of cryptography that". A nonexperienced person should be able to walk in and glean a concise and precise idea of what public-key cryptography is, what it is used for, to what end, in what media, and in what context as available; notwithstanding details, of course - that's what the body of the article is for.
I performed a total revamp of the summary, and I separated what was a very detailed working description from the summary into a section called "How it works". This section needs to be merged with the section "Description", preferably retaining the name "How it Works". The description is already covered by the summary (I hope). Stephen Charles Thompson ( talk) 22:03, 21 November 2009 (UTC)
"Asynchronous encryption" is not an accepted term for public-key cryptography, and does not appear in any literature. Perhaps it is a corruption of "Asymmetric cryptography," which is an accepted term, but the word "asynchronous" refers to a different concept entirely. Hashbrowncipher ( talk) 22:31, 23 February 2010 (UTC)
I've been making a few minor changes, but need clarification on this passage:
In contrast, symmetric-key algorithms, variations of which have been used for some thousands of years, use a single secret key shared by sender and receiver (which must also be kept private, thus accounting for the ambiguity of the common terminology) for both encryption and decryption [emphasis mine]
What common terminology is ambiguous? What "must also be kept private", just the key or something else, too? I'm going to take a stab at fixing this up, but please let me know or help out if I botch anything. Thanks! / ninly( talk) 21:29, 6 July 2010 (UTC)
The "How it works" section states that "each user has a pair of cryptographic keys—a public encryption key and a private decryption key". This makes it sound like public keys are only uses for encryption, and private keys are only used for decryption, which not the case for signatures. For years, I was confused on this point. The article needs to make it more clear that information encrypted with one key (which may either be the public key or the private key, depending on what you're trying to accomplish) may only be decrypted with the other key. —Preceding unsigned comment added by AndrewGarber ( talk • contribs) 04:18, 8 May 2011 (UTC)
Can someone explain why these systems are not completely compromised by simply reversing what ever process the 'public' key does to the message;thereby recreating the original plain text. The fact that the 'private' key cannot be determined from the 'public' key would seem to be completely irrelevant, since whatever the program does with the public key to encrypt the message could certainly be undone, using the 'public' key, by a program specifically written to do so. This has always seemed obvious to me and so must occur to others. An explanation of why this isn't (or is) a problem would seem beneficial to me. Danm60 ( talk) 17:39, 11 September 2010 (UTC)
Both the introduction to the article and the Weaknesses section addresses just this sort of an issue. It's possible to 'undo' it, but it's also computationally expensive. So expensive that in most circumstances, it's not even worth trying. Through some really, really complex mathematics, you get a function that is easy to perform in one direction, but incredibly hard to perform in the other direction. Gahread ( talk) 14:37, 22 September 2010 (UTC)
The same point occurred to me as to Danm60. I think I understand Gahread's reply (in principle!), but I don't think the explanation is at all clear in the existing article. The intro to the article says that 'it is extremely difficult for anyone to figure out the private key based on their knowledge of the public key', but this is not Danm60's (or my) concern. Intuitively, if the encrypted message is made using some algorithmic operation on the 'public' key, then it seems plausible that if one knows the message, the algorithm, and the public key, one can reverse the process and decrypt the message without first finding the 'private' key. I understand from Gahread's reply that this is in practice very difficult because of the nature of the algorithm, but I think the article itself could be clearer about this. 109.149.27.90 ( talk) 14:00, 6 September 2011 (UTC)
Given that all of this is difficult by intention, is it at all possible to give worked examples? Maybe by using a quite trivial pair of keys and a trivial trapdoor program? Old_Wombat ( talk) 10:12, 5 March 2011 (UTC)
If it is correct that,
then, this article must cite da Vinci! —Preceding unsigned comment added by 187.56.21.46 ( talk) 11:53, 10 March 2011 (UTC)
Just saw the same claim in the novel, and looked it up online, and unsurprisingly, it appears not to be true:
http://boards.straightdope.com/sdmb/showthread.php?t=272184
Electronwill ( talk) 06:07, 27 September 2011 (UTC)
There is a section titled Actual Algorithms - Two Linked Keys, but when going to that section there's yet another description of encryption by means of analogies, and certain nothing resembling an Actual Algorithm. Silas Maxfield ( talk) 09:26, 2 February 2012 (UTC)
Surely given all that is said in this article., the link to
http://gpg4win.org/documentation.html
is inappropriate. Far more suitable external links readily come to mind.
Please consider an edit to remove that link. G. Robert Shiplett 15:13, 15 June 2011 (UTC)
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. |
Archive 1 | Archive 2 |
This should probably be combined with Asymmetric key algorithm or vice-versa. Rasmus Faber 15:39, 8 Dec 2003 (UTC)
Rasmus, I think I disagree. Not because there is any content issue here, but because public discussion of the subject has become perverted by -- well, let's blame them, it's probably their fault anyway -- the journalists. As with the hijacking of the word hacker, public key has come to mean asymmetric key. In fact, some asymmetric key algorithms are not public key, and vice versa.
Perhaps the best option is to have an entry 'public key' pointing to the 'asymmetric key' article. At least then the Wikipedia would not be contributing to the distortion of content in this area.
ww
The actual situation, if you'll permit me to be a little pedantic, is that asymmetric key algorithms are tools used in public key cryptography. Merging these two articles would be like merging block cipher and symmetric key cryptography. Public key cryptography includes more than just asymmetric key algorithms - it includes key agreement algorithms and digital signature algorithms, not to mention the actual protocols in which these algorithms are used. I disagree with the merge -- leave them separate. Decrypt3 21:27, Jul 10, 2004 (UTC)
Ed Felten conducted a "Wikipedia quality check", examining a handful of articles; he said
— Matt 01:38, 6 Sep 2004 (UTC)
Should RSA be in the highly regarded section? I thought that significant flaws existed compared to ElGammal User:Watsonladd
There isn't any word about Diffie-Hellman key exchange algorithm in the history section, I think it is the first public asymmetric-key cryptography algorithm. Gbiten 02:55, 24 Dec 2004 (UTC)
I guess I'm inclined to agree on this. Perhaps a pointer to a D-H article would be appropriate? ww 19:27, 19 Jan 2005 (UTC)
Why is DH cited as an example of public key? Isn't it a symmetrical key algorithm?
Parakan, in a recent edit summary suggested such an article may be needed. Given the way things have developed regarding cryptography topics here, he's probably right. I think we need one, and pointers to it from, eg, cryptosystem and perhaps cryptographic engineering. ww 19:27, 19 Jan 2005 (UTC)
I am very much outside my area of expertise here, but is it not true that public key cryptography (in general) would be in serious trouble if an efficient algorithm were found to solve the Diffie-Hellman problem? The article on this (as yet unsolved) problem is new and, I think, very good; perhaps someone with more knowledge of the subject could briefly discuss this vulnerability here and link to Diffie-Hellman problem. Regards Bryan 14:42, 29 November 2005 (UTC)
I am writing my Security+ test tomorrow and need a clarification about one issue in regards to PGP. My question is "What does PGP uses to encrypt data....Asymetric or Symetric algorithms? —Preceding unsigned comment added by 24.83.1.79 ( talk • contribs) 07:17, 30 November 2005.
The tone of this section seems a bit paranoid:
(from Practical considerations → Weaknesses)
I can see that this could be a practical concern to have, but I can't remember the last time I saw an exclamation mark in an encyclopedia...
There is something that has been bothering me in many descriptions of public key encryption. I see that it is possible to use a private key to encrypt a message and the public key to decrypt same. This seems very insecure since anyone intercepting the message can then use a person's public key to decrypt it? What am I missing?
Thanks Simon PS. As you can tell I am a cryptosystems newbie :-(
In reference to using private key encryption for authentication and non-repudiation in the Application section, is there a difference between authentication and non-repudiation in this case or not? --
Etienne
03:56, 30 July 2006 (UTC)
The discussion of interception/falsification weaknesses for public key approaches (the last paragraph in the weakness section) would be greatly helped by mentioning that these vulnerabilities can be avoided by using a secure connection such as SSL.
By grouping interception/falsification vulnerabilities together with weaknesses that are truly unknown and not preventable (due to the nature of algorithms) it makes these problems sound equally unavoidable when in fact modern implementations of public key cryptography require approaches that prevent most forms of interception and falsification (for example SSL makes man-in-the-middle attacks impossible based on what I know about it).
Also, mentioning that gaining control of the users system and by extension their private key is another potential security risk which, while obvious, rounds out the list of weaknesses. Since currently I'm learning about cryptography I'd rather leave this to more qualified editiors to consider and potentially implement. Antonrojo 14:52, 14 May 2006 (UTC)
Pointing specifically at the government as the corrupter of CA signing authorities is both biased and short sighted. Any number of entities might blackmail or convince a CA to sign bogus certificates (kidnap CEO's kids, bank holding loan on CA or who has potential large legal suit for losses due to CA error, etc). Further this overlooks social engineering of applications (as happened to Microsoft), internal attackers at the CA (for profit, revenge, etc) and CA servers simply succumbing to intrusions. —Preceding
unsigned comment added by
70.230.251.78 (
talk •
contribs)
In the last paragraph of the Weaknesses, the last two sentences about government coercion are very unclear. Right now it's written as follows:
This attack is especially interesting when the attacker is the government as they potentially have the power to persuade a Certificate Authority to sign a bogus public key. Then the government can plug off the cable at Bob's ISP and insert their bogus web server. The function of this server is to present itself as Alice (validated by the certificate obtained by coercion), log all messages and forward them to the "real" Alice web server.
I started rewriting it as,
This attack is especially interesting when the attacker is the government as they potentially have the power to persuade a Certificate Authority to sign a bogus public key. In this case for instance, if Bob's ISP was sending a message to Alice, they could intercept the message by posing as Alice (validated by the certificate obtained by coercion), log all mesages and then forward them to the "real" Alice web server.
but I think this is wrong. I'm really having trouble understanding what the original text meant. -- Etienne 05:10, 30 July 2006 (UTC)
I made some diagrams for this article. I put the first draft version of the diagrams into the article. I hope you like them. I have some ideas about how to extend them but not sure that is necessary. For instance adding the Alice and Bob users in the encrypt and sign images just like I have in the shared secret image.
I made the images in .svg format which usually works fine. But this time Wikimedia rendered them wrong. I tried several ways to fix it but failed. So I put .png versions into the article instead. The .svg versions of the images are available here: User:Davidgothberg/Test_area. If any one can fix them so they render correctly I would appreciate it.
-- David Göthberg 09:45, 7 August 2006 (UTC)
Just before your comment I updated the images again. I removed the (ASK) and (AVK) to make the images less cluttered. And I added "Big random number" to the first image to make it self-explanatory and not dependant on the image caption. Regarding the Alice/Bob labels I am unsure myself. To me they seem both good and bad. Depends on what one wants to explain. Let's leave them in there for a while and see what other Wikipedians think about it. I will ask the people in the crypto chat I hang out in too, they often have some good comments/ideas. -- David Göthberg 01:39, 8 August 2006 (UTC)
The literature usually describes the private key operation as sign/decrypt and the public key operation as verify/encrypt. Yet the diagram/image that shows the signature scheme shows the private key operation as sign/ENCRYPT and the public key operation as verify/DECRYPT. I think this is confusing at best. But is it wrong or dangerous for any specific public key scheme? 163.181.251.9 ( talk) 22:11, 24 September 2009 (UTC)
I tried following the diagrams and the article but I can't understand why I'm able to read sent emails I've encrypted in Outlook Express since I shouldn't be able to according to the diagrams and this statement "a message encrypted with a recipient's public key cannot be decrypted by anyone except the recipient possessing the corresponding private key. This is used to ensure confidentiality." I am not in possession of the recipients private key, only their public one, so how come I am able to read the emails I sent to them in my sent items folder? As far as I know digital signing and encryption used in Outlook Express is public key cryptography. 121.209.117.2 21:43, 28 September 2007 (UTC)
This article seems to claim that private key encryption cannot be made safe against a brute force attack. However a private key encrytion placed over another private key cannot ever be cracked by someone without at least one of the keys. Why has this been overlooked? Symmetric Chaos 13:18, 20 September 2006 (UTC)
I have never seen the term "Key Making Function" used in any cryptography paper - the standard term is Key Generation function. If no-one objects, I will change the diagram to reflect this. Birkett 15:17, 21 November 2006 (UTC)
The external link for note 4 ("The NSA has also claimed to have invented public-key cryptography, in the 1960s; however, there is currently (as of 2004) little supporting public evidence for this claim") is broken. I suspect it was attempting to link to something called "NSA Memorandum 160" -- could someone with actual knowledge of this subject confirm that? (The text of that memo is available online; this may be exactly what was being linked to.) Jd4v15 19:30, 1 February 2007 (UTC)
Reading this article is annoying because of the dorky demands for citations every 6 words. Stop making demands for citations for simple statements. It detracts from the readability. -- 61.9.138.145 23:53, 12 March 2007
The following text seems dubious:
It appears that when a private key high in the hierarchy (which probably means a key of a certificate authority) is disclosed then this key must be revoked and certificates signed with that key must be reissued. But I can't see any need for revoking keys signed with that key. This text seems to be some kind of false advertising for the company offering transient key crypto. 85.2.94.204 ( talk) 22:28, 11 December 2007 (UTC)
<--
You state the case exactly, but do not draw the practical conclusion. A compromised CA means that all certificates depending on that CA (or any CA lower in the heirarchy) must get a new certificate from some other CA. This is the entire problem CAs are supposed to assist with and solve. When they fail, users are thrown back to the Wild west condition of being unable to be sure any key belongs to anyone in particular, thus stopping protected communications abruptly and permanently until new certificates are obtained and published. The problem is not with the user's encryption/decryption which as you point out may be perfectly sensible and secure in practice, but with the system on which communication relies, namely an uncorrupted CA in a PKI system. Both are required for successful secure communication and either alone is insufficient.
I'll look into the article again to see whether something can be done to make clear the point to our Average Reader. ww ( talk) 00:23, 13 October 2008 (UTC)
<--
Failure to authenticate a piece of information does not invalidate that piece of information. Certificates exists precisely to avoid man in the middle attacks. They are independent of the security of the actual scheme, where public keys are assumed to be communicated through an authenticated channel. There is absolutely no reason to discard a key when a certifying authority of this key is compromised. I cannot see any theoretical or practical reason why one would wish to discard the key in this case. Skippydo ( talk) 06:18, 20 October 2008 (UTC)
The UK has a law ( Regulation of Investigatory Powers Act or RIPA) that requires you to either provide clear-text versions of encrypted data, or to provide a decryption key upon receipt of a "Section 49" notice. Recipients are also bound from telling anyone apart from their lawyer that they have been issued the notice. This power, whilst originally passed in 2000 was activated in 2007 [1].
Is it not possible for someone to decrypt data that has been encrypted with other people's public keys. To do so would require access to the other person's private key. It is therefore a problem to use public-key cryptography if you are not keeping a clear-text version of everything you encrypt.
For example: say you use a friend's public key to encrypt a message to him - say your bank details to repay you some money you lent him. There is no surrounding text on the message to make it clear what the message was about. 5 years go past. He has changed his keys in this time, or has moved away, or has died, or lost his private key for some reason. Should you ever be asked to tell the police what the message in my Outbox was about, or to provide a cleartext version, you would be unable to comply as you could never have decoded it. That gives you an automatic 2 year jail sentence.
This has not yet come to court, although it has started to be used by the police [2] - and not against al-Qaeda or child porn creators, either.
The analogy given: "In an asymmetric key system, Bob and Alice have separate padlocks. First, Alice asks Bob to send his open padlock to her through regular mail, keeping his key to himself. When Alice receives it she uses it to lock a box containing her message, and sends the locked box to Bob. Bob can then unlock the box with his key and read the message from Alice. To reply, Bob must similarly get Alice's open padlock to lock the box before sending it back to her."
is flawed in that it is subject to a man-in-the-middle attack. If a malicious third-party were to intercept Bob's open padlock in transit, and then sends their own open padlock to Alice, Alice will send her secret message back with the attacker's padlock, which the attacker can easily remove. Once the attacker has finished with the message, he can simply replace Bob's padlock on the message, and send it to Bob, who believes it has come from Alice untampered.
The second analogy with two different padlocks is also flawed:
"In another kind of asymmetric key system, Bob and Alice have separate padlocks. First, Alice puts the secret message in a box, and locks the box using a padlock to which only she has a key. She then sends the box to Bob through regular mail. When Bob receives the box, he adds his own padlock to the box, and sends it back to Alice. When Alice receives the box with the two padlocks, she removes her padlock and sends it back to Bob. When Bob receives the box with only his padlock on it, Bob can then unlock the box with his key and read the message from Alice."
The problem again lies in a third-party with their own padlocks. When Alice sends the message with her padlock to Bob, the attacker intercepts and places his own padlock on the box, and sends it back to Alice, who dutifully removes her padlock, and sends it off to the attacker, who can now unlock and read the message and possibly change it maliciously. Now, similarly, the attacker can send the box off to Bob with his padlock on it, and Bob, believing it to have come from Alice, places his padlock on it, and sends it off again. The attacker removes his padlock and sends it to Bob, who removes his padlock and reads the tampered message.
In both cases, the main problem is the fact that there is no verification of identity. Bob and Alice have no idea what the other's padlocks should look like, and even if they do, have no way to verify that it is in fact the senders.
I think these weaknesses should be detailed in the Weaknesses section, as there is no clear (from what I can see) expression of the weaknesses of the actual analogy. Sorry for the lengthiness, but I felt the analogies needed to be picked apart in detail.
Matwilko ( talk) 17:08, 9 March 2008 (UTC)
Another issue I see with the example is - when it says "First, Alice asks Bob to send his open padlock to her through regular mail, keeping his key to himself. When Alice receives it she uses it to lock a box containing her message". How is that possible, when Alice does not have the key, but only has the padlock Bob sent her. She cannot lock a box with only the padlock. I don't think the postal analogy holds true for asymmetric keys because its difficult to find a real life equivalent to the mathematical concept underlying this technology. —Preceding unsigned comment added by 17.227.143.125 ( talk) 20:35, 28 July 2009 (UTC)
In the security section, the following statement I think could use more elaboration: "To achieve authentication, non-repudiation, and confidentiality, the sender would first encrypt the message using his private key, then a second encryption is performed using the recipient's public key."
Namely, does it really matter which encryption is done first and which is done second? If if does, it would probably be good to add a sentence explaining why. If it doesn't, to add a sentence saying the actual ordering of the two encryptions is unimportant. —Preceding unsigned comment added by 70.17.114.124 ( talk) 20:19, 22 June 2008 (UTC)
This article contains a diagram showing the possibility of two parties each combining their own private key with the public key of the other party to yield a new shared secret. I assume that this is done without exchanging any messages (which would make it easy). I see that this is possible with some public key schemes (notably ElGamal), but I have no idea how (and honestly doubt that) it could be done with RSA for example. Could someone please give more information about this (in short: Citation needed)? —Preceding unsigned comment added by 141.3.32.141 ( talk) 08:36, 10 July 2008 (UTC)
<-- DG, I now understand the point you had in mind when you reverted. I agree with your comments above. What I disagree with is that the fourth image suggests what you think it does. I took it to mean concatenation of secret key with other material as that's what the image shows. Other processing, as you suggest would clearly be sensible, which is the import of the comment I added. I was trying for brevity and a note of caution. If we revise the image to suggest additional processing, I'd have no problem. With the image as it was, there is sufficient imprecision that it can lead to confusion. It certainly misled me, and I'm a little less credulous re crypto than the Average Reader can be expected to be. ww ( talk) 02:43, 22 July 2008 (UTC)
I have a problem with understanding this section so it appears to me that there's an error in writing. It says:
...in such [hybrid] cryptosystem, a shared secret key ("session key") is generated by one party and this much briefer session key is then encrypted by each recipient's public key. Each recipient uses the corresponding private key to decrypt the session key. Once all parties have obtained the session key they can use a much faster symmetric algorithm to encrypt and decrypt messages.
Now it appears to me that all an attacker may need is a public key from a recipient (which is public, therefore available) to gain the session key and break any security. Another thing which I can't understand is whether the session key is encrypted by all recipents' public keys combined or using a corresponding public key for each recipent (it only says "encrypted by each recipient's public key).
I hope you understand what I mean. -- Darko Maksimović ( talk) 13:16, 24 July 2008 (UTC)
The renaming of the category was not suggested by me and I disagree with the suggestion. I just report it here so more editors can join in the discussion. (Follow the "discussion" link in the box above if you want to discuss it.)
-- David Göthberg ( talk) 15:40, 2 August 2008 (UTC)
Category:Public-key cryptography is itself a category within Category:Cryptography. — Robert Greer ( talk) 15:34, 6 March 2009 (UTC)
I'm reading this article and the diagrams are nice and all, but they lack any description of how this works mathematically. How is it possible to encrypt with one key and decrypt with the other? A math section would add to this article.
I concur - without reducing to practice, the article devolves into hand waving. You can write an algorithm from any of the diagrams on: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation This article should achieve at least that depth. —Preceding unsigned comment added by 69.254.42.143 ( talk) 02:25, 19 January 2010 (UTC)
I'm having a problem with the following:
The first time I read this, it appeared to say that D & H's work was based on the GCHQ material. Following sentences clarify it, but what I'm looking for is a way of rewording the sentence so that it's referring to the the type of the inventions, rather than the specific work. How about, "...1970s; these inventions were {the same as, similar to} what later became known as..."? Since I'm not familiar enough with either work, I don't feel comfortable just plopping it in without checking with others.
GuiderBob ( talk) 20:21, 27 May 2009 (UTC)
I'm not exactly familiar with their work either. But it's safe to say that they were developed independently. I took a stab at rewriting the paragraph in question. Also, I moved it to the end so that it has a better context. Please tell me what you think. Skippydo ( talk) 02:09, 28 May 2009 (UTC)
Introduction needs to be rewritten for accessibility by nonspecialist readers, and to change from a description of behavior - "a form of cryptography in which" - to at least include a description of context - "a form of cryptography that". A nonexperienced person should be able to walk in and glean a concise and precise idea of what public-key cryptography is, what it is used for, to what end, in what media, and in what context as available; notwithstanding details, of course - that's what the body of the article is for.
I performed a total revamp of the summary, and I separated what was a very detailed working description from the summary into a section called "How it works". This section needs to be merged with the section "Description", preferably retaining the name "How it Works". The description is already covered by the summary (I hope). Stephen Charles Thompson ( talk) 22:03, 21 November 2009 (UTC)
"Asynchronous encryption" is not an accepted term for public-key cryptography, and does not appear in any literature. Perhaps it is a corruption of "Asymmetric cryptography," which is an accepted term, but the word "asynchronous" refers to a different concept entirely. Hashbrowncipher ( talk) 22:31, 23 February 2010 (UTC)
I've been making a few minor changes, but need clarification on this passage:
In contrast, symmetric-key algorithms, variations of which have been used for some thousands of years, use a single secret key shared by sender and receiver (which must also be kept private, thus accounting for the ambiguity of the common terminology) for both encryption and decryption [emphasis mine]
What common terminology is ambiguous? What "must also be kept private", just the key or something else, too? I'm going to take a stab at fixing this up, but please let me know or help out if I botch anything. Thanks! / ninly( talk) 21:29, 6 July 2010 (UTC)
The "How it works" section states that "each user has a pair of cryptographic keys—a public encryption key and a private decryption key". This makes it sound like public keys are only uses for encryption, and private keys are only used for decryption, which not the case for signatures. For years, I was confused on this point. The article needs to make it more clear that information encrypted with one key (which may either be the public key or the private key, depending on what you're trying to accomplish) may only be decrypted with the other key. —Preceding unsigned comment added by AndrewGarber ( talk • contribs) 04:18, 8 May 2011 (UTC)
Can someone explain why these systems are not completely compromised by simply reversing what ever process the 'public' key does to the message;thereby recreating the original plain text. The fact that the 'private' key cannot be determined from the 'public' key would seem to be completely irrelevant, since whatever the program does with the public key to encrypt the message could certainly be undone, using the 'public' key, by a program specifically written to do so. This has always seemed obvious to me and so must occur to others. An explanation of why this isn't (or is) a problem would seem beneficial to me. Danm60 ( talk) 17:39, 11 September 2010 (UTC)
Both the introduction to the article and the Weaknesses section addresses just this sort of an issue. It's possible to 'undo' it, but it's also computationally expensive. So expensive that in most circumstances, it's not even worth trying. Through some really, really complex mathematics, you get a function that is easy to perform in one direction, but incredibly hard to perform in the other direction. Gahread ( talk) 14:37, 22 September 2010 (UTC)
The same point occurred to me as to Danm60. I think I understand Gahread's reply (in principle!), but I don't think the explanation is at all clear in the existing article. The intro to the article says that 'it is extremely difficult for anyone to figure out the private key based on their knowledge of the public key', but this is not Danm60's (or my) concern. Intuitively, if the encrypted message is made using some algorithmic operation on the 'public' key, then it seems plausible that if one knows the message, the algorithm, and the public key, one can reverse the process and decrypt the message without first finding the 'private' key. I understand from Gahread's reply that this is in practice very difficult because of the nature of the algorithm, but I think the article itself could be clearer about this. 109.149.27.90 ( talk) 14:00, 6 September 2011 (UTC)
Given that all of this is difficult by intention, is it at all possible to give worked examples? Maybe by using a quite trivial pair of keys and a trivial trapdoor program? Old_Wombat ( talk) 10:12, 5 March 2011 (UTC)
If it is correct that,
then, this article must cite da Vinci! —Preceding unsigned comment added by 187.56.21.46 ( talk) 11:53, 10 March 2011 (UTC)
Just saw the same claim in the novel, and looked it up online, and unsurprisingly, it appears not to be true:
http://boards.straightdope.com/sdmb/showthread.php?t=272184
Electronwill ( talk) 06:07, 27 September 2011 (UTC)
There is a section titled Actual Algorithms - Two Linked Keys, but when going to that section there's yet another description of encryption by means of analogies, and certain nothing resembling an Actual Algorithm. Silas Maxfield ( talk) 09:26, 2 February 2012 (UTC)
Surely given all that is said in this article., the link to
http://gpg4win.org/documentation.html
is inappropriate. Far more suitable external links readily come to mind.
Please consider an edit to remove that link. G. Robert Shiplett 15:13, 15 June 2011 (UTC)