Key stretching, hardware acceleration and where crypto actually runs

Why this matters

This lesson closes objective 3.3 with the two remaining named topics, and they share a theme that is easy to miss: performance is a security property.

Key stretching is deliberately slow, and how slow is a parameter you set and must revisit, because the attacker's hardware improves while your stored hashes do not. Hardware acceleration is deliberately fast, and its absence is a security problem rather than only a cost one — because cryptography that is too slow gets switched off in production, which is a failure mode that reliably appears in incident reports and in exam scenarios.

The third section covers where cryptographic operations physically happen, because that determines who can extract a key. It ties back to lesson seventeen's key models and lesson twenty-two's attestation: this is the same question at the level of the individual operation.

The lesson

Key derivation and stretching: PBKDF2, bcrypt, scrypt, Argon2 and the parameters that matter

The problem: a password is low-entropy and a cryptographic hash is fast, so an attacker who obtains stored hashes can test billions of candidates per second. Key stretching makes each guess expensive, so the same attacker tests far fewer.

The functions, in the order they arrived and with what each added:

• PBKDF2. Applies a pseudo-random function repeatedly. The cost parameter is the iteration count. Widely supported and approved in many compliance regimes, which is often why it is chosen. Its weakness is that it is CPU-bound and memory-light, so it parallelises extremely well on graphics hardware and dedicated devices — an attacker's advantage over your server is large.
• bcrypt. Deliberately uses a moderate amount of memory and an access pattern less friendly to parallel hardware, which narrows that advantage. Its cost parameter is a work factor that scales exponentially. A practical limitation to know: it truncates long inputs, which matters when passphrases are long.
• scrypt. Explicitly memory-hard: it requires a configurable, large amount of memory, so parallel attack hardware must provide memory per instance, which is expensive. Parameters cover CPU/memory cost, block size and parallelism.
• Argon2. The current general recommendation, designed for this purpose with independent control of memory, iterations and parallelism. Its variants trade side-channel resistance against maximum memory hardness, and the hybrid variant is the usual default.

Parameters are the part that matters in practice, and three rules cover it. Tune to your hardware: choose parameters so that a single derivation takes a target time on your production hardware — a few hundred milliseconds for interactive authentication is the common target, balancing attacker cost against user experience and your own capacity under load. Revisit them, because attacker hardware improves and parameters chosen five years ago are now cheap to attack. And store the parameters with the hash, so that old hashes remain verifiable while new ones use stronger settings, and so an upgrade can rehash on next successful authentication.

Two supporting elements. A salt is unique per password, stored alongside the hash, and defeats precomputation — it is not secret and does not need to be. A pepper is a site-wide secret value combined with the password, stored separately from the database (ideally in an HSM), so that a database compromise alone is insufficient. Peppers are optional, genuinely useful, and complicate rotation.

The distinction worth holding, because scenarios use it: password hashing functions are intentionally slow; general-purpose hash functions are intentionally fast. Using a fast hash for passwords is the classic error, and using a slow one for integrity checking of large files is the mirror image.

Work factors tuned to your hardware and revisited, because attackers upgrade too

The operational discipline, stated separately because organisations set these once and never return.

Stored password hashes have a long life — years, often — and their protection is fixed at the parameters used when they were created, while attack economics improve continuously. A parameter set that made a guess expensive in one era is ordinary in the next, and nothing in the system reports that.

What a maintained programme does:

• Benchmark on current production hardware, not on a developer laptop, and choose parameters to hit the target time under realistic concurrency.
• Record the parameters as a configuration standard with a review cycle — lesson one's machinery, applied to a number that silently decays.
• Upgrade opportunistically. On each successful authentication, if the stored parameters are below current standard, rehash with the new ones. Over time the population migrates without forcing a password reset.
• Account for load. Stretching costs you CPU on every authentication, so it is a capacity consideration and a denial-of-service consideration: an attacker submitting authentication attempts consumes your CPU at the rate you chose. Rate limiting is the pairing.

The scenario shape: an organisation whose password hashes are cracked quickly after a database breach despite "using a proper hashing function". The function was right and the work factor was the default from a decade-old library.

Hardware acceleration: AES-NI, offload cards and the throughput it unlocks

Cryptography is computationally expensive, and hardware support is what makes pervasive encryption affordable.

Instruction-set acceleration — dedicated processor instructions for block cipher rounds and for hashing — is present in essentially all modern general-purpose processors and improves symmetric encryption throughput by a large multiple. Its practical significance is that it removed the argument for leaving data unencrypted on performance grounds. A scenario justifying plaintext storage or transport by CPU cost is usually describing a decision made before this was universal, or a configuration not using it.

Offload devices — network cards and dedicated cards that perform cryptographic operations — matter at high volume, principally for terminating large numbers of TLS connections. The security consideration is where the keys live: an offload device holding private keys is a key storage location with its own protection properties, and it may or may not prevent extraction.

Two practical points that recur:

• Verify acceleration is actually being used. Libraries fall back to software implementations silently when built without support, when running in a constrained container, or when a virtualisation layer does not expose the instructions. The symptom is unexplained CPU load, and the diagnosis is rarely attempted because nothing reports it.
• Acceleration cuts both ways. The same hardware that makes your cryptography cheap makes the attacker's guessing cheap, which is precisely why key stretching functions are designed to be memory-hard rather than merely iterative.

A third point connects to the previous lesson: performance is why confidential computing is practical and homomorphic encryption is not. The first runs ordinary accelerated operations inside a protected region; the second cannot use any of that acceleration because it is doing different mathematics.

HSMs and TPMs: what each protects and the operations that never leave them

Both are hardware roots of trust, they solve different problems, and confusing them is a recognisable error.

A trusted platform module is a small chip bound to a single machine. Its purposes are platform integrity and machine-bound key storage: it holds measurements from the boot process, as lesson twenty-two described, and can hold keys that are usable only on that machine and only when the platform is in an expected state. It is a low-throughput device — it is not there to encrypt bulk data, and using it as though it were is a design error.

A hardware security module is a dedicated, certified device for cryptographic operations at volume. It generates keys, performs signing and encryption, and is built so that key material cannot be extracted. It is used as a root of trust for certificate authorities, for payment processing, for code signing, and as the backing for key management services.

The property both share, and it is the reason either exists: the private key never leaves the device. An application does not retrieve the key and use it; it sends the operation to the device, which performs it and returns the result. A complete compromise of the host therefore yields the use of the key while the device permits it, and not the key itself — which means revocation actually works, and the compromise ends when access is withdrawn.

Practical considerations that scenarios test:

• Certification levels are frequently mandated by obligation rather than chosen by risk, and the required level appears in the requirement text.
• Backup and quorum. Key material that cannot be extracted also cannot be casually backed up; recovery relies on device-specific mechanisms usually requiring several custodians. That is a control and an operational burden, and losing the ability to use a key is unrecoverable data loss.
• Availability. If every transaction requires the device, the device is in the availability path. Clustering matters.
• Throughput and latency are real limits, which is why envelope encryption from lesson seventeen exists: the device protects the key-encrypting key and bulk data is encrypted by data keys in software with hardware acceleration.

Performance as a security property when slow crypto gets switched off in production

The closing idea of the objective, and the one worth carrying because it changes how you evaluate a design.

Cryptographic controls that are too slow do not stay in place. The sequence is predictable: the control is deployed, latency rises, users or a dependent team complain, the control is exempted for the affected path "temporarily", and the exemption persists. The estate then has a documented control and a real configuration that differs, which is the drift from lesson twenty-seven in its most consequential form.

Recognising the pattern:

• TLS inspection exempted for a list of destinations that grows.
• Encryption disabled on a database "for performance during month-end".
• A key management call cached with an unbounded lifetime, so key policy changes no longer take effect.
• Signature verification skipped in a hot path.
• Multi-factor authentication bypassed for a service because it broke an integration.

Each is a real configuration with a plausible justification, and none appears in the architecture document.

The engineering response is to treat performance as a design requirement of the control itself: measure the cost before deployment under realistic load, choose mechanisms and placements that meet the latency budget, use hardware acceleration deliberately, and size the infrastructure for the cryptographic work rather than discovering it in production. Where a control genuinely cannot meet the requirement, that is an architecture decision to make openly — a different control, a different placement, or an accepted risk with an owner — rather than an exemption granted under pressure at the moment something is slow.

And the governance response is lesson eighteen's, restated: a control that generates more friction than the organisation will tolerate does not produce security, it produces workarounds. The strongest cryptography in the estate is the cryptography that is still switched on a year later.