2

I have gone over:

I am new to cryptography and security. I am trying to understand the point of self-signed certificates.

I understand the point of certificates as a means to distribute the public keys where a trusted CA (issuer) "signs" (=>encrypts) the public key of the subject and the client that trusts this CA uses the public key of the issuer (CA) to decrypt (un-sign) the certificate and get the public key of the subject (server). I have understood this from Data Communication and Networking by Behrouz.A.Forouzan 4th.edition Page 987. enter image description here

Now, if my understanding is right, how do I extend this logic to a self-signed certificate! If the subject matches the issuer and the overall purpose for the client is to obtain the public key of the subject (server), how does the client decrypt (un-sign/open) the certificate using the public key of the issuer to get the public key of the subject as the public key of the issuer is the public key of the subject? How does the client get the public key of the subject (server) that it ultimately wants to establish an SSL session with?

The fact that this question has not been asked anywhere tells me that there must be something really basic that I have not understood. Please help me in understanding this.

8
  • 1
    The certificate is not encrypted, it is signed. That is, it has a huge block of plaintext, followed by a checksum that can only be generated from the private key, and can be verified from the public key. – Ghedipunk Jul 13 '20 at 17:19
  • 1
    You use signing and encrypting as if they were synonyms. However, they are 2 different concepts. Also, the concept of "un-signing" does not exist. I guess that you mean signature verification. – lab9 Jul 13 '20 at 17:19
  • I have uploaded a snap of why this was confusing me thus far..The text and the corresponding diagram from the book gives me a hint of encryption and signing being synonyms. – Sheel Pancholi Jul 13 '20 at 17:26
  • 1
    That latest edit certainly helps to explain why you have the idea that you do.—That snippet is as technically correct and as useless as saying "A hard drive's head is read by its head." There is subtle jargon here that is best to ignore until you learn more. For now, forget that anyone equates signing to encrypting, unless you're doing the maths yourself. Signing is generating a snippet that goes at the end of your (otherwise fully plaintext) document, that can only be created by the private key, but that can be verified by the public key. – Ghedipunk Jul 13 '20 at 17:30
  • Alright..thank you – Sheel Pancholi Jul 13 '20 at 17:34
1

A few major misunderstandings here.

First of all, that book is just wrong. Signing is not a form of encryption, nor verifying a form of decryption. In the specific case of RSA, signing is mathematically the equivalent operation to "encrypt with the private key", but this is more a coincidence than an inherent property of digital signatures. Some digital signature algorithms don't support actual encryption at all! (DSA and ECDSA being the obvious ones.) Conceptually, the two operations (sign vs. encrypt) are used very differently, and practically there are many considerations for an implementer (padding, length, etc.) that apply to one operation but not the other, even for RSA.

Second, signing is never done in a way conceals the original message. This may be another way that book is misleading you: all signing operations, conceptually, take two inputs (a message and a private key) and produce one output (a short-ish string / huge number that is meaningless without the original message). The inputs - including the message - are not modified. Usually the actual operation of signing can only be done on a short piece of data, so the message is cryptographically hashed first (this is usually done automatically by the crypto toolkit when you say "sign M with K"), but some algorithms instead work on the whole message and internally are doing something akin to hashing while also producing the signature. From the user's perspective, this is still "sign M with K", just for a key K used with a different digital signature algorithm.

In any case, the practical output of a signing operation is that now you have two pieces of data - the message M and its signature S - in addition to your private and public key pair. Anybody with M, S, and the public key can verify that S was created from M using the corresponding private key if neither of M or S are modified, so of course you have to distribute M and S unchanged. Note that S is usually much smaller than M, and it is conceptually impossible to extract M from S.

Now, in practice, signing is often (not always!) used with encryption. When encrypting, you do modify M - or at least, you produce C, the ciphertext of M, and keep M secret - and then either the recipient must decrypt C (to get M) before they can verify the signature S, or you sign the encrypted message C rather than signing the plain text M and thus your S is verified against C not against M. Nothing in this paragraph is relevant to certificates, because certificates do not have any encryption!


With those cleared up, hopefully you understand why the question is trivial. A certificate consists of (arguably) four parts: data about the cert (when it was issued, by whom, for how long, for what purposes), data about the subject (who the cert is issued to), the subject's public key, and the issuer's signature of the previous three parts. The first three parts are plain text, and the last - the signature - is meaningless without that plain text.

So, you extract the public key from a self-signed certificate - or any other part, from any certificate - by parsing the certificate structure and reading the relevant part of the certificate (the one that contains the public key). That's it. The act of signing does not, and must not, modify any part of the certificate (except the part where the signature itself is stored).

0

I believe the confusion is coming from some oversimplifications on the quoted diagram. Let me refer to what you have highlighted in red.

Asymmetric cryptography relies on a pair of keys:

  • private key, which is known only to the owner
  • public key, which the owner is free to distribute

Asymmetric keys can be used for signing/signature verification or encryption/decryption.

Signing

For signing, owner of the private key uses this key to sign the message. For signature verification, anyone with access to the message and the public key can use this key to verify the signature.

Encryption

For encryption, whoever has access to the public key can encrypt the message. Due to the nature of asymmetric cryptography, only the recipient, aka the person who owns the private key, will be able to decrypt it using their private key.

Conceptually, signing and decryption are similar in a sense that both use private key.

One thing worth pointing out is that signing and decryption are more closely aligned in the plain RSA meaning, where basic RSA is used as-is. Which I don't think is the case in modern software any more. More often you'll come across encryption schemes like RSA-OAEP or signing like RSA-PSS, which build on top of plain RSA to provide additional security. In which case saying that signing and decryption are the same, or signature verification and encryption are the same, is even more incorrect.

3
  • "whoever has access to the public key can sign the message" s/sign/encrypt/ – Z.T. Jul 13 '20 at 17:43
  • "Conceptually, signing and encryption are similar in a sense that both use private key." s/encryption/decryption/ – Z.T. Jul 13 '20 at 17:43
  • Many thanks for pointing out cut&paste mistakes. I corrected the answer. – automatictester Jul 13 '20 at 17:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.