Digital signature
In cryptography, a digital signature proves that a message was produced by the holder of a private key and was not altered afterwards. It is the correct, valuable use of a hash function, and it underpins code signing, DNSSEC, document signing and the schemes behind qualified electronic signatures in the EU.
What it is
Electronic signature is the broad term: any data in electronic form associated with a document that serves to identify the person signing. The label covers everything from the image of a handwritten signature pasted into a PDF, which proves very little, to a signature backed by cryptography and by a certificate issued by a trusted third party.
Digital signature is the second of those, the specific technical form, and the only one that proves anything to a third party. The distinction matters because both are sold under the same word: the guarantee comes not from the process being electronic, but from a private key behind it and a verification that actually runs.
How it works
A digital signature combines a hash function with public-key cryptography. The signer computes the digest of the message and encrypts that digest with their private key; the result is the signature, attached to the message. Anyone with the signer’s public key can recompute the digest, verify it against the decrypted signature, and confirm two things at once: that the message was not changed (integrity) and that it came from the holder of the private key (authenticity), which together give non-repudiation. The trust in the public key comes from a public key infrastructure, so a signature is only as trustworthy as the certificate binding the key to an identity, and that certificate is issued by a certificate authority. It differs from a keyed integrity code such as HMAC, which uses a shared secret and so cannot prove which of two parties produced it.
What goes wrong
Signatures fail at the edges, not in the mathematics. If the underlying hash has broken collision resistance (MD5 or SHA-1), an attacker can construct two messages with the same digest, and a signature over one is a valid signature over the other, which is a genuine forgery. Verification is the other soft spot: an application that accepts a signature without checking that the certificate is valid, unexpired and not revoked, or that trusts the wrong signing identity, gains nothing from the cryptography. In the supply chain this matters directly: code signing is meant to prove software’s origin, and a software supply chain attack that abuses a stolen signing key or a lax verification defeats exactly the control that was supposed to stop it. The quantum horizon also presses sooner here than in encryption, because a document signed today has to remain verifiable for many years, which is the ground of post-quantum cryptography.
Where this shows up in an audit
Wherever signatures gate trust (signed code, signed documents, signed DNS records under DNSSEC, tokens and updates) we check the algorithm and the verification. We flag signatures relying on a hash with broken collision resistance, and, more often, verification that is incomplete: certificate validity and revocation not checked, or the trust anchor too broad. The finding is written against the weak algorithm or the missing verification step, because a signature that is not properly verified provides authenticity to no one and is a control in name only.