What does “signing” a file really mean?
up vote
11
down vote
favorite
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?
- Do we sign the whole file so it becomes sort of encrypted?
- 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?
- 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?
certificates digital-signature
New contributor
add a comment |
up vote
11
down vote
favorite
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?
- Do we sign the whole file so it becomes sort of encrypted?
- 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?
- 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?
certificates digital-signature
New contributor
6
"key signing" is not useful for your understanding. "Digital signature" is what you are asking about.
– schroeder♦
13 hours ago
4
Have you read a wiki or some other source? en.wikipedia.org/wiki/Digital_signature
– schroeder♦
13 hours ago
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
11 hours ago
The accepted answer is unfortunately incorrect. For RSA at least, signing is closer to decryption of a hash than encryption of it, though that's still dangerously incorrect. This is a common misunderstanding.
– forest
1 hour ago
add a comment |
up vote
11
down vote
favorite
up vote
11
down vote
favorite
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?
- Do we sign the whole file so it becomes sort of encrypted?
- 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?
- 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?
certificates digital-signature
New contributor
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?
- Do we sign the whole file so it becomes sort of encrypted?
- 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?
- 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?
certificates digital-signature
certificates digital-signature
New contributor
New contributor
edited 4 hours ago
The Guy with The Hat
20012
20012
New contributor
asked 14 hours ago
zgulser
1675
1675
New contributor
New contributor
6
"key signing" is not useful for your understanding. "Digital signature" is what you are asking about.
– schroeder♦
13 hours ago
4
Have you read a wiki or some other source? en.wikipedia.org/wiki/Digital_signature
– schroeder♦
13 hours ago
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
11 hours ago
The accepted answer is unfortunately incorrect. For RSA at least, signing is closer to decryption of a hash than encryption of it, though that's still dangerously incorrect. This is a common misunderstanding.
– forest
1 hour ago
add a comment |
6
"key signing" is not useful for your understanding. "Digital signature" is what you are asking about.
– schroeder♦
13 hours ago
4
Have you read a wiki or some other source? en.wikipedia.org/wiki/Digital_signature
– schroeder♦
13 hours ago
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
11 hours ago
The accepted answer is unfortunately incorrect. For RSA at least, signing is closer to decryption of a hash than encryption of it, though that's still dangerously incorrect. This is a common misunderstanding.
– forest
1 hour ago
6
6
"key signing" is not useful for your understanding. "Digital signature" is what you are asking about.
– schroeder♦
13 hours ago
"key signing" is not useful for your understanding. "Digital signature" is what you are asking about.
– schroeder♦
13 hours ago
4
4
Have you read a wiki or some other source? en.wikipedia.org/wiki/Digital_signature
– schroeder♦
13 hours ago
Have you read a wiki or some other source? en.wikipedia.org/wiki/Digital_signature
– schroeder♦
13 hours ago
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
11 hours ago
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
11 hours ago
The accepted answer is unfortunately incorrect. For RSA at least, signing is closer to decryption of a hash than encryption of it, though that's still dangerously incorrect. This is a common misunderstanding.
– forest
1 hour ago
The accepted answer is unfortunately incorrect. For RSA at least, signing is closer to decryption of a hash than encryption of it, though that's still dangerously incorrect. This is a common misunderstanding.
– forest
1 hour ago
add a comment |
5 Answers
5
active
oldest
votes
up vote
21
down vote
accepted
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 encrypts only the hash with her private key and attaches this piece of information to the file.
Bob uses her public key to decrypt it and get 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).
1
I think I'm getting there but one thing - how it's attached to the file? Like they get zipped or it's added as a part of the like metadata, or sth else?
– zgulser
10 hours ago
6
@zgulser it depends on the file format and/or protocol. You can even have signatures of the files as a separate files.
– Hauleth
10 hours ago
@zgulser As examples of what Hauleth is talking about, the.sig
files here are signatures in a binary format for the bash source package files of the same name (sans the.sig
). Here, thesignature
links point to.asc
files for the i3 window manager source packages. Those.asc
files are also signatures, but in a text format.
– JoL
8 hours ago
1
@zgulser yes they can be zipped with the document. For example Microsoft Word's docx files are actually just zip archives, you can even open them up in 7-zip or winrar or any other archive manager.
– csiz
7 hours ago
1
@BlueRaja-DannyPflughoeft I don't think that's the case for all public-key signature schemes. ECDSA is a signature algorithm that certainly doesn't have an encryption or decryption step. ECDH is about as close as you can get to "encryption" with the given public key, and it isn't even really that; it's used for symmetric key exchange.
– John Adams
2 hours ago
|
show 8 more comments
up vote
5
down vote
Your second answer is close.
First, let’s agree on the mechanics of the process.
- Identify/validate the data to be signed
- Perform a cryptographic hash of the data
- Encrypt the hash value using your private key
- Output the data and signature in an agreed-upon format
Step 1 is to identify the data. If it’s an entire file, that’s easy enough. This is also the step where you make sure the data is worthy of your signature. You wouldn’t want to sign the wrong thing.
Step 2 is to compute a hash digest of the original data. A hash algorithm takes in any amount of data and outputs a fixed-sized value (called a digest) that is unique to the input data. A hash is repeatable, so If you compute the hash on the same input data a second time, you will get the same digest out. But if someone changes even a single bit of the original data, computing the hash algorithm on the changed data will produce a completely different hash digest. (If you are familiar with the idea of a checksum, it’s similar.)
Step 3 is performing the encryption process. In this step you encrypt the digest with your private key. The output is a digital signature that could only have been created by someone who has a copy of your private key (which should only be you!) By encrypting with your private key, everyone who knows your public key will later be able to confirm the signature by using your public key to decrypt the digest.
Step 4 is where you follow your protocol for outputting digitally signed documents. In cases like producing signed web server certificates, the original data might be an X.509 formatted certificate; this is followed by the bytes of the encrypted hash digest. Depending on the protocol, you might then use Base64 to encode the data plus signature for transport, and put the words BEGIN CERTIFICATE/ END CERTIFICATE around it. This entire block may then be written to a single file.
Note that different protocols will be completely different in how the output is structured. There is no rule of protocols that says the signature must follow the data - the signature could be stored in a different file, or sent in a separate stream. It all depends on the needs of the systems.
I'm confused with the word "hashing" here. Let's say we hash the whole file, we encrypt it, and then pass it along with the original file to the recipient (since the hashed file cannot be reverted on the recipient side), right? If so, would it make the transmission size doubled or make the transmission insecure as the original file be part of the message sent?
– zgulser
10 hours ago
A hash is not the same size as the original file, it's a much shorter string chosen so that an attacker can't find a different file with the same hash (although such files are guaranteed to exist); so no, it doesn't make the transmission size doubled. Generally the entire signature / certificate information has a fixed length of a few hundred bytes at most, but could be based on a hash of a file several gigabytes in size.
– IMSoP
9 hours ago
3
@JohnDeters You might want to pick a different wording for "a hash digest ... uniquely identifies the data". By definition, a hash doesn't uniquely identify an input string (see the "pigeonhole principle"). The second part of that sentence is the important one: an attacker must not be able to choose a new input that will produce the same hash.
– IMSoP
9 hours ago
@zgulser Just to hammer in this point, when a file is signed (but not encrypted), the original file is (often) already part of the message. It's not considered insecure because signing-but-not-encrypting is meant to be used in cases where it doesn't matter who sees the content of the file.
– David Z
8 hours ago
@IMSoP , I intentionally don’t want to get into describing all the crypto involved, and why things need to be done a certain way. “Effectively unique” is a property required of cryptographically secure hash algorithms, but that distinction would only clutter a simple explanation.
– John Deters
6 hours ago
|
show 1 more comment
up vote
3
down vote
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
11 hours ago
3
@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
10 hours ago
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.
– Peter Papadopoulos
10 hours ago
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.
– Peter Papadopoulos
10 hours ago
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).
– Peter Papadopoulos
10 hours ago
|
show 3 more comments
up vote
-1
down vote
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.
Generally, it is done with 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".
Generally, applying the cryptographic process with the public key is known as "encryption", and applying the cryptographic process with the private key is known as "decryption", but with signatures, that nomenclature is often reversed. This is because signing can be accomplished by the signer applying the cryptographic process with the private key, and verification done by the recipient applying the cryptographic process with the public key to the result. Thus, if we continue to refer to what the sender does as "encryption", then signing is done by encrypting with the private key. On the other hand, if we refer to applying the cryptographic process with the public key as "encryption" regardless of who does it, then signing is done by decrypting the file, and it is verified by encrypting the result. To avoid this ambiguity, I have been using the wordier but clearer "applying the cryptographic process".
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 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)
Thx. So, with all the knowledge above, can we "assume" the signature and the certificate including the public key be in the same, let's say, zip file along with the content of the original file? This makes sense to me if the file is already transferred over a secure protocol and recipient only wants to validate the file sender (ie - publishing a new .apk on Google Play)
– zgulser
5 hours ago
@zgulser When you say "certificate including the public key", do you mean "certificate that results from applying the public key", or do you mean "certificate, plus the actual value of the public key"? There wouldn't be much point in including the public key itself in the message. The point of the signature is for the recipient to verify the signature against the alleged sender's public key, to see if the public key used to sign the file is the same as the public key that the recipient has otherwise determined to be the sender's public key.
– Acccumulation
5 hours ago
If someone wants to forge a message, and they're sending the public key with the message, all they have to do is generate a key pair, sign the file with the private key, and then send the public key with the message. All signing does is indicate that the person who sent the message is the same person who published the public key. If the public key is included in the message, then obviously the person who sent you the public key is the same person who sent the public key.
– Acccumulation
5 hours ago
For your first message - I meant the latter (that is the certificate + the actual value of the public key). I think I misexplained myself here. All I try to figure is rather the process for that particular case which is passing a structure of data ( signature+certificate+content) over the web. Also I think you should never use your public key to sign your things (right?).
– zgulser
5 hours ago
add a comment |
up vote
-1
down vote
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.
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 fixed value (usually a Fermat prime), 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 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.
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.
Would the downvoter care to explain what is wrong with this answer? To the best of my knowledge, it is completely correct. I would be happy to revise it if I was made aware of a problem.
– forest
1 hour ago
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.
– TessellatingHeckler
10 mins ago
add a comment |
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
21
down vote
accepted
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 encrypts only the hash with her private key and attaches this piece of information to the file.
Bob uses her public key to decrypt it and get 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).
1
I think I'm getting there but one thing - how it's attached to the file? Like they get zipped or it's added as a part of the like metadata, or sth else?
– zgulser
10 hours ago
6
@zgulser it depends on the file format and/or protocol. You can even have signatures of the files as a separate files.
– Hauleth
10 hours ago
@zgulser As examples of what Hauleth is talking about, the.sig
files here are signatures in a binary format for the bash source package files of the same name (sans the.sig
). Here, thesignature
links point to.asc
files for the i3 window manager source packages. Those.asc
files are also signatures, but in a text format.
– JoL
8 hours ago
1
@zgulser yes they can be zipped with the document. For example Microsoft Word's docx files are actually just zip archives, you can even open them up in 7-zip or winrar or any other archive manager.
– csiz
7 hours ago
1
@BlueRaja-DannyPflughoeft I don't think that's the case for all public-key signature schemes. ECDSA is a signature algorithm that certainly doesn't have an encryption or decryption step. ECDH is about as close as you can get to "encryption" with the given public key, and it isn't even really that; it's used for symmetric key exchange.
– John Adams
2 hours ago
|
show 8 more comments
up vote
21
down vote
accepted
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 encrypts only the hash with her private key and attaches this piece of information to the file.
Bob uses her public key to decrypt it and get 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).
1
I think I'm getting there but one thing - how it's attached to the file? Like they get zipped or it's added as a part of the like metadata, or sth else?
– zgulser
10 hours ago
6
@zgulser it depends on the file format and/or protocol. You can even have signatures of the files as a separate files.
– Hauleth
10 hours ago
@zgulser As examples of what Hauleth is talking about, the.sig
files here are signatures in a binary format for the bash source package files of the same name (sans the.sig
). Here, thesignature
links point to.asc
files for the i3 window manager source packages. Those.asc
files are also signatures, but in a text format.
– JoL
8 hours ago
1
@zgulser yes they can be zipped with the document. For example Microsoft Word's docx files are actually just zip archives, you can even open them up in 7-zip or winrar or any other archive manager.
– csiz
7 hours ago
1
@BlueRaja-DannyPflughoeft I don't think that's the case for all public-key signature schemes. ECDSA is a signature algorithm that certainly doesn't have an encryption or decryption step. ECDH is about as close as you can get to "encryption" with the given public key, and it isn't even really that; it's used for symmetric key exchange.
– John Adams
2 hours ago
|
show 8 more comments
up vote
21
down vote
accepted
up vote
21
down vote
accepted
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 encrypts only the hash with her private key and attaches this piece of information to the file.
Bob uses her public key to decrypt it and get 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).
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 encrypts only the hash with her private key and attaches this piece of information to the file.
Bob uses her public key to decrypt it and get 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).
answered 13 hours ago
Lithilion
8821213
8821213
1
I think I'm getting there but one thing - how it's attached to the file? Like they get zipped or it's added as a part of the like metadata, or sth else?
– zgulser
10 hours ago
6
@zgulser it depends on the file format and/or protocol. You can even have signatures of the files as a separate files.
– Hauleth
10 hours ago
@zgulser As examples of what Hauleth is talking about, the.sig
files here are signatures in a binary format for the bash source package files of the same name (sans the.sig
). Here, thesignature
links point to.asc
files for the i3 window manager source packages. Those.asc
files are also signatures, but in a text format.
– JoL
8 hours ago
1
@zgulser yes they can be zipped with the document. For example Microsoft Word's docx files are actually just zip archives, you can even open them up in 7-zip or winrar or any other archive manager.
– csiz
7 hours ago
1
@BlueRaja-DannyPflughoeft I don't think that's the case for all public-key signature schemes. ECDSA is a signature algorithm that certainly doesn't have an encryption or decryption step. ECDH is about as close as you can get to "encryption" with the given public key, and it isn't even really that; it's used for symmetric key exchange.
– John Adams
2 hours ago
|
show 8 more comments
1
I think I'm getting there but one thing - how it's attached to the file? Like they get zipped or it's added as a part of the like metadata, or sth else?
– zgulser
10 hours ago
6
@zgulser it depends on the file format and/or protocol. You can even have signatures of the files as a separate files.
– Hauleth
10 hours ago
@zgulser As examples of what Hauleth is talking about, the.sig
files here are signatures in a binary format for the bash source package files of the same name (sans the.sig
). Here, thesignature
links point to.asc
files for the i3 window manager source packages. Those.asc
files are also signatures, but in a text format.
– JoL
8 hours ago
1
@zgulser yes they can be zipped with the document. For example Microsoft Word's docx files are actually just zip archives, you can even open them up in 7-zip or winrar or any other archive manager.
– csiz
7 hours ago
1
@BlueRaja-DannyPflughoeft I don't think that's the case for all public-key signature schemes. ECDSA is a signature algorithm that certainly doesn't have an encryption or decryption step. ECDH is about as close as you can get to "encryption" with the given public key, and it isn't even really that; it's used for symmetric key exchange.
– John Adams
2 hours ago
1
1
I think I'm getting there but one thing - how it's attached to the file? Like they get zipped or it's added as a part of the like metadata, or sth else?
– zgulser
10 hours ago
I think I'm getting there but one thing - how it's attached to the file? Like they get zipped or it's added as a part of the like metadata, or sth else?
– zgulser
10 hours ago
6
6
@zgulser it depends on the file format and/or protocol. You can even have signatures of the files as a separate files.
– Hauleth
10 hours ago
@zgulser it depends on the file format and/or protocol. You can even have signatures of the files as a separate files.
– Hauleth
10 hours ago
@zgulser As examples of what Hauleth is talking about, the
.sig
files here are signatures in a binary format for the bash source package files of the same name (sans the .sig
). Here, the signature
links point to .asc
files for the i3 window manager source packages. Those .asc
files are also signatures, but in a text format.– JoL
8 hours ago
@zgulser As examples of what Hauleth is talking about, the
.sig
files here are signatures in a binary format for the bash source package files of the same name (sans the .sig
). Here, the signature
links point to .asc
files for the i3 window manager source packages. Those .asc
files are also signatures, but in a text format.– JoL
8 hours ago
1
1
@zgulser yes they can be zipped with the document. For example Microsoft Word's docx files are actually just zip archives, you can even open them up in 7-zip or winrar or any other archive manager.
– csiz
7 hours ago
@zgulser yes they can be zipped with the document. For example Microsoft Word's docx files are actually just zip archives, you can even open them up in 7-zip or winrar or any other archive manager.
– csiz
7 hours ago
1
1
@BlueRaja-DannyPflughoeft I don't think that's the case for all public-key signature schemes. ECDSA is a signature algorithm that certainly doesn't have an encryption or decryption step. ECDH is about as close as you can get to "encryption" with the given public key, and it isn't even really that; it's used for symmetric key exchange.
– John Adams
2 hours ago
@BlueRaja-DannyPflughoeft I don't think that's the case for all public-key signature schemes. ECDSA is a signature algorithm that certainly doesn't have an encryption or decryption step. ECDH is about as close as you can get to "encryption" with the given public key, and it isn't even really that; it's used for symmetric key exchange.
– John Adams
2 hours ago
|
show 8 more comments
up vote
5
down vote
Your second answer is close.
First, let’s agree on the mechanics of the process.
- Identify/validate the data to be signed
- Perform a cryptographic hash of the data
- Encrypt the hash value using your private key
- Output the data and signature in an agreed-upon format
Step 1 is to identify the data. If it’s an entire file, that’s easy enough. This is also the step where you make sure the data is worthy of your signature. You wouldn’t want to sign the wrong thing.
Step 2 is to compute a hash digest of the original data. A hash algorithm takes in any amount of data and outputs a fixed-sized value (called a digest) that is unique to the input data. A hash is repeatable, so If you compute the hash on the same input data a second time, you will get the same digest out. But if someone changes even a single bit of the original data, computing the hash algorithm on the changed data will produce a completely different hash digest. (If you are familiar with the idea of a checksum, it’s similar.)
Step 3 is performing the encryption process. In this step you encrypt the digest with your private key. The output is a digital signature that could only have been created by someone who has a copy of your private key (which should only be you!) By encrypting with your private key, everyone who knows your public key will later be able to confirm the signature by using your public key to decrypt the digest.
Step 4 is where you follow your protocol for outputting digitally signed documents. In cases like producing signed web server certificates, the original data might be an X.509 formatted certificate; this is followed by the bytes of the encrypted hash digest. Depending on the protocol, you might then use Base64 to encode the data plus signature for transport, and put the words BEGIN CERTIFICATE/ END CERTIFICATE around it. This entire block may then be written to a single file.
Note that different protocols will be completely different in how the output is structured. There is no rule of protocols that says the signature must follow the data - the signature could be stored in a different file, or sent in a separate stream. It all depends on the needs of the systems.
I'm confused with the word "hashing" here. Let's say we hash the whole file, we encrypt it, and then pass it along with the original file to the recipient (since the hashed file cannot be reverted on the recipient side), right? If so, would it make the transmission size doubled or make the transmission insecure as the original file be part of the message sent?
– zgulser
10 hours ago
A hash is not the same size as the original file, it's a much shorter string chosen so that an attacker can't find a different file with the same hash (although such files are guaranteed to exist); so no, it doesn't make the transmission size doubled. Generally the entire signature / certificate information has a fixed length of a few hundred bytes at most, but could be based on a hash of a file several gigabytes in size.
– IMSoP
9 hours ago
3
@JohnDeters You might want to pick a different wording for "a hash digest ... uniquely identifies the data". By definition, a hash doesn't uniquely identify an input string (see the "pigeonhole principle"). The second part of that sentence is the important one: an attacker must not be able to choose a new input that will produce the same hash.
– IMSoP
9 hours ago
@zgulser Just to hammer in this point, when a file is signed (but not encrypted), the original file is (often) already part of the message. It's not considered insecure because signing-but-not-encrypting is meant to be used in cases where it doesn't matter who sees the content of the file.
– David Z
8 hours ago
@IMSoP , I intentionally don’t want to get into describing all the crypto involved, and why things need to be done a certain way. “Effectively unique” is a property required of cryptographically secure hash algorithms, but that distinction would only clutter a simple explanation.
– John Deters
6 hours ago
|
show 1 more comment
up vote
5
down vote
Your second answer is close.
First, let’s agree on the mechanics of the process.
- Identify/validate the data to be signed
- Perform a cryptographic hash of the data
- Encrypt the hash value using your private key
- Output the data and signature in an agreed-upon format
Step 1 is to identify the data. If it’s an entire file, that’s easy enough. This is also the step where you make sure the data is worthy of your signature. You wouldn’t want to sign the wrong thing.
Step 2 is to compute a hash digest of the original data. A hash algorithm takes in any amount of data and outputs a fixed-sized value (called a digest) that is unique to the input data. A hash is repeatable, so If you compute the hash on the same input data a second time, you will get the same digest out. But if someone changes even a single bit of the original data, computing the hash algorithm on the changed data will produce a completely different hash digest. (If you are familiar with the idea of a checksum, it’s similar.)
Step 3 is performing the encryption process. In this step you encrypt the digest with your private key. The output is a digital signature that could only have been created by someone who has a copy of your private key (which should only be you!) By encrypting with your private key, everyone who knows your public key will later be able to confirm the signature by using your public key to decrypt the digest.
Step 4 is where you follow your protocol for outputting digitally signed documents. In cases like producing signed web server certificates, the original data might be an X.509 formatted certificate; this is followed by the bytes of the encrypted hash digest. Depending on the protocol, you might then use Base64 to encode the data plus signature for transport, and put the words BEGIN CERTIFICATE/ END CERTIFICATE around it. This entire block may then be written to a single file.
Note that different protocols will be completely different in how the output is structured. There is no rule of protocols that says the signature must follow the data - the signature could be stored in a different file, or sent in a separate stream. It all depends on the needs of the systems.
I'm confused with the word "hashing" here. Let's say we hash the whole file, we encrypt it, and then pass it along with the original file to the recipient (since the hashed file cannot be reverted on the recipient side), right? If so, would it make the transmission size doubled or make the transmission insecure as the original file be part of the message sent?
– zgulser
10 hours ago
A hash is not the same size as the original file, it's a much shorter string chosen so that an attacker can't find a different file with the same hash (although such files are guaranteed to exist); so no, it doesn't make the transmission size doubled. Generally the entire signature / certificate information has a fixed length of a few hundred bytes at most, but could be based on a hash of a file several gigabytes in size.
– IMSoP
9 hours ago
3
@JohnDeters You might want to pick a different wording for "a hash digest ... uniquely identifies the data". By definition, a hash doesn't uniquely identify an input string (see the "pigeonhole principle"). The second part of that sentence is the important one: an attacker must not be able to choose a new input that will produce the same hash.
– IMSoP
9 hours ago
@zgulser Just to hammer in this point, when a file is signed (but not encrypted), the original file is (often) already part of the message. It's not considered insecure because signing-but-not-encrypting is meant to be used in cases where it doesn't matter who sees the content of the file.
– David Z
8 hours ago
@IMSoP , I intentionally don’t want to get into describing all the crypto involved, and why things need to be done a certain way. “Effectively unique” is a property required of cryptographically secure hash algorithms, but that distinction would only clutter a simple explanation.
– John Deters
6 hours ago
|
show 1 more comment
up vote
5
down vote
up vote
5
down vote
Your second answer is close.
First, let’s agree on the mechanics of the process.
- Identify/validate the data to be signed
- Perform a cryptographic hash of the data
- Encrypt the hash value using your private key
- Output the data and signature in an agreed-upon format
Step 1 is to identify the data. If it’s an entire file, that’s easy enough. This is also the step where you make sure the data is worthy of your signature. You wouldn’t want to sign the wrong thing.
Step 2 is to compute a hash digest of the original data. A hash algorithm takes in any amount of data and outputs a fixed-sized value (called a digest) that is unique to the input data. A hash is repeatable, so If you compute the hash on the same input data a second time, you will get the same digest out. But if someone changes even a single bit of the original data, computing the hash algorithm on the changed data will produce a completely different hash digest. (If you are familiar with the idea of a checksum, it’s similar.)
Step 3 is performing the encryption process. In this step you encrypt the digest with your private key. The output is a digital signature that could only have been created by someone who has a copy of your private key (which should only be you!) By encrypting with your private key, everyone who knows your public key will later be able to confirm the signature by using your public key to decrypt the digest.
Step 4 is where you follow your protocol for outputting digitally signed documents. In cases like producing signed web server certificates, the original data might be an X.509 formatted certificate; this is followed by the bytes of the encrypted hash digest. Depending on the protocol, you might then use Base64 to encode the data plus signature for transport, and put the words BEGIN CERTIFICATE/ END CERTIFICATE around it. This entire block may then be written to a single file.
Note that different protocols will be completely different in how the output is structured. There is no rule of protocols that says the signature must follow the data - the signature could be stored in a different file, or sent in a separate stream. It all depends on the needs of the systems.
Your second answer is close.
First, let’s agree on the mechanics of the process.
- Identify/validate the data to be signed
- Perform a cryptographic hash of the data
- Encrypt the hash value using your private key
- Output the data and signature in an agreed-upon format
Step 1 is to identify the data. If it’s an entire file, that’s easy enough. This is also the step where you make sure the data is worthy of your signature. You wouldn’t want to sign the wrong thing.
Step 2 is to compute a hash digest of the original data. A hash algorithm takes in any amount of data and outputs a fixed-sized value (called a digest) that is unique to the input data. A hash is repeatable, so If you compute the hash on the same input data a second time, you will get the same digest out. But if someone changes even a single bit of the original data, computing the hash algorithm on the changed data will produce a completely different hash digest. (If you are familiar with the idea of a checksum, it’s similar.)
Step 3 is performing the encryption process. In this step you encrypt the digest with your private key. The output is a digital signature that could only have been created by someone who has a copy of your private key (which should only be you!) By encrypting with your private key, everyone who knows your public key will later be able to confirm the signature by using your public key to decrypt the digest.
Step 4 is where you follow your protocol for outputting digitally signed documents. In cases like producing signed web server certificates, the original data might be an X.509 formatted certificate; this is followed by the bytes of the encrypted hash digest. Depending on the protocol, you might then use Base64 to encode the data plus signature for transport, and put the words BEGIN CERTIFICATE/ END CERTIFICATE around it. This entire block may then be written to a single file.
Note that different protocols will be completely different in how the output is structured. There is no rule of protocols that says the signature must follow the data - the signature could be stored in a different file, or sent in a separate stream. It all depends on the needs of the systems.
edited 6 hours ago
answered 12 hours ago
John Deters
26k24085
26k24085
I'm confused with the word "hashing" here. Let's say we hash the whole file, we encrypt it, and then pass it along with the original file to the recipient (since the hashed file cannot be reverted on the recipient side), right? If so, would it make the transmission size doubled or make the transmission insecure as the original file be part of the message sent?
– zgulser
10 hours ago
A hash is not the same size as the original file, it's a much shorter string chosen so that an attacker can't find a different file with the same hash (although such files are guaranteed to exist); so no, it doesn't make the transmission size doubled. Generally the entire signature / certificate information has a fixed length of a few hundred bytes at most, but could be based on a hash of a file several gigabytes in size.
– IMSoP
9 hours ago
3
@JohnDeters You might want to pick a different wording for "a hash digest ... uniquely identifies the data". By definition, a hash doesn't uniquely identify an input string (see the "pigeonhole principle"). The second part of that sentence is the important one: an attacker must not be able to choose a new input that will produce the same hash.
– IMSoP
9 hours ago
@zgulser Just to hammer in this point, when a file is signed (but not encrypted), the original file is (often) already part of the message. It's not considered insecure because signing-but-not-encrypting is meant to be used in cases where it doesn't matter who sees the content of the file.
– David Z
8 hours ago
@IMSoP , I intentionally don’t want to get into describing all the crypto involved, and why things need to be done a certain way. “Effectively unique” is a property required of cryptographically secure hash algorithms, but that distinction would only clutter a simple explanation.
– John Deters
6 hours ago
|
show 1 more comment
I'm confused with the word "hashing" here. Let's say we hash the whole file, we encrypt it, and then pass it along with the original file to the recipient (since the hashed file cannot be reverted on the recipient side), right? If so, would it make the transmission size doubled or make the transmission insecure as the original file be part of the message sent?
– zgulser
10 hours ago
A hash is not the same size as the original file, it's a much shorter string chosen so that an attacker can't find a different file with the same hash (although such files are guaranteed to exist); so no, it doesn't make the transmission size doubled. Generally the entire signature / certificate information has a fixed length of a few hundred bytes at most, but could be based on a hash of a file several gigabytes in size.
– IMSoP
9 hours ago
3
@JohnDeters You might want to pick a different wording for "a hash digest ... uniquely identifies the data". By definition, a hash doesn't uniquely identify an input string (see the "pigeonhole principle"). The second part of that sentence is the important one: an attacker must not be able to choose a new input that will produce the same hash.
– IMSoP
9 hours ago
@zgulser Just to hammer in this point, when a file is signed (but not encrypted), the original file is (often) already part of the message. It's not considered insecure because signing-but-not-encrypting is meant to be used in cases where it doesn't matter who sees the content of the file.
– David Z
8 hours ago
@IMSoP , I intentionally don’t want to get into describing all the crypto involved, and why things need to be done a certain way. “Effectively unique” is a property required of cryptographically secure hash algorithms, but that distinction would only clutter a simple explanation.
– John Deters
6 hours ago
I'm confused with the word "hashing" here. Let's say we hash the whole file, we encrypt it, and then pass it along with the original file to the recipient (since the hashed file cannot be reverted on the recipient side), right? If so, would it make the transmission size doubled or make the transmission insecure as the original file be part of the message sent?
– zgulser
10 hours ago
I'm confused with the word "hashing" here. Let's say we hash the whole file, we encrypt it, and then pass it along with the original file to the recipient (since the hashed file cannot be reverted on the recipient side), right? If so, would it make the transmission size doubled or make the transmission insecure as the original file be part of the message sent?
– zgulser
10 hours ago
A hash is not the same size as the original file, it's a much shorter string chosen so that an attacker can't find a different file with the same hash (although such files are guaranteed to exist); so no, it doesn't make the transmission size doubled. Generally the entire signature / certificate information has a fixed length of a few hundred bytes at most, but could be based on a hash of a file several gigabytes in size.
– IMSoP
9 hours ago
A hash is not the same size as the original file, it's a much shorter string chosen so that an attacker can't find a different file with the same hash (although such files are guaranteed to exist); so no, it doesn't make the transmission size doubled. Generally the entire signature / certificate information has a fixed length of a few hundred bytes at most, but could be based on a hash of a file several gigabytes in size.
– IMSoP
9 hours ago
3
3
@JohnDeters You might want to pick a different wording for "a hash digest ... uniquely identifies the data". By definition, a hash doesn't uniquely identify an input string (see the "pigeonhole principle"). The second part of that sentence is the important one: an attacker must not be able to choose a new input that will produce the same hash.
– IMSoP
9 hours ago
@JohnDeters You might want to pick a different wording for "a hash digest ... uniquely identifies the data". By definition, a hash doesn't uniquely identify an input string (see the "pigeonhole principle"). The second part of that sentence is the important one: an attacker must not be able to choose a new input that will produce the same hash.
– IMSoP
9 hours ago
@zgulser Just to hammer in this point, when a file is signed (but not encrypted), the original file is (often) already part of the message. It's not considered insecure because signing-but-not-encrypting is meant to be used in cases where it doesn't matter who sees the content of the file.
– David Z
8 hours ago
@zgulser Just to hammer in this point, when a file is signed (but not encrypted), the original file is (often) already part of the message. It's not considered insecure because signing-but-not-encrypting is meant to be used in cases where it doesn't matter who sees the content of the file.
– David Z
8 hours ago
@IMSoP , I intentionally don’t want to get into describing all the crypto involved, and why things need to be done a certain way. “Effectively unique” is a property required of cryptographically secure hash algorithms, but that distinction would only clutter a simple explanation.
– John Deters
6 hours ago
@IMSoP , I intentionally don’t want to get into describing all the crypto involved, and why things need to be done a certain way. “Effectively unique” is a property required of cryptographically secure hash algorithms, but that distinction would only clutter a simple explanation.
– John Deters
6 hours ago
|
show 1 more comment
up vote
3
down vote
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
11 hours ago
3
@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
10 hours ago
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.
– Peter Papadopoulos
10 hours ago
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.
– Peter Papadopoulos
10 hours ago
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).
– Peter Papadopoulos
10 hours ago
|
show 3 more comments
up vote
3
down vote
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
11 hours ago
3
@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
10 hours ago
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.
– Peter Papadopoulos
10 hours ago
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.
– Peter Papadopoulos
10 hours ago
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).
– Peter Papadopoulos
10 hours ago
|
show 3 more comments
up vote
3
down vote
up vote
3
down vote
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.
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.
answered 13 hours ago
Peter Papadopoulos
3596
3596
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
11 hours ago
3
@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
10 hours ago
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.
– Peter Papadopoulos
10 hours ago
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.
– Peter Papadopoulos
10 hours ago
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).
– Peter Papadopoulos
10 hours ago
|
show 3 more comments
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
11 hours ago
3
@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
10 hours ago
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.
– Peter Papadopoulos
10 hours ago
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.
– Peter Papadopoulos
10 hours ago
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).
– Peter Papadopoulos
10 hours ago
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
11 hours ago
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
11 hours ago
3
3
@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
10 hours ago
@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
10 hours ago
2
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.
– Peter Papadopoulos
10 hours ago
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.
– Peter Papadopoulos
10 hours ago
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.
– Peter Papadopoulos
10 hours ago
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.
– Peter Papadopoulos
10 hours ago
2
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).
– Peter Papadopoulos
10 hours ago
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).
– Peter Papadopoulos
10 hours ago
|
show 3 more comments
up vote
-1
down vote
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.
Generally, it is done with 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".
Generally, applying the cryptographic process with the public key is known as "encryption", and applying the cryptographic process with the private key is known as "decryption", but with signatures, that nomenclature is often reversed. This is because signing can be accomplished by the signer applying the cryptographic process with the private key, and verification done by the recipient applying the cryptographic process with the public key to the result. Thus, if we continue to refer to what the sender does as "encryption", then signing is done by encrypting with the private key. On the other hand, if we refer to applying the cryptographic process with the public key as "encryption" regardless of who does it, then signing is done by decrypting the file, and it is verified by encrypting the result. To avoid this ambiguity, I have been using the wordier but clearer "applying the cryptographic process".
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 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)
Thx. So, with all the knowledge above, can we "assume" the signature and the certificate including the public key be in the same, let's say, zip file along with the content of the original file? This makes sense to me if the file is already transferred over a secure protocol and recipient only wants to validate the file sender (ie - publishing a new .apk on Google Play)
– zgulser
5 hours ago
@zgulser When you say "certificate including the public key", do you mean "certificate that results from applying the public key", or do you mean "certificate, plus the actual value of the public key"? There wouldn't be much point in including the public key itself in the message. The point of the signature is for the recipient to verify the signature against the alleged sender's public key, to see if the public key used to sign the file is the same as the public key that the recipient has otherwise determined to be the sender's public key.
– Acccumulation
5 hours ago
If someone wants to forge a message, and they're sending the public key with the message, all they have to do is generate a key pair, sign the file with the private key, and then send the public key with the message. All signing does is indicate that the person who sent the message is the same person who published the public key. If the public key is included in the message, then obviously the person who sent you the public key is the same person who sent the public key.
– Acccumulation
5 hours ago
For your first message - I meant the latter (that is the certificate + the actual value of the public key). I think I misexplained myself here. All I try to figure is rather the process for that particular case which is passing a structure of data ( signature+certificate+content) over the web. Also I think you should never use your public key to sign your things (right?).
– zgulser
5 hours ago
add a comment |
up vote
-1
down vote
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.
Generally, it is done with 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".
Generally, applying the cryptographic process with the public key is known as "encryption", and applying the cryptographic process with the private key is known as "decryption", but with signatures, that nomenclature is often reversed. This is because signing can be accomplished by the signer applying the cryptographic process with the private key, and verification done by the recipient applying the cryptographic process with the public key to the result. Thus, if we continue to refer to what the sender does as "encryption", then signing is done by encrypting with the private key. On the other hand, if we refer to applying the cryptographic process with the public key as "encryption" regardless of who does it, then signing is done by decrypting the file, and it is verified by encrypting the result. To avoid this ambiguity, I have been using the wordier but clearer "applying the cryptographic process".
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 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)
Thx. So, with all the knowledge above, can we "assume" the signature and the certificate including the public key be in the same, let's say, zip file along with the content of the original file? This makes sense to me if the file is already transferred over a secure protocol and recipient only wants to validate the file sender (ie - publishing a new .apk on Google Play)
– zgulser
5 hours ago
@zgulser When you say "certificate including the public key", do you mean "certificate that results from applying the public key", or do you mean "certificate, plus the actual value of the public key"? There wouldn't be much point in including the public key itself in the message. The point of the signature is for the recipient to verify the signature against the alleged sender's public key, to see if the public key used to sign the file is the same as the public key that the recipient has otherwise determined to be the sender's public key.
– Acccumulation
5 hours ago
If someone wants to forge a message, and they're sending the public key with the message, all they have to do is generate a key pair, sign the file with the private key, and then send the public key with the message. All signing does is indicate that the person who sent the message is the same person who published the public key. If the public key is included in the message, then obviously the person who sent you the public key is the same person who sent the public key.
– Acccumulation
5 hours ago
For your first message - I meant the latter (that is the certificate + the actual value of the public key). I think I misexplained myself here. All I try to figure is rather the process for that particular case which is passing a structure of data ( signature+certificate+content) over the web. Also I think you should never use your public key to sign your things (right?).
– zgulser
5 hours ago
add a comment |
up vote
-1
down vote
up vote
-1
down vote
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.
Generally, it is done with 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".
Generally, applying the cryptographic process with the public key is known as "encryption", and applying the cryptographic process with the private key is known as "decryption", but with signatures, that nomenclature is often reversed. This is because signing can be accomplished by the signer applying the cryptographic process with the private key, and verification done by the recipient applying the cryptographic process with the public key to the result. Thus, if we continue to refer to what the sender does as "encryption", then signing is done by encrypting with the private key. On the other hand, if we refer to applying the cryptographic process with the public key as "encryption" regardless of who does it, then signing is done by decrypting the file, and it is verified by encrypting the result. To avoid this ambiguity, I have been using the wordier but clearer "applying the cryptographic process".
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 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)
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.
Generally, it is done with 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".
Generally, applying the cryptographic process with the public key is known as "encryption", and applying the cryptographic process with the private key is known as "decryption", but with signatures, that nomenclature is often reversed. This is because signing can be accomplished by the signer applying the cryptographic process with the private key, and verification done by the recipient applying the cryptographic process with the public key to the result. Thus, if we continue to refer to what the sender does as "encryption", then signing is done by encrypting with the private key. On the other hand, if we refer to applying the cryptographic process with the public key as "encryption" regardless of who does it, then signing is done by decrypting the file, and it is verified by encrypting the result. To avoid this ambiguity, I have been using the wordier but clearer "applying the cryptographic process".
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 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)
answered 6 hours ago
Acccumulation
1192
1192
Thx. So, with all the knowledge above, can we "assume" the signature and the certificate including the public key be in the same, let's say, zip file along with the content of the original file? This makes sense to me if the file is already transferred over a secure protocol and recipient only wants to validate the file sender (ie - publishing a new .apk on Google Play)
– zgulser
5 hours ago
@zgulser When you say "certificate including the public key", do you mean "certificate that results from applying the public key", or do you mean "certificate, plus the actual value of the public key"? There wouldn't be much point in including the public key itself in the message. The point of the signature is for the recipient to verify the signature against the alleged sender's public key, to see if the public key used to sign the file is the same as the public key that the recipient has otherwise determined to be the sender's public key.
– Acccumulation
5 hours ago
If someone wants to forge a message, and they're sending the public key with the message, all they have to do is generate a key pair, sign the file with the private key, and then send the public key with the message. All signing does is indicate that the person who sent the message is the same person who published the public key. If the public key is included in the message, then obviously the person who sent you the public key is the same person who sent the public key.
– Acccumulation
5 hours ago
For your first message - I meant the latter (that is the certificate + the actual value of the public key). I think I misexplained myself here. All I try to figure is rather the process for that particular case which is passing a structure of data ( signature+certificate+content) over the web. Also I think you should never use your public key to sign your things (right?).
– zgulser
5 hours ago
add a comment |
Thx. So, with all the knowledge above, can we "assume" the signature and the certificate including the public key be in the same, let's say, zip file along with the content of the original file? This makes sense to me if the file is already transferred over a secure protocol and recipient only wants to validate the file sender (ie - publishing a new .apk on Google Play)
– zgulser
5 hours ago
@zgulser When you say "certificate including the public key", do you mean "certificate that results from applying the public key", or do you mean "certificate, plus the actual value of the public key"? There wouldn't be much point in including the public key itself in the message. The point of the signature is for the recipient to verify the signature against the alleged sender's public key, to see if the public key used to sign the file is the same as the public key that the recipient has otherwise determined to be the sender's public key.
– Acccumulation
5 hours ago
If someone wants to forge a message, and they're sending the public key with the message, all they have to do is generate a key pair, sign the file with the private key, and then send the public key with the message. All signing does is indicate that the person who sent the message is the same person who published the public key. If the public key is included in the message, then obviously the person who sent you the public key is the same person who sent the public key.
– Acccumulation
5 hours ago
For your first message - I meant the latter (that is the certificate + the actual value of the public key). I think I misexplained myself here. All I try to figure is rather the process for that particular case which is passing a structure of data ( signature+certificate+content) over the web. Also I think you should never use your public key to sign your things (right?).
– zgulser
5 hours ago
Thx. So, with all the knowledge above, can we "assume" the signature and the certificate including the public key be in the same, let's say, zip file along with the content of the original file? This makes sense to me if the file is already transferred over a secure protocol and recipient only wants to validate the file sender (ie - publishing a new .apk on Google Play)
– zgulser
5 hours ago
Thx. So, with all the knowledge above, can we "assume" the signature and the certificate including the public key be in the same, let's say, zip file along with the content of the original file? This makes sense to me if the file is already transferred over a secure protocol and recipient only wants to validate the file sender (ie - publishing a new .apk on Google Play)
– zgulser
5 hours ago
@zgulser When you say "certificate including the public key", do you mean "certificate that results from applying the public key", or do you mean "certificate, plus the actual value of the public key"? There wouldn't be much point in including the public key itself in the message. The point of the signature is for the recipient to verify the signature against the alleged sender's public key, to see if the public key used to sign the file is the same as the public key that the recipient has otherwise determined to be the sender's public key.
– Acccumulation
5 hours ago
@zgulser When you say "certificate including the public key", do you mean "certificate that results from applying the public key", or do you mean "certificate, plus the actual value of the public key"? There wouldn't be much point in including the public key itself in the message. The point of the signature is for the recipient to verify the signature against the alleged sender's public key, to see if the public key used to sign the file is the same as the public key that the recipient has otherwise determined to be the sender's public key.
– Acccumulation
5 hours ago
If someone wants to forge a message, and they're sending the public key with the message, all they have to do is generate a key pair, sign the file with the private key, and then send the public key with the message. All signing does is indicate that the person who sent the message is the same person who published the public key. If the public key is included in the message, then obviously the person who sent you the public key is the same person who sent the public key.
– Acccumulation
5 hours ago
If someone wants to forge a message, and they're sending the public key with the message, all they have to do is generate a key pair, sign the file with the private key, and then send the public key with the message. All signing does is indicate that the person who sent the message is the same person who published the public key. If the public key is included in the message, then obviously the person who sent you the public key is the same person who sent the public key.
– Acccumulation
5 hours ago
For your first message - I meant the latter (that is the certificate + the actual value of the public key). I think I misexplained myself here. All I try to figure is rather the process for that particular case which is passing a structure of data ( signature+certificate+content) over the web. Also I think you should never use your public key to sign your things (right?).
– zgulser
5 hours ago
For your first message - I meant the latter (that is the certificate + the actual value of the public key). I think I misexplained myself here. All I try to figure is rather the process for that particular case which is passing a structure of data ( signature+certificate+content) over the web. Also I think you should never use your public key to sign your things (right?).
– zgulser
5 hours ago
add a comment |
up vote
-1
down vote
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.
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 fixed value (usually a Fermat prime), 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 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.
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.
Would the downvoter care to explain what is wrong with this answer? To the best of my knowledge, it is completely correct. I would be happy to revise it if I was made aware of a problem.
– forest
1 hour ago
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.
– TessellatingHeckler
10 mins ago
add a comment |
up vote
-1
down vote
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.
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 fixed value (usually a Fermat prime), 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 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.
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.
Would the downvoter care to explain what is wrong with this answer? To the best of my knowledge, it is completely correct. I would be happy to revise it if I was made aware of a problem.
– forest
1 hour ago
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.
– TessellatingHeckler
10 mins ago
add a comment |
up vote
-1
down vote
up vote
-1
down vote
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.
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 fixed value (usually a Fermat prime), 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 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.
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.
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.
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 fixed value (usually a Fermat prime), 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 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.
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.
edited 59 mins ago
answered 2 hours ago
forest
27k138398
27k138398
Would the downvoter care to explain what is wrong with this answer? To the best of my knowledge, it is completely correct. I would be happy to revise it if I was made aware of a problem.
– forest
1 hour ago
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.
– TessellatingHeckler
10 mins ago
add a comment |
Would the downvoter care to explain what is wrong with this answer? To the best of my knowledge, it is completely correct. I would be happy to revise it if I was made aware of a problem.
– forest
1 hour ago
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.
– TessellatingHeckler
10 mins ago
Would the downvoter care to explain what is wrong with this answer? To the best of my knowledge, it is completely correct. I would be happy to revise it if I was made aware of a problem.
– forest
1 hour ago
Would the downvoter care to explain what is wrong with this answer? To the best of my knowledge, it is completely correct. I would be happy to revise it if I was made aware of a problem.
– forest
1 hour ago
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.
– TessellatingHeckler
10 mins ago
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.
– TessellatingHeckler
10 mins ago
add a comment |
zgulser is a new contributor. Be nice, and check out our Code of Conduct.
zgulser is a new contributor. Be nice, and check out our Code of Conduct.
zgulser is a new contributor. Be nice, and check out our Code of Conduct.
zgulser is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f198423%2fwhat-does-signing-a-file-really-mean%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
6
"key signing" is not useful for your understanding. "Digital signature" is what you are asking about.
– schroeder♦
13 hours ago
4
Have you read a wiki or some other source? en.wikipedia.org/wiki/Digital_signature
– schroeder♦
13 hours ago
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
11 hours ago
The accepted answer is unfortunately incorrect. For RSA at least, signing is closer to decryption of a hash than encryption of it, though that's still dangerously incorrect. This is a common misunderstanding.
– forest
1 hour ago