Tokenisation, hashing and digital signatures

Why this matters

Objective 3.5 is about the primitives themselves, and its examinable skill is selection: given a stated requirement, which primitive provides it. That sounds elementary and it is where a surprising number of marks are lost, because the primitives have overlapping-sounding names and non-overlapping properties.

Three distinctions do most of the work. Tokenisation is not encryption — there is no key and no mathematical relationship, which is exactly why it reduces compliance scope where encryption does not. Hashing is not encryption — it is one-way and has no key, so "hash the data so we can retrieve it later" is a contradiction. And a signature is not a MAC — both provide integrity and authenticity, and only one provides non-repudiation, because only one uses a key that a single party holds.

The lesson works through each primitive by the property it provides, because that is how scenarios present the question.

The lesson

Tokenisation versus encryption, and the scope reduction that makes it attractive

Tokenisation replaces a sensitive value with a surrogate — a token — that has no mathematical relationship to the original. The mapping between the two is held in a separate, strongly protected vault. Recovering the original requires access to the vault; it cannot be computed from the token.

Encryption transforms a value with a key. The ciphertext contains the information, protected by the key, and anyone with the key recovers it.

That difference produces the commercial property that drives adoption. Because a token carries no information about the original, systems holding only tokens are generally outside the compliance scope for the data the tokens represent — which is the scope reduction lesson eleven described as the largest cost lever in the payment standard. Encrypted data, by contrast, is usually still in scope, because the protection depends on key management that the assessor must therefore examine.

Practical considerations that scenarios probe:

• The vault becomes the highest-value asset in the estate. Everything depends on it, so it needs the strongest protection, the strictest access, and serious availability engineering — it is now in the path of every detokenisation.
• Format-preserving tokens keep the shape of the original so existing systems accept them, which is what makes retrofitting possible. The caution is that preserved format can leak — a token retaining the last four digits is deliberate and is disclosure.
• Detokenisation must be tightly controlled and logged, because the population of systems that can detokenise is the real scope. A permissive detokenisation API undoes the entire arrangement.
• Determinism is a trade. A deterministic scheme, where the same input always yields the same token, allows matching and joins across systems and thereby permits analysis of the underlying data — which may be exactly what you wanted to prevent.

The selection rule: tokenise when the goal is to remove data from systems that do not need it; encrypt when the data must remain present and usable in place. A scenario about reducing the number of systems in an audit scope wants tokenisation; a scenario about protecting data the application must process wants encryption.

Hashing for integrity, with salts, peppers and the misuse that breaks it

A cryptographic hash maps input of any size to a fixed-size digest, such that the same input always produces the same digest, the input cannot be recovered from the digest, and finding two inputs with the same digest is infeasible.

It has no key, which is the fact that determines everything about where it can be used. A hash alone provides integrity only against accidental change, because an attacker who alters data can simply recompute the digest. To provide integrity against an adversary, the hash must be bound to a secret or a signature — which is what MACs and signatures do, below.

Uses that are correct:

• Detecting corruption, where the digest is obtained by a trusted route separate from the data.
• Deduplication and content addressing.
• A building block inside MACs, signatures, key derivation and password-hashing functions.
• Commitment, publishing a digest now to prove later that you held the data at that time.

Misuses that scenarios describe:

• Using a fast general-purpose hash for passwords. It is designed to be fast, so guessing is fast. Lesson thirty-five's stretching functions exist for this, and this is the single most common misuse.
• Treating an unprotected digest as tamper evidence against an attacker who can also change the digest.
• Using a hash for anonymisation. Hashing an identifier from a small or guessable domain — an email address, a phone number, a national identifier — is reversible by brute force in seconds, so hashed identifiers are pseudonymous at best and remain personal data.
• Using an algorithm with known collision weaknesses for anything requiring collision resistance, such as signing.

Salts are unique per record, stored alongside the hash, not secret, and they defeat precomputation and reveal nothing when two users share a password. Peppers are a site-wide secret stored separately from the database, so that a database compromise alone is insufficient; they are optional and complicate rotation. Both were covered in lesson thirty-five and belong to password hashing specifically, not to hashing generally.

Digital signatures: what they prove about origin and about change

A digital signature is produced by hashing the data and encrypting the digest with the signer's private key. A verifier hashes the data, decrypts the signature with the signer's public key, and compares.

Properties it provides, and the third is what distinguishes it:

• Integrity — any change to the data breaks the comparison.
• Authenticity — only the holder of the private key could have produced it.
• Non-repudiation — because only one party holds the private key, the signer cannot credibly deny signing.

Compare with a message authentication code, which provides integrity and authenticity using a shared secret. Either party can compute it, so either could have produced any given value — which means a MAC gives no non-repudiation. This is the distinction to be able to state cold, because scenarios turn on it: a requirement that a party must not be able to deny an action eliminates every shared-secret mechanism.

What a signature does not prove, and each appears as a distractor:

• That the content is true. It proves who asserted it, not that the assertion is correct.
• That the signer intended the specific meaning, unless what was signed makes that clear — a signature over a rendered document that a reader sees differently from what was signed is a real class of attack.
• When it was signed. Signature time is asserted by the signer unless a trusted timestamp is added, which is the mechanism that makes long-term verification possible after a certificate expires.
• That the key still belongs to the claimed identity, which is the certificate and revocation problem from lesson thirty-seven.

Non-repudiation as a property built from signature, identity and time

Non-repudiation is not a primitive; it is a property assembled from several controls, and a design missing any one of them does not achieve it. This is worth treating explicitly because scenarios frequently describe a system with signatures that nonetheless cannot support a repudiation claim.

The components:

• Sole control of the private key. If anyone else can use the key — an escrow, a shared HSM role, an administrator who can extract it — the signer can plausibly deny. Hardware-held, non-exportable keys are what make sole control credible, and key escrow is directly incompatible with it, which is a trade lesson thirty-seven noted for email.
• Strong binding of key to identity, through an enrolment process that actually verified the person or workload. Non-repudiation inherits the weakness of issuance.
• A trusted timestamp, so the signature can be shown to have existed while the certificate was valid. Without it, an expired or revoked certificate makes the signature unverifiable later, and "I cannot verify it" and "it was not signed" are indistinguishable.
• Evidence retention — the signature, the certificate chain, the revocation status at signing time and the timestamp — preserved for as long as the signature must remain provable. This is a records management obligation, and it is what usually fails.
• Audit logging of the signing event, binding it to an authenticated session.

The practical test to apply to a design: could the signer plausibly claim somebody else did it? If the key is on a shared filesystem, if the administrator could have used it, if the enrolment was self-service with no verification, or if the evidence to verify it no longer exists, then yes — and the system provides integrity and authenticity but not non-repudiation.

Picking the primitive from the requirement, which is how these are examined

The selection table the objective is built around. In a scenario, find the property being asked for and read across.

Three habits that make the table usable under exam conditions:

Ask whether the original must be recoverable. If yes, hashing is eliminated entirely. This one question removes a large share of wrong answers immediately.

Ask how many parties hold the secret. One party means a signature is available and non-repudiation is achievable; two or more means a MAC at best, and non-repudiation is off the table.

Ask what is being protected against whom. Accidental corruption, an adversary in the middle, an insider with the database, a party who might later deny — these lead to different rows, and the scenario nearly always says which one in its description of the problem rather than in its technical detail.