Cfxtrjtrk

Your second answer is close.

First, let’s agree on the mechanics of the process.

1. Identify/validate the data to be signed


2. Perform a cryptographic hash of the data


3. Encrypt the hash value using your private key


4. 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.

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.

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)

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 ≡ m^e (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 ≡ m^d (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 s^e ≡ 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.