1
$\begingroup$

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?

Improve this question
$\endgroup$
6
  • 3
    $\begingroup$ 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. $\endgroup$
    – kelalaka
    May 6, 2020 at 20:05
  • $\begingroup$ @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? $\endgroup$
    – BobRodes
    May 6, 2020 at 21:14
  • $\begingroup$ @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. $\endgroup$
    – Crypto Learner
    May 6, 2020 at 22:11
  • $\begingroup$ @McFly Yes, I'm beginning to pick that up from reading. Thanks! $\endgroup$
    – BobRodes
    May 6, 2020 at 22:21
  • $\begingroup$ @McFly The first signature scheme, the Rabin Signature, include the hash then sign paradigm for the security proof. There the term is compression. $\endgroup$
    – kelalaka
    May 6, 2020 at 22:22

1 Answer 1

Reset to default
3
$\begingroup$

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.

Improve this answer
$\endgroup$
12
  • $\begingroup$ This answer needs to include the encrypted message since the OP asked. $\endgroup$
    – kelalaka
    May 6, 2020 at 21:33
  • $\begingroup$ 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? $\endgroup$
    – BobRodes
    May 6, 2020 at 21:39
  • $\begingroup$ 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. $\endgroup$
    – SAI Peregrinus
    May 6, 2020 at 21:46
  • 1
    $\begingroup$ @BobRodes that confuse come from the RSA, see Cornell's explanation RSA Signing is Not RSA Decryption $\endgroup$
    – kelalaka
    May 6, 2020 at 22:00
  • 1
    $\begingroup$ @BobRodes Yes, and OAEP could be much simpler if we have XOF ( eXtendable Output Function, see SHA3) during that time. $\endgroup$
    – kelalaka
    May 6, 2020 at 22:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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