## Overview#

The big thing to keep in mind with RSA in the real world is that all of the numbers involved have to be big to make things really hard to break using the best algorithms that we have.How big? We will look at our Example Certificate which was "signed" by "VeriSign Class 3 Secure Server CA."

From the Example Certificate, we see that this VeriSign Certificate Modulus n is 2048 bits long which has this 617 digit base-10 representation:

1890572922 9464742433 9498401781 6528521078 8629616064 3051642608 4317020197 7241822595 6075980039 8371048211 4887504542 4200635317 0422636532 2091550579 0341204005 1169453804 7325464426 0479594122 4167270607 6731441028 3698615569 9947933786 3789783838 5829991518 1037601365 0218058341 7944190228 0926880299 3425241541 4300090021 1055372661 2125414429 9349272172 5333752665 6605550620 5558450610 3253786958 8361121949 2417723618 5199653627 5260212221 0847786057 9342235500 9443918198 9038906234 1550747726 8041766919 1500918876 1961879460 3091993360 6376719337 6644159792 1249204891 7079005527 7689341573 9395596650 5484628101 0469658502 1566385762 0175231997 6268718746 7514321(Good luck trying to find "p" and "q" from this "n" - if you could, you could generate real-looking VeriSign certificates.)

VeriSign's e is 2^16 + 1 = 65537.

Of course, they keep their d value secret. Before signing, VeriSign checked the validity of the contents that Example Certificate claimed on its certificate using a real-world "handshake" that involved looking at several of the requester's business documents. Once VeriSign was satisfied with the documents, they used the SHA-1 Cryptographic Hash Function to get a Hash value of the Certificate that had all the claims. In Wireshark, the full certificate shows up as the "signedCertificate" part, which sort of a misnomer since it actually means that those are the bytes that the signer is going to sign and not the bytes that already include a signature.

The actual signature, S, is simply called "encrypted" in Wireshark. If we raise S to VeriSign's Public Key Certificate Exponent of 65537 and then take the remainder when divided by the modulus "n", we get this Decrypted signature HEX value:

0001FFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF FFFFFFFF00302130 0906052B0E03021A 05000414C19F8786 871775C60EFE0542 E4C2167C830539DB

Per the PKCS #1 v1.5 standard in RFC 2313 page-9,

- the first byte is "00" and it "ensures that the encryption block, when converted to an integer, is less than the modulus."
- The second byte of "01" indicates that this is a Private Key operation (e.g. it's a Digital Signature).
- This is followed by a lot of "FF" bytes that are used to pad the result to make sure that it's big enough.
- The padding is terminated by a "00" byte.
- It's followed by "30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14" which is the PKCS #1 v2.1 way of specifying the SHA-1 hash algorithm.
- The last 20 bytes are SHA-1 Hash digest of the bytes in "signedCertificate."

Since the Decrypted value is properly formatted and the last bytes are the same Hash value that we can calculate independently, we can assume that whoever knew "VeriSign Class 3 Secure Server CA"'s Private Key "signed" it. We implicitly trust that only VeriSign knows the Private Key "d."

We can repeat the process to verify the rest of the Certificate Chain. Which implies that "VeriSign Class 3 Secure Server CA"'s certificate was signed by VeriSign's "Class 3 Public Primary Certification Authority."