How to make a digital signature (and how digital differs from electronic)

To make a digital signature, the document's digest is computed and signed with a private key whose paired public key is certified — an electronic attestation linking the key to a named person. In practice, nobody does this by hand: a signing service performs the cryptography; your part is to load the document and identify the signers.

Under eIDAS, an electronic signature is 'data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign' (article 3(10)) — the drawing you see in the ceremony is just the human-readable face of those data.

Three components, exactly: a hash of the signed content (the digest makes the statement self-contained — verification re-computes it), the private key operation that signs that digest (the key is the one thing that cannot be shared), and a certificate that ties the key to an identity, issued via a chain you can validate. Three facts; that is what any digital signature is, whatever platform you use.

The visual mark (a drawn or typed name in the signing canvas) is presentation, not the signature itself. The regulation's article 3(13) calls the operative thing 'electronic signature creation data' — unique data the signatory uses to create the signature, kept under the signatory's sole control — which is the article 26(c) requirement in its standard form.

Hand-rolled: generate a key pair locally (OpenSSL, GPG), sign the file, distribute the key. It works and is free; the receiver then has to assemble the chain, the time and the revocation checks themselves — which is why hand-rolled signatures are rare in contracts.

Platform-issued: the service runs signature creation data under the signatory's sole control, typically gated by possession checks (a one-time code) and binds the result into the document with a timestamp. What you trade is care of the infrastructure; what you gain is that the evidence arrives complete.

Qualified-device based: key creation and signing happen in a certified device (a smart card or certified mobile environment), on a qualified certificate issued by a qualified trust service provider — that is the article 3(12) qualified electronic signature, which article 25(2) gives the legal effect of a handwritten signature. Where the law or the counterparty demands it, only this third path qualifies.

Any of the three above can be an electronic signature. The advanced tier is a factual requirement set (article 26: unique link, identification, sole control, tamper detection) — a compliant platform's standard output qualifies, but it is a question about the flow, not a label.

The qualified tier is about who certified the key. A qualified certificate for electronic signature 'is issued by a qualified trust service provider and meets the requirements laid down in Annex I' (article 3(15)) — so the question 'do I need a qualified signature?' is answered by the words 'who issues the certificate', and nothing else.

In a compliant remote flow: the signer receives a single-use token, proves possession (a code), and signs — creation data used under the signer's sole control during the ceremony, exactly what article 26(c) asks. The platform then seals the output: hash-bound content, an authority-anchored RFC 3161 time when configured, validation material only when the signing service actually embeds it, and a verification path anyone can run.

The parts that make the proof worth re-examining later are not ‘making a signature’ but packaging it: the timestamp, the level, and the audit trail around the ceremony. That is why the next step after signing is not reading the file, but reading the evidence pack.