1.3.1 - Encryption and hashing

Recovering data from ciphertext

Encryption transforms readable plaintext into ciphertext using an algorithm and a key.

Imagine a clinic sending an appointment message to a patient. An interceptor may obtain the transmitted bytes; confidentiality means they should not be able to read the message. Encryption changes the representation so that the authorised recipient can recover the plaintext using the appropriate key. The key is data that controls the transformation. Keeping the algorithm secret is not the foundation of a well-designed modern cryptographic system; protecting the key is essential.

A simple classroom substitution helps distinguish representation from meaning: shifting each letter three positions makes CAB become FDE; shifting back recovers CAB. This is a reversible toy, not secure modern encryption, because an attacker can try the few possible shifts. Practical cryptography uses carefully analysed algorithms and much larger key spaces. We are reasoning about the keys and purposes, rather than treating this toy as a deployable system.

If the clinic must later show the appointment text to the patient, storing only a hash cannot meet that requirement. Encryption alone also does not automatically establish who sent a message or whether it was altered: appropriate authentication or integrity mechanisms are needed.

Sharing one symmetric secret

Symmetric encryption uses the same secret key to encrypt and decrypt data.

If A encrypts a file with key K, B needs K to decrypt it. Possessing ciphertext without K should not be enough to recover the plaintext with a secure algorithm. Symmetric methods are efficient for large amounts of data, making them suitable for encrypting a stored backup or the main data stream of a secure connection. A single organisation encrypting its own backup does not have to send its key to a remote recipient, although it still needs secure key storage and recovery procedures.

Key distribution becomes a problem when A and B have never shared a secret. Sending K openly alongside the encrypted file lets an interceptor read the key and decrypt the file. They need an already protected channel or a secure key-establishment method. If several recipients all share K, any holder can decrypt data protected by K; a compromised holder affects the entire group. Separate keys can limit that exposure but increase key-management work. Losing the only copy of K can also make the organisation's own data inaccessible.

Using a public and private key pair

Asymmetric encryption uses a mathematically related pair: a public key which can be shared and a private key which its owner keeps secret.

For confidentiality, a sender encrypts for B using B's public key, and B decrypts with B's corresponding private key. A does not need B's private key. Publishing B's public key therefore does not let everyone decrypt B's incoming ciphertext. Encrypting a message for B using A's public key would be the wrong choice: it would be recoverable using A's private key, not B's.

There is still an identity problem. If an attacker persuades A to use the attacker's public key while claiming that it belongs to B, the attacker can decrypt the message. A needs a trustworthy way to establish whose key it is, such as a correctly verified certificate. Asymmetric cryptography also supports digital signatures for origin/integrity checking; signing is a distinct operation, not simply a confidentiality message sent using the wrong key. Detailed certificate/signature algorithms are background here, not a new requirement to implement them.

Compared with symmetric methods, asymmetric operations are generally more computationally expensive for bulk data. A practical hybrid approach establishes or protects a symmetric session key using asymmetric cryptography, then encrypts the large data stream symmetrically. This combines the useful public-key distribution property with efficient bulk encryption. Neither method eliminates the need to protect devices and private/secret keys.

Checking values without decrypting them

A hash function deterministically maps input data to a hash value, which is used differently depending on the application.

A cryptographic hash produces a fixed-length digest for inputs of different lengths and is designed to make finding an input from its digest, or finding two inputs with the same digest, computationally difficult. Different inputs can nevertheless share a digest: there are more possible inputs than fixed-length outputs. This is a collision, so matching digests are strong evidence under suitable cryptographic assumptions, not mathematical proof of identical arbitrary files. Hashing is not reversible encryption. An attacker may still guess an input, hash the guess and compare it with the stored value.

Verifying a password

A service should not need to recover a user's password. At registration, it stores a salted password hash; at login it applies the same password-hashing procedure to the entered password and stored salt, then compares results. A salt is a per-password random value stored with the hash. It causes the same password with different salts to produce different stored results and reduces reuse of precomputed guesses. The salt is not a secret decryption key. Real password storage uses an appropriately costly password-hashing scheme, rather than a fast general-purpose digest alone, to make large-scale guessing harder. A weak guessed password is still weak.

Checking a file

A publisher can provide a digest of a download. The recipient recomputes the digest and compares it to detect a changed or corrupted file. If an attacker can replace both the file and its advertised digest, a match does not authenticate the publisher. The expected digest must come from a trusted source, or be protected by a suitable authentication mechanism.

Locating a record

A non-cryptographic hash may map a record key to a small table index for efficient lookup. For the toy rule index = identifier MOD 10, identifiers 27 and 47 both map to slot 7. The table therefore needs collision handling, such as keeping both records in a chain at slot 7 and checking their full identifiers when searching. This indexing hash need not have cryptographic security; its job differs from a password hash or file digest.