Encryption: algorithms, key length, key exchange, and where to apply it

Objective 1.3 is about choosing the appropriate cryptographic solution. The previous lesson covered PKI and certificates. This one covers encryption itself: the two families of algorithm, how strong is strong enough, how two parties agree a key in public, how much of a system to encrypt, and how data is protected in transit -- along with the hardware that keeps the keys safe. Hashing, salting, signatures and obfuscation follow in the next lesson.

Why this matters

Encryption questions on this exam are almost never about how an algorithm works inside. They are about fit: a stated requirement, a threat, a constraint such as a low-powered device, and four options of which one matches. "Encrypt it" is rarely the whole answer -- the question is encrypt what, where, with which kind of key, and where does that key live.

It is also where the most persistent misunderstandings live. Full-disk encryption is not protection against malware on a running laptop. A longer key is not comparable across algorithm families. And a strong cipher with its key stored next to the data protects almost nothing. Each of those is a question waiting to happen.

The lesson

Symmetric and asymmetric, and why every real protocol uses both

Symmetric encryption uses one shared secret key to encrypt and decrypt. It is fast and suited to bulk data -- disks, files, network streams. Its problem is distribution: both ends need the same key, and getting it to them without anyone else seeing it is hard. Every pair of parties also needs its own key, which scales badly.

Asymmetric encryption uses a key pair, public and private. It solves distribution, because the public key can be published, and it enables signatures. It is far slower than symmetric encryption and is not used to encrypt bulk data.

Real protocols therefore use both, each for what it is good at. In a TLS connection, asymmetric cryptography authenticates the server (through its certificate) and lets the two sides agree a fresh symmetric session key; that symmetric key then encrypts everything that follows. Encrypted email works the same way: the message is encrypted with a random symmetric key, and only that small key is encrypted with the recipient's public key. When a question asks why a protocol does not simply use asymmetric encryption for everything, the answer is performance.

Algorithms and key length, and what 'strong enough' means this decade

The names worth knowing:

• AES is the standard symmetric cipher, with 128-, 192- and 256-bit keys. AES-128 is still considered strong; AES-256 is chosen for long-lived or highly sensitive data. ChaCha20 is a widely used alternative, common on devices without AES hardware support.
• RSA is the long-established asymmetric algorithm. 2048 bits is the usual minimum today, with 3072 bits or more recommended for data that must stay protected well into the next decade.
• Elliptic curve cryptography (ECC) gives comparable strength with much shorter keys -- a 256-bit curve is roughly as strong as 3072-bit RSA -- which is why phones, smart cards and constrained IoT devices favour it.
• Deprecated and wrong answers: DES (its 56-bit key is brute-forceable), 3DES (retired by NIST for new encryption), RC4 (prohibited in TLS), and short RSA keys such as 1024 bits.

Two rules about key length. First, it is only comparable within a family: 256-bit AES, 256-bit ECC and 2048-bit RSA are not on one scale. Second, longer keys cost performance, so the exam frames length as a trade-off between strength and speed, especially on constrained devices.

"Strong enough this decade" has one more dimension: quantum computing. A sufficiently large quantum computer would break RSA, elliptic-curve and Diffie-Hellman algorithms outright, while weakening symmetric ciphers far less -- another reason to prefer AES-256 for long-term secrets. Because recorded traffic could be decrypted later, data with a long confidentiality life is already at risk. NIST published its first post-quantum standards in 2024, and major browsers have begun combining a classical and a post-quantum algorithm in their key exchanges. For the exam, the practical point is crypto-agility: systems should be able to change algorithms without being rebuilt.

Key exchange: agreeing a secret over a channel somebody else is reading

Symmetric encryption needs a shared key, and the network between the two parties is assumed hostile. There are two broad answers.

• Key transport. One side generates the session key and sends it encrypted with the other side's public key. It works, but if that long-term private key is ever stolen, every recorded session protected that way can be decrypted.
• Key agreement. With Diffie-Hellman (DH) or its elliptic-curve form ECDH, each side contributes a value and both derive the same secret without it ever crossing the wire. Someone watching sees the exchange and still cannot compute the result.

When those Diffie-Hellman values are freshly generated for each session and then discarded -- ephemeral exchange, written DHE or ECDHE -- you get perfect forward secrecy (PFS): stealing the server's long-term key later does not expose past sessions, because the keys that protected them no longer exist. TLS 1.3 dropped RSA key transport for this reason, so its normal handshakes are forward-secret.

Diffie-Hellman on its own does not prove who you agreed a key with, so an attacker in the middle could run one exchange with each side. That is why the exchange is authenticated -- in TLS, the server signs its part with the key in its certificate.

Some keys are still exchanged out of band: a pre-shared key typed into two devices, or delivered separately from the data it protects. That is acceptable for small, fixed relationships and does not scale beyond them.

Encrypting a whole disk, a partition or volume, a file, a database or a single record

The level of encryption should match the threat. The broader it is, the less it protects once the system is running and unlocked.

• Full-disk encryption covers everything on the drive, including the operating system. It protects a device that is lost or stolen while powered off. It protects against nothing once the machine is booted and a user is logged in -- which is why "the laptops have full-disk encryption" is not an answer to a malware question.
• Partition and volume encryption protect a subdivision of storage: a partition is a slice of one physical disk, while a volume is a logical unit that may span more than one. Both let you, for example, encrypt a data volume separately from the system. Products blur these terms -- several tools sold as full-disk encryption technically work on volumes -- so answer from the scope the scenario describes.
• File-level encryption protects individual files and keeps protecting them when they are copied off the disk, emailed or uploaded -- the property full-disk lacks.
• Database encryption protects the whole data store, often transparently to the application, which mainly defends against stolen storage or backups.
• Record-level (or field- and column-level) encryption protects individual rows or values, so a database administrator who can read the tables still cannot read the card numbers. This is the answer when the threat is a privileged insider or an application flaw that exposes whole tables.

The rule of thumb: the more granular the encryption, the more separation you get from people and processes that legitimately have access to the layer beneath it -- at the cost of more keys to manage.

Encryption in transit, the protocols that carry it, and the hardware that guards the keys

Data at rest is only half of it. Transport or communication encryption protects data moving across a network, and on the exam it is usually a matter of picking the secure protocol over the insecure one:

• TLS protects web traffic (HTTPS) and wraps many other protocols -- secure directory lookups (LDAPS), mail transfer, FTPS. Current versions are 1.2 and 1.3; SSL and early TLS are deprecated.
• SSH replaces Telnet for remote administration, and carries SFTP and SCP for file transfer.
• IPsec protects traffic at the network layer, typically for site-to-site and remote-access VPNs.
• Others to recognise: SNMPv3 instead of earlier versions for device management, SRTP for voice and video, S/MIME for signed and encrypted email.

Whatever the algorithm, encryption is only as strong as the protection of its keys. The hardware tools that guard them:

• A TPM (Trusted Platform Module) is a chip in an individual computer. It stores keys, ties them to that machine, and can attest to its boot state -- which is why a laptop's encrypted disk will not unlock in another machine.
• An HSM (hardware security module) is a dedicated, tamper-resistant device, or cloud service, for an organisation. It generates and stores keys and performs operations without the key ever leaving it: applications ask the HSM to sign or decrypt rather than asking for the key.
• A key management system (KMS) handles keys across their life -- generation, distribution, rotation, revocation, destruction and auditing -- often backed by an HSM.
• A secure enclave is an isolated area of a processor, common in phones, that holds keys and biometric data apart from the main operating system.

What to take into the exam

• Symmetric for bulk speed, asymmetric for key exchange and identity; real protocols use asymmetric to set up a symmetric session key.
• AES, RSA at 2048+ and ECC are current; DES, 3DES, RC4 and short RSA keys are wrong answers. Key length only compares within one family.
• Ephemeral Diffie-Hellman gives perfect forward secrecy; authentication stops an attacker sitting in the middle of the exchange.
• Full-disk protects a powered-off device; file- and record-level encryption protect against people who already have access to the layer below.
• Pick TLS, SSH, IPsec, SNMPv3 and SRTP over their plaintext equivalents.
• TPM is per device, HSM is per organisation and never releases the key, KMS manages the life cycle.