1

This is how I understand digital signature verification to work in general:

  1. Plaintext gets run through a hashing mechanism to make a message digest (IBM's terminology, there appear to be plenty of other terms for the hashed data).
  2. Message digest is encrypted using sender's private key.
  3. Both encrypted message digest and plaintext are sent to recipient.
  4. Recipient decrypts message digest using sender's public key.
  5. Plaintext gets run through hashing mechanism to make message digest, as in step 1.
  6. If hashed plaintext and decrypted message digest are equivalent, test passes.

What I can't figure out is how this process is specifically applied in RSA verification of a digital certificate. I can't find the plaintext! If it's generated at random for each request, then what's the point of having a digital signature from the assigning CA in the certificate? If it isn't, then where does whoever is verifying the certificate get the plaintext to compare the signature to? I don't see that it's part of the certificate.

So, first, do I understand the general signature verification process as it applies to digital certificate verification? And if I do, can someone solve the "mystery of the missing plaintext" for me?

BobRodes
  • 113
  • 5
  • 3
    For 2. the correct terminology; the message is signed by the sender's signature key. And, the recipient verifies the signature with the signer's public key for signature. 4. ( you skipped the encryption) RSA is not used for encryption. Rather a hybrid Cryptosystem is preferred. Like, DHKE or RSA-KEM and use this key for AES encryption. RSA signature is secure either with RSA-FDH ( if the hash size equal to modulus) or RSA-PSS. – kelalaka May 06 '20 at 20:05
  • @kelalaka Thanks for responding. Correct terminology aside, is "signing by the sender's signature key" accomplished by encrypting using sender's private key (I understand that a signature key is distinct from an encryption key, but they are both certificate holder's private keys, right?), or is something different involved? Also, your response to 4 notwithstanding, where is the plaintext that gets hashed, and doesn't it get sent along for comparison purposes? – BobRodes May 06 '20 at 21:14
  • @BobRodes, to be rigorous, in a "digital signature" scheme, "in general," the hash component is not mandatory. It is there when we consider a specif paradigm: hash-then-encrypt. – Crypto Learner May 06 '20 at 22:11
  • @McFly Yes, I'm beginning to pick that up from reading. Thanks! – BobRodes May 06 '20 at 22:21
  • @McFly The first signature scheme, the Rabin Signature, include the hash then sign paradigm for the security proof. There the term is compression. – kelalaka May 06 '20 at 22:22
  • @kelalaka, that is interesting. Thank you for sharing! – Crypto Learner May 06 '20 at 23:07

1 Answers1

3

Lets fix that description of the signature generation. Please read the PKCS#1 v2.2 specifications to get the full detail.

  1. Canonical binary plaintext gets run through a hashing mechanism to make a message digest (IBM's terminology, there appear to be plenty of other terms for the hashed data).
  2. Message digest is used as input for the configured padding mechanism.
  3. Binary padded message digest is converted to a number.
  4. Number is raised to the power of the private exponent modulo the modulus, either directly or using the Chinese Remainder Theorem.
  5. The number is converted back to binary with the same byte size as the modulus, giving the signature.
  6. Both the plaintext and generated signature are sent to recipient.

As you can see I had to rewrite most of it. The modular exponentiation is commonly seen as the "encryption with private key part", but that's a contradiction in itself; it is just a similar operation and PKCS#1 v2 goes out of the way to explain that. For more information, see my Q/A here.

What I can't figure out is how this process is specifically applied in RSA verification of a digital certificate. I can't find the plaintext!

The certificate contains a to be signed (TBS) part. This can be found in the X.509v3 standard. This is the plaintext in above signature generation scheme:

The signatureValue field contains a digital signature computed upon
the ASN.1 DER encoded tbsCertificate.  The ASN.1 DER encoded
tbsCertificate is used as the input to the signature function.  This
signature value is encoded as a BIT STRING and included in the
signature field.

If it's generated at random for each request, then what's the point of having a digital signature from the assigning CA in the certificate? If it isn't, then where does whoever is verifying the certificate get the plaintext to compare the signature to? I don't see that it's part of the certificate.

It's just data, there are no pointers as in: here is the plaintext within the binary or textual description.

So, first, do I understand the general signature verification process as it applies to digital certificate verification? And if I do, can someone solve the "mystery of the missing plaintext" for me?

Sure see above. But most of this is best found out by reading the standard documents. If you had done that then the mystery would not have existed.

Community
  • 1
Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313
  • This answer needs to include the encrypted message since the OP asked. – kelalaka May 06 '20 at 21:33
  • Thank you! So, my "missing plaintext" is the "ASN.1 DER encoded tbsCertificate"? For example, using this page, in *.stackexchange.com's Public Key Info area, the "Signature" field is "Let's Encrypt Authority"'s ASN.1 DER encoded tbsCertificate, encrypted (i.e. signed) using Let's Encrypt's (private) signature key? – BobRodes May 06 '20 at 21:39
  • You're still conflating encryption and signing. They're similar mathematical operations for RSA, but they are different and produce different results. Encryption IS NOT signing. – SAI Peregrinus May 06 '20 at 21:46
  • @SAIPeregrinus I do understand that they are different. I'm just working on building an understanding of the terminology involved. I read "signing" as synonymous with "encrypting using a private key," where the signature is decrypted using the public key. Encryption, so-called, uses the public key to encrypt and the private key to decrypt. Is this correct as far as it goes, or am I missing something? – BobRodes May 06 '20 at 21:53
  • 1
    @BobRodes that confuse come from the RSA, see Cornell's explanation RSA Signing is Not RSA Decryption – kelalaka May 06 '20 at 22:00
  • @kelalaka Thanks, that's helpful. So, in a theoretical sense, what I'm saying is basically true, but not so for any practical implementation of the process, since the OAEP pre- and post-processing that encryption uses differs entirely from the hashing process that signing uses prior to applying the private key encryption. Is that about correct? – BobRodes May 06 '20 at 22:17
  • 1
    @BobRodes Yes, and OAEP could be much simpler if we have XOF ( eXtendable Output Function, see SHA3) during that time. – kelalaka May 06 '20 at 22:20
  • @kelalaka Ok, good. Thanks for your input. – BobRodes May 06 '20 at 22:23
  • Maarten, I got lost in the docs. Thanks for pointing me to the right place. I think I have it now. – BobRodes May 06 '20 at 22:47
  • If you don't get the right hash then you may need to re-encode a tag somewhere (some tags are IMPLICIT, which means that they can represent a SEQUENCE even if they don't contain that tag number (0x8X -> 0x30). ASN.1 has hidden treasures like that. If you're satisfied with the answer then don't forget to accept! – Maarten Bodewes May 07 '20 at 16:24
  • I think I have it, yes. My "missing plaintext" is the subject's tbsCertificate field. Also, the answer to my question in the comments above is "no." Rather, using this page, the "Signature" field is stackexchange.com's ASN.1 DER encoded tbsCertificate (not Let's Encrypt's), signed with Let's Encrypt's signature key. Of course, the CA signs the subject's certificate, not its own (unless it's a root CA, in which case it is both subject and issuer). Thanks for pointing me in the right direction. – BobRodes May 07 '20 at 19:14
  • "If you had done that then the mystery would not have existed." You underestimate my capacity for self-obfuscation. :) – BobRodes May 07 '20 at 19:19