As you all know, plenty of X.509 Certificates use (PKCS#1 SHA1 with RSA encryption) as the Certificate Signature Algorithm for generating the signature of 2048 Bits long. We know that SHA1 hash function generates a hash value of 160 bits, so this makes the 2048 Bits Certificate Signature Value a combination of (160 bits + 1888 bits = 2048 Bits). My question is: From where do 1888 bits come from? Are they another a hash value or are they just padding?

Can someone briefly answer this question. If you also can provide me a source or a website to read more about it since I've been trying to find an answer of this one but I haven't gotten a good resource to explain this issue.

Thank you SO MUCH in advance :)


The 2048 Bits long field is a container for the results of the hash function. It is long enough to accept the results from a variety of hashing functions.

If the hash function used provides a result that is shorter than 2048, the hash value is padded as other answers have said.

Also note that you should no longer be using SHA-1. If you have US Government clients, then they are NOT allowed to use it. And no one else should be using it either.

In 2011, the US National Institute of Standards issued a regulation (see page 6) that states:

After December 31, 2013, key lengths providing less than 112 bits of security strength shall not be used to generate digital signatures.

(Emphasis is in the original.) This regulation applies to the US Government, but it is also common for non-government organizations/companies to follow it as an example of best practice.


Signature algorithms make use of a one way hash function (in this case SHA-1). The algorithm gathers the data to be signed (hash(message)), which is then signed using the RSA private key. This operation crates the signature value (e_priv(hash(certificate fields))), which is a bit string which you see included in the certificate signature field.

We aren't taking the SHA-1 output and adding it onto something to create the signature field, rather we're performing a signature on the hash output.

  • Thank you for your response. Bear with me because I still don't get the point why the signature is 2048 bits when we use SHA1. I fully understand the fact that we sign the hash value generated from the whole certificate using RSA private key. When we use SHA1 as a mechanism for generating the hash, it will produce only 160 bits according to the SHA1 standard. – Mike Feb 12 '14 at 0:53

Output size of RSA encryption always equivalent to RSA key size. In your case of Sha1RSA 2048 signing, 160 bit sha1 digest is padded as per PKCS#1 padding scheme in order make input block equivalent to RSA key size and then encrypted with RSA private key which results in 2048 bit signature.


The 1888 extra bits are mostly bytes of vale 0xFF.


It would be pretty pointless to just compute a hash (that everybody can compute) and then add a bunch of 1s. What would it prove ? The important part of RSA is the modular exponentiation; so that the signature is not at all "the hash and some 1888 extra bits". You cannot hope to understand RSA if you do not consider this exponentiation.

You may meditate the RSA PKCS#1 standard.


Larry>>SHA1 does not use a key. Signing is done with 2048 bits RSA, SHA1 is just used for Message Digest. If data is less than 2048 bits you get equal strength in the signature without SHA, just pad the data with FF, the strength of the signature is in the key-length not in the Message Digest process. Using SHA1 alone as a signing method is not recommended. Using 112 bits symmetrical keys are not recommended. Using 2048 bits RSA keys is still ok for signing and encryption.

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.