Digital signature

A digital-signature scheme defines generation and verification processes. The signer uses a private key and the specified data to generate a signature. A verifier checks the relationship among that data, the signature, and the corresponding public key. The public key may be disclosed; the private key must remain secret to prevent impersonation.

Many schemes first compute a cryptographic message digest, but “encrypting a hash with the private key” is not a universal definition of signing. FIPS 186-5 distinguishes input processing for RSA, ECDSA, HashEdDSA, and EdDSA. Signature schemes have their own generation and verification rules and need not provide an operation that decrypts the signature.

References: [1] [2]

A signature allows changes that break its relationship to the signed data to be detected. Under the security assumptions of a correctly implemented scheme, an attacker without the private key should not be able to forge a valid signature for a different message. The protection concerns the data actually covered by the signing procedure, not everything a reader associates with it.

If a protocol signs only a particular field or message portion, additional unsigned commentary is not protected merely because it accompanies the signature. Systems must specify the signed representation and scope. Verification failure also does not identify its cause by itself: altered data, a damaged signature, or an incorrect public key can all prevent successful verification.

References: [1] [2]

Successful mathematical verification does not alone identify a real-world person or organization. Anyone can generate a key pair and attach someone else's name to the public key. The verifier needs a trustworthy binding to the claimed signer, valid keys and parameters, and appropriate assurances about possession of the corresponding private key. Certificates and public-key infrastructure commonly support this binding.

FIPS 186-5 consequently distinguishes mathematical verification from validation that obtains the additional assurances. A public key need not be confidential, but substitution must be prevented. Compromise of the private key undermines attribution. Evidence of origin therefore depends on key management and the applicable trust arrangement, not only on a successful arithmetic check.

References: [1]

Signing and encryption provide different services. A signature can accompany publicly readable data and be checked by anyone with the correct public key. Restricting who can read the message requires a separate confidentiality mechanism. TLS 1.3 similarly separates authentication from record-layer traffic protection; a signature is not a substitute for authenticated encryption.

A valid signature also cannot establish that a claim is true, advice is sound, or software behaves safely. An authenticated source can sign mistaken or harmful content. This follows from the verification target: cryptography checks a relationship between data and keys, not the merits of the statements. An image of handwriting is likewise not this cryptographic process and does not supply equivalent change detection.

References: [2] [3]