Talk:Public-key cryptography

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
WikiProject Cryptography / Computer science  (Rated C-class, Top-importance)
WikiProject icon This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the quality scale.
 Top  This article has been rated as Top-importance on the importance scale.
Taskforce icon
This article is supported by WikiProject Computer science (marked as Top-importance).
WikiProject Numismatics / Cryptocurrency  (Rated C-class, Low-importance)
WikiProject icon This article is within the scope of WikiProject Numismatics, a collaborative effort to improve the coverage of numismatics and currencies on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.
Taskforce icon
This article is supported by the Cryptocurrency task force (marked as Mid-importance).
edit·history·watch·refresh Stock post message.svg To-do list for Public-key cryptography:

Merge sections "How it Works" and "Description"

Physical keys are a bad metaphor[edit]

"There's one key to lock the box. And a different key to unlock it. And the message is the box."

Maybe magic wands would be more apt? — Preceding unsigned comment added by (talk) 05:07, 8 October 2014 (UTC)

How about an open padlock for the public key, since anyone you give it to can lock a message for your key to open? (The analogy's not perfect in the case of reusable keys, since you probably can't copy a padlock without being able to make a key for it, but it's better.) NeonMerlin 15:12, 24 June 2015 (UTC)
PKI is an entire system (infrastructure"), not just a device. The postal system might be a better analogy. Once you address a letter to me, seal the envelope, and put it into the system, the content is secure until it is delivered to me and I open it. Access to my mailbox is secure and publicly available from remote locations for anyone in the world to mail to me. That is security because the system releases control of the letter only when it is in my control. The postal system does not have authentication. But if it did, the service would require your ID when you mail a letter. I could be assured at my end when I received a letter "from" you that it really had been mailed by you. The only authentication I have these days is your signature on the same sheet of paper (or within the same envelope) indicating your hand has originated the sending. Grammar'sLittleHelper (talk) 08:36, 25 June 2015 (UTC)
@NeonMerlin: I think that is an excellent analogy. It makes it perfectly obvious why no one has to share their secret keys! (It also hints at the relationship between public-key encryption and one-way functions.) You should make the change. Norbornene (talk) 14:28, 10 September 2017 (UTC)

Digital signature is not ‘encryption with the private key’[edit]

The opening paragraph about signature schemes explains that digital signature is ‘encryption of a message digest with the private key’:

Message authentication involves hashing the message to produce a "digest," and encrypting the digest with the private key to produce a digital signature.

This is wrong on multiple levels.

  1. The only signature schemes where this is close to the truth are RSA-based ones. But the RSA private key operation, computing cube roots, or roots, modulo , is not encryption—it is just the private key operation, used differently in encryption schemes and in signature schemes. You can't take an RSA-based encryption scheme, such as RSAES-OAEP[1], exchange the public and private exponents, and get a signature scheme, any more than you can take an RSA-based signature scheme and make a secure encryption scheme. Other schemes, such as Victor Shoup's RSA-based encryption where the sender generates , computes , symmetrically encrypts a message with secret key , and then transmits , are even further from the design of a signature scheme.
  2. Even if you had an older RSA-based signature scheme that were more similar to a corresponding RSA-based encryption scheme, talk of ‘encryption with the private key’ encourages users to actually reuse key material between different applications, which leads to attacks such as Bleichenbacher's, enabling a decryption oracle to serve as a signature oracle or vice versa.
  3. The vast majority of signature schemes are not even this vaguely related to encryption schemes at all. For example, in EdDSA[2] with base point , a signature under public key on a message is a pair of a curve point and a natural number such that . (The signer, who knows the such that , computes , , and ; then ) There is nothing resembling ‘encryption with a private key’ or ‘decryption with a public key’ here.
  4. Only some signature schemes use a fixed message digest , e.g. MD5. These schemes are broken by collisions in —which has been well-documented to have been exploited for international industrial sabotage, by the Flame malware. Others, such as EdDSA, do not use a fixed message digest: an attacker cannot compute up front in order to search through possible values of for collisions.

These technical details may be inconsequential to the layman, but—aside from the confusion that the idea of ‘encryption with the private key’ tends to yield among a lay audience—the misconceptions that this article suggests lead newcomers to cryptography to dangerously wrong conclusions that may later entail major diplomatic incidents. I have seen even people who are likely to be judged experts in the field led astray by this confusion of ideas. So, after another novice asked a confused question arising from this article, I rewrote the paragraph to explain what meaningful properties a signature scheme would entail:

In a public key signature system, a person can combine a message with a private key to create a short digital signature on the message. Anyone with the corresponding public key can combine a message, a putative digital signature on it, and a known public key to verify whether the signature was valid—made by the owner of the corresponding private key. Changing the message, even replacing a single letter, will cause verification to fail: in a secure signature system, it is computationally infeasible for anyone who does not know the private key to deduce it from the public key or from any number of signatures, or to find a valid signature on any message for which a signature has not hitherto been seen. Thus the authenticity of a message can be demonstrated by the signature, provided the owner of the private key keeps the private key secret.

This edit was reverted. What do I need to do to persuade the Wikipedians watching this page to let this edit stand?

You make a compelling argument that this section should be changed. I reverted because I saw that several citations had been removed, but this may have been a mistake on my part as closer examination shows that they weren't germane to the central argument. To directly answer your question, the way to a Wikipedian's heart is to provide citations. In this case, because the section is in the introduction, citations would not be needed here provided there was an expanded treatment of the material in the body of the article that was fully backed up with reliable secondary sources. This reliance on secondary sources does imply that Wikipedia articles will never be at the cutting edge of technology; but this is a price that the community has decided it is willing to pay. --Bill Cherowitzo (talk) 05:59, 15 November 2016 (UTC)

So would you like to see citations in this paragraph, or is it OK as is on reflection? The body of the article is a bit voluminous for me to be comfortable reworking it—but I expect most readers won't go much past the opening paragraph, so I think what that says is more important. The Digital signatures article needs a lot of work too but generally reflects what my rewrite of the opening paragraph says. If you do want citations, how would you feel about these citations?[3][4]

Under the generalization that more citations can never hurt, I would put them in (they are fine in my opinion). If, and when, the treatment of digital signatures in this article gets expanded the issue can be looked at again and the references moved if that makes sense. Thanks for the work that you have put into this.--Bill Cherowitzo (talk) 17:25, 15 November 2016 (UTC)

OK, thanks. I've reapplied the change, with the citations added.

Hyphenation of the compound adjective formed by the words "public key"[edit]

Is there any reason why the use of the compound adjective "public key" isn't hyphenated in the article body when it leads a noun that it's modifying? The article title (and instances in the "Notes" and "References" sections) has the correct hyphenation (namely, public-key cryptography) whereas every instance in the article text is [incorrectly] devoid of a hyphen. --Jhfrontz (talk) 02:23, 12 May 2017 (UTC)

Security Section Needs Citations[edit]

The entire section has no inline citations, especially this sentence:

To achieve both authentication and confidentiality, the sender should include the recipient's name in the message, sign it using his private key, and then encrypt both the message and the signature using the recipient's public key.

It is not clear what adding the recipient's name achieves.

Furthermore under RSA, this "sign-then-encrypt" pattern does not seem possible given the length limitations imposed on the data that can be encrypted (e.g. with 2048-bit RSA the signature alone would be 2048-bits, already exceeding the allowed space for a payload which is always less than the 2048 bits because padding must be included). Am I missing something here? — Preceding unsigned comment added by (talk) 04:20, 17 October 2017 (UTC)

Non-standard use of the word "combined" confusing[edit]

First line 5th paragraph -

"In a public key signature system, a person can combine a message with a private key to create a short digital ..."

and subsequent usages. I have spent in the last 3 days about 10 hours trying to learn the concepts, nomenclature and digital entities underlying daily use of paired-key encryption. Nowhere have I found the word "combined" applied to any PKI method. Thus I don't have a clue what the above sentence means - the meaning of the word "combined" in this use case is unknown to me.

I am sorry, but I cannot offer any specific rephrasing or improvements to this article because I have not yet properly understood the subject myself. My credentials regarding this article are limited to having a college degree and 30 years experience setting up dozens end user computer systems. I have written half dozen user manuals for corporate computer systems and one for a course on Quicken taught nationwide at senior centers. I believe I _am_ qualified to say that this article is confusing, potentially very much so.

As a general recommendation: Utilize standard English in a manner such that one and only one word is used to reference a particular entity, method or concept AND that word is used with the same meaning as most accepted current texts. When attempting to teach a complex subject it is extremely counterproductive to use (even slightly) different words or phrases to reference the same thing within the curriculum. Aligning the local nomenclature with public common usage on a topic is also important and necessary.

In other words: Consistency, consistency, consistency. The topic itself is so challenging that it's imperative to remove as many other impediments to learning as we can. In this case, the richness of language which allows many different ways of expressing the same thing embodies a severe handicap to learning. Less (a limited vocabulary)is more (understandable), in the case of written learning material. — Preceding unsigned comment added by Rlaggren (talkcontribs) 17:39, 13 January 2018 (UTC)

External links modified (January 2018)[edit]

Hello fellow Wikipedians,

I have just modified one external link on Public-key cryptography. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

As of February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required on behalf of editors regarding these talk page notices, other than regular verification, as with any edit, using the archive tools per instructions below. This message updated dynamically through the template {{sourcecheck}} (last update: 1 May 2018).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 11:15, 20 January 2018 (UTC)

  1. ^ J. Jonsson and B. Kaliski. Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1. doi:10.17487/RFC3447. RFC 3447. 
  2. ^ Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang (2011-09-26). "High-speed high-security signatures". Journal of Cryptographic Engineering. 2 (77): 77–89. doi:10.1007/s13389-012-0027-1. Retrieved 2016-11-14. 
  3. ^ Alfred J. Menezes, Paul C. van Oorschot, and Scott A. Vanstone (October 1996). "11: Digital Signatures" (PDF). Handbook of Applied Cryptography. CRC Press. ISBN 0-8493-8523-7. Retrieved 2016-11-14. 
  4. ^ Daniel J. Bernstein (2008-05-01). "Protecting communications against forgery" (PDF). Algorithmic Number Theory. MSRI Publications. 44. §5: Public-key signatures, pp. 543–545. Retrieved 2016-11-14.