I'm a bit new to security and trying to get the concepts properly.

I'm wondering what exactly "signing" a file (a certificate, an apk file, or something else) means?

  1. Do we sign the whole file so it becomes sort of encrypted?
  2. Is there like a piece of plain text that we sign and pass it through, for example, a zip, and let the receiving side checks that piece based on a particular protocol before going any further?
  3. Or something else?

As far as I can see, if we sign the whole file, then it can be more secure as the contents would be encrypted (or signed). But I've also seen/heard some examples in where you only sign a piece of text instead of the whole thing.

Any ideas would be greatly appreciated.

PS: I've already checked What does key signing mean?

  • 8
    "key signing" is not useful for your understanding. "Digital signature" is what you are asking about.
    – schroeder
    Commented Nov 26, 2018 at 13:25
  • 6
    Have you read a wiki or some other source? en.wikipedia.org/wiki/Digital_signature
    – schroeder
    Commented Nov 26, 2018 at 13:29
  • 2
    A file signing process will attach fingerprint data that the recipient can use to verify that the file haven't been tampered with. It is just instill level of trust but doesn't guarantee that the file is safe.
    – mootmoot
    Commented Nov 26, 2018 at 15:31
  • 1
    "But I've also seen/heard some examples in where you only sign a piece of text instead of the whole thing." Do you have any links or references to such things? That seems like an awfully strange thing to do. Commented Nov 27, 2018 at 6:34
  • 2
    @DavidSchwartz In APIs, it's common to sign key pieces of the request, plus a timestamp and nonce, because a) it reduces the risk of transfer encodings invalidating the signature; and b) it removes a catch-22 where you need to place the signature inside the request, but need to generate the complete request before you can sign it.
    – IMSoP
    Commented Nov 27, 2018 at 14:45

6 Answers 6


Unfortunately, the answers here which claim that signing is equivalent to encryption of the message digest are not entirely correct. Signing does not involve encrypting a digest of the message. While it is correct that a cryptographic operation is applied on a digest of the message created by a cryptographic hash algorithm and not the message itself, the act of signing is distinct from encryption.

Taken from https://www.cs.cornell.edu/courses/cs5430/2015sp/notes/rsa_sign_vs_dec.php:

In the abstract world of textbooks, RSA signing and RSA decryption do turn out to be the same thing. In the real world of implementations, they are not. So don't ever use a real-world implementation of RSA decryption to compute RSA signatures. In the best case, your implementation will break in a way that you notice. In the worst case, you will introduce a vulnerability that an attacker could exploit.

Furthermore, don't make the mistake of generalizing from RSA to conclude that any encryption scheme can be adapted as a digital signature algorithm. That kind of adaptation works for RSA and El Gamal, but not in general.

Creating a digital signature for a message involves running the message through a hash function, creating a digest (a fixed-size representation) for the message. A mathematical operation is done on the digest using a secret value (a component of the private key) and a public value (a component of the public key). The result of this operation is the signature, and it is usually either attached to the message or otherwise delivered alongside it. Anyone can tell, just by having the signature and public key, if the message was signed by someone in possession of the private key.

I'll use RSA as an example algorithm. First, a little background on how RSA works. RSA encryption involves taking the message, represented as an integer, and raising it to the power of a known value (this value is most often 3 or 65537). This value is then divided by a public value that is unique to each public key. The remainder is the encrypted message. This is called a modulo operation. Signing with RSA is a little different. The message is first hashed, and the hash digest is raised to the power of a secret number, and finally divided by the same unique, public value in the public key. The remainder is the signature. This differs from encryption because, rather than raising a number to the power of a known, public value, it's raised to the power of a secret value that only the signer knows.

Although RSA signature generation is similar to RSA decryption on paper, there is a big difference to how it works in the real world. In the real world, a feature called padding is used, and this padding is absolutely vital to the algorithm's security. The way padding is used for encryption or decryption is different from the way it is used for a signature. The details which follow are more technical...

To use textbook RSA as an example of asymmetric cryptography, encrypting a message m into ciphertext c is done by calculating c ≡ me (mod N), where e is a public value (usually a Fermat prime for efficiency reasons), and N is the non-secret product of two secret prime numbers. Signing a hash m, on the other hand, involves calculating s ≡ md (mod N), where d is the modular inverse of e, being a secret value derived from the secret prime numbers. This is much closer to decryption than it is to encryption, though calling signing decryption is still not quite right. Note that other asymmetric algorithms may use completely different techniques. RSA is merely a common enough algorithm to use as an example.

The security of signing comes from the fact that d is difficult to obtain without knowing the secret prime numbers. In fact, the only known way to obtain d (or a value equivalent to d) from N is to factor N into its component primes, p and q, and calculate d = e-1 mod (p - 1)(q - 1). Factoring very large integers is believed to be an intractable problem for classical computers. This makes it possible to easily verify a signature, as that involves determining if se ≡ m (mod N). Creating a signature, however, requires knowledge of the private key.

  • 6
    because I think it's "not useful" (by the downvote tooltip wording). I think it won't answer OP's beginner level questions, and your point isn't clearly explained or justified. In what way is the second equation closer to decryption, and why is that a relevant part to single out and focus on? Why then a link which says it isn't decryption, if you're trying to be strictly correct? Changing @Lithilion's answer to say "processes only the hash" would make it less incorrect, but simple enough to be useful to OP. Commented Nov 27, 2018 at 3:07
  • 1
    @TessellatingHeckler Unfortunately, sometimes you get a lot of incorrect answers with confusing comments and even upvotes to what should be a simple question. In that case, it's very hard to produce a simple answer that explains what's wrong with the apparently simple answers. Commented Nov 27, 2018 at 6:38
  • 1
    @HenkHolterman No, you couldn't. The size of the message itself is limited. I suppose you could break up a message into multiple chunks and sign them individually, but just like you can't encrypt a large value, you can't sign a large value. Public key encryption is quite different from symmetric encryption.
    – forest
    Commented Nov 28, 2018 at 5:37
  • 1
    @DavidSchwartz I used RSA as an example not only because it is extremely common, but because it is easy to understand (I am so not going to try to explain how elliptic curve signatures work). However, I linked to and quoted content which explained that algorithms based on IFP and DLP like RSA and El Gamal (or DSA) are unique in that respect to try to avoid misconceptions. Do you have any suggestions?
    – forest
    Commented Nov 28, 2018 at 5:39
  • 1
    @Luc Your original understanding is still incorrect. RSA-PKCS#1v1.5 is a special kind of signature that allows recovery: you can find the hash of the message from the signature value. A signature with recovery looks superficially similar to encrypting the hash, but has different security properties. You should have a look at how other common signature schemes work, the most common one being ECDSA. ECDSA does not allow recovery and is not even superficially similar to “encrypting” with the private key. Commented Dec 15, 2018 at 14:23

Signing a file does not encrypt it. When Alice signs a file she usually signs the whole file. So she calculates a hash of the whole file and signs only the hash with her private key and attaches this piece of information to the file.
Bob uses her public key to verify it and gets her calculated hash. He then calculates the hash of the file himself (without the signature of course) and checks both hashes. If they match its the same exact version of the file Alice sent. If they don't match Mallory could have changed it.

The file itself never gets encrypted, and of course you can just remove the signature, but then it's not signed anymore (and therefore worthless).

For more technical and detailled information please refer to forests answer: https://security.stackexchange.com/a/198473/191453

  • 9
    @zgulser it depends on the file format and/or protocol. You can even have signatures of the files as a separate files.
    – Hauleth
    Commented Nov 26, 2018 at 17:15
  • 15
    -1 This is completely incorrect. Signing a hash is not the same as encrypting a hash.
    – forest
    Commented Nov 27, 2018 at 0:28
  • 5
    @forest You're trying to be pedantic by arguing semantics, but from a pedantic standpoint you're incorrect. "Encrypt using the private key" is the correct phrasing - "decrypt before encrypt" only works if encryption/decryption are commutative, which is true for RSA but not for other asymmetric schemes. Commented Nov 27, 2018 at 0:45
  • 8
    @BlueRaja-DannyPflughoeft This is not semantics, this is cryptography. The operation of signing is distinct from the operation of encrypting, not only for RSA but for all other cryptosystems as well. Note that it is even more distinct when you are using real-world RSA with padding and not textbook RSA. In particular, encryption, by definition, raises a message to the power of e, modulo a public composite number (N), where e is a public exponent. The public key is also defined as the tuple e,N.
    – forest
    Commented Nov 27, 2018 at 0:53
  • 8
    @forest I'm not even sure what you're objecting to. Is it that the answer here uses the phrase "...uses her public key to decrypt it"? Is your entire argument here that the act of recovering the signer's hash using their public key does not constitute a "decryption" (or, by extension, that signing the hash does not produce an output one can call an "encryption" of the original hash)?
    – J...
    Commented Nov 27, 2018 at 13:13

Of course one can choose to sign any (part of) information one wants, and leave other parts unsigned. But usually, when we say "sign a file", we refer to signing the whole file plus the file meta-data (e.g. file modification timestamp). This is how OpenPGP and GPG work.

But, if it is not a file, say it is XML signing, you must specify which parts of the XML content are actually covered by the signature.

Also, try to differentiate signatures from encryption. These are two independent matters. One file can be unencrypted+signed, or encrypted+unsigned, or any other combination.

  • If I sign the whole file, then that means receiving party cannot access it (or it's content) till it's verified by the corresponding public key, right?
    – zgulser
    Commented Nov 26, 2018 at 16:13
  • 4
    @zgulser Wrong... in general. Signing a file (in general) does not alter the file being signed (other protocol layers could do this at roughly the same time, but it is not required). A "pure" signing process would leave "the data that was signed" (untouched) and "an encrypted signature of that data" (that proves you signed the data).
    – TripeHound
    Commented Nov 26, 2018 at 16:25
  • 2
    Signing a file means that you produce a signature, which stands separately from the file itself. The receiving party may validate the signature to verify that the file is indeed coming from you and in this case he/she needs the key. But, he/she may well choose to ignore the signature.
    – papajony
    Commented Nov 26, 2018 at 16:29
  • Try to think of the signature in terms of a paper document with a human signature at the bottom. You examine the signature (validate it) to ensure that the document content was indeed produced by the sender. But you may choose to accept the document, without caring about the signature. But why would you want to do this? The signature is there to give you a means of identifying that the document (or file) are authentic.
    – papajony
    Commented Nov 26, 2018 at 16:31
  • 2
    Well, you have different types of signatures. You can bundle together the file+signature in one, or you can have a separate signature file (so called a detached signature).
    – papajony
    Commented Nov 26, 2018 at 16:42

Signing a file, or more generally signing some content (an email message, the body of an email message, a subtree of an XML document, a portion of a certificate, a TLS handshake, etc.), means to create a sequence of bytes which is called the signature. This process has certain properties:

  • There is a method for verifying the signature. Verifying the signature gives a boolean result, either “this is a good signature of the file” or “this is not a good signature of the file”.
  • A good signature for a file is never a good signature for a different file. Therefore a good signature guarantees that the file is authentic. Authenticity, in security, means that some data really comes from where it's supposed to come from.
  • There is a secret value called a private key or secret key. It is impossible to create a good signature of a file if you don't know that secret value.
  • In a public-key scheme, there is a value associated with the private key which is called the public key. If you know the public key, you can verify signatures, but you can't create a signature of a different file.

It's important to know that anybody can sign a file, but they can only sign it with their own private key. You can't sign a file with somebody else's private key unless you somehow manage to get hold of the private key, for example by hacking their computer. So knowing that a file comes with a good signature doesn't say anything: what's important is to know that it has a good signature made with the expected private key. This means that the verifier must know the public key in advance. If the public key is transmitted alongside the signature and the message, it doesn't prove anything in itself, but it can be useful if there is some mechanism to allow the verifier to verify the public key. Such a mechanism is called a _public key infrastructure. In other words, the signature operation turns a promise of confidentiality of the private key, and a promise of authenticity of the public key, into a guarantee of authenticty of the file.

A signature generally means “I approve of this content”. What “approve” means depends on the context. For example:

  • When Microsoft distributes a Windows update that is signed with Microsoft's Windows update signature key, the signature means that this particular code update has been approved by Microsoft. If someone wants to distribute malware and pass it off as a Windows update, they won't be able to create a good signature for it, and so the Windows update application will reject the update.
  • If you receive a mail that is signed, it means that it was really written by the person who signed it (or that their machine was compromised). You don't get this guarantee from the From: line of an email in general because anybody can write whatever they want there. (Some distribution systems make it harder, but in general on the Internet there's no way to prevent people from writing whatever they want in the From: line.)
  • When a certificate authority signs a certificate, what they are saying is that they have verified that the owner of the domain name listed in the certificate is the owner of the private key for which the corresponding public key is in the certificate. This kind of statement associating a name with a public key is the basis of public key infrastructures.
  • When a TLS server signs the handshake of a TLS connection, it allows the client to verify that they are who they claim to be. Anyone can sign a TLS handshake, but only Google can sign a TLS handshake with the public signature for google.com.

The signature is a separate piece of data. It can be bundled in a zip file along with the signed data, added as an attachment to an email, added to an XML file as a separate node, etc. In a certificate, the signature bundled alongside the signed data. In a TLS handshake, the signature is a separate part of the messages sent by the server.

Do we sign the whole file so it becomes sort of encrypted?

No. The signature depends on the content of the file, but you can't recover the content of the file from the signature. The content needs to be transmitted alongside the signature. The content can be encrypted, but that's independent from signing it.

Is there like a piece of plain text that we sign and pass it through, for example, a zip, and let the receiving side checks that piece based on a particular protocol before going any further?

Yes, exactly. The sender passes the file content (the zip or text or whatever) to sign and the private key to the signature function, and gets the signature out. (The word “signature” can refer to either this process or to the output of this process.) The recipient passes the content and the public key to the verification function, and gets a result “it's good” or “it's bad”. Generally the recipient refuses to do anything with the content if the signature is bad.

As far as I can see, if we sign the whole file, then it can be more secure as the contents would be encrypted (or signed).

Signing something doesn't encrypt anything. Signing the whole file is more secure than signing part of a file in the sense that the signature only gives you some security about the part that is signed. If you sign part of a file then the unsigned part could be anything.


It is similar to give your product(files) a laser anti-counterfeiting label, to let others receiver(buyer) have more confident in quality, When receiver(buyer) see a signiture as real genuine certificate.

  • The question is not asking about why to sign, but what signing means technically. Your analogy is too vague and non-descript to be a helpful answer.
    – schroeder
    Commented May 30, 2022 at 19:57

In the most general sense, "signing" in this context means a process that depends on the text and some secret knowledge in such a way that anyone with access to the text and secret knowledge can create the output, and anyone given the text and the output can verify that the output is correct, but it is infeasible for anyone who doesn't have access to the secret knowledge to independently produce the correct output.

One method of doing this is using public key encryption, which is a system in which there are two keys and a cryptographic process such that applying the cryptographic process with one key, then taking the result and applying the cryptographic process with the other key, results in the original input. One of these keys is publicly distributed, and known as the "public key", and the other key is kept secret, and is known as the "private key".

When used to restrict access to information, which is what “encryption” generally refers to, public key encryption consists of the sender using the recipient’s public key on the file, and the recipient uses their private key on their result; thus, only the intended recipient can read the file. Signing can be accomplished by having the sender use their private key, and the recipient using the sender’s public key. Thus, while in the first case only the recipient can read the file (since only they have their private key), in the second case only the sender can send the file (since only they know their private key). In the first case, everyone can write, but only one can read, while in the second case, only one person can write but everyone can read.

If just the result from using the sender’s private key is sent, then everyone will have to get the sender’s public key to read the file. So often the original file is sent as well, so that people can read it without going through that process. But since sending both the file and the result of applying the cryptographic process to the whole file means sending twice as much data as just the file, a hash is usually used to decrease the size of the signature. This can be done by hashing the file and then signing the hash (and then the recipient can hash the file and apply the cryptographic process with the public key to the hashed file, and see if that matches the signed hash that was sent).

Although signing a file, verifying a signature, and encryption can all use the same cryptographic process, the term "encryption" is primarily used refer specifically to when this process is used to keep other people from reading the file, rather than for authentication. If we're applying the process for secrecy, then we send only the result, as we don't want unauthorized people to have access to the plaintext. If we're authenticating, we send both so that the recipient can check that they match.

If a sender wants only the intended recipient to be able to read a file, then the sender can encrypt as a separate process. So how that would work is that the sender would hash the file, apply their private key to the result, append that result to the file, then apply the recipient's private key to the file+signature, and then send that to the recipient. Thus, the recipient would get message=recipient.public(file+sender.private(hash(file)). The recipient would then apply their private key to the message, hash the original file part of the result, and check whether that matches the sender's public key applied to the signature:

hash((recipient.private(message)).file) == sender.public((recipient.private(message)).signature)


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .