Hashes detect changes when the expected digest is trusted. Message authentication codes and digital signatures also connect data to a key holder, while certificates help establish whose public key is being used. Focus on what each mechanism establishes, what it leaves unprotected, and which trust assumptions it requires.

Integrity and Authenticity

• Integrity ensures that data has not been modified.

• Authenticity verifies that data came from the source it claims.

• Confidentiality hides content. Encryption alone does not guarantee integrity, so an encrypted message can be altered without the receiver detecting the change unless the system also checks integrity.

Hash Functions

A cryptographic hash function maps a message of any length to a fixed-size digest. It is public and takes no key, so anyone can compute it.

Be able to recognize and define these properties and explain their purpose:

• Fixed-length output means the digest has the same size regardless of the input’s length. This makes it inexpensive to store, publish, or sign, but also means collisions must exist.

• Determinism means the same input always produces the same digest, allowing repeated calculations to be compared.

• Preimage resistance means that given a digest, finding any input that produces it is infeasible. It is not a guarantee of secrecy, since guessable inputs can be found by hashing candidates.

• Second preimage resistance means that, given one message, finding a different message with the same digest is infeasible.

• Collision resistance means finding any two different messages with the same digest is infeasible, even when the attacker chooses both.

• Avalanche means even a one-bit change alters about half the digest bits on average, unpredictably.

• Efficiency means computing a digest is fast, with work roughly proportional to the input’s length.

Second preimage resistance protects an existing message against substitution. Collision resistance also prevents an attacker from preparing two messages with matching digests in advance, obtaining approval for one, and substituting the other. It is the stronger requirement because the attacker chooses both messages.

Collisions must exist because there are more possible messages than fixed-size digests. This is the pigeonhole principle. The requirement is that finding a collision be infeasible, not that collisions never occur.

For a well-designed hash with an \(n\)-bit digest, a brute-force search on a non-quantum computer takes about \(2^n\) attempts to find a preimage or second preimage. Weaknesses in a particular hash function can allow faster attacks.

Finding any collision takes about \(2^{n/2}\) attempts, because each new digest can be compared against every digest already computed. This is the birthday problem. To obtain 128 bits of collision resistance, a hash therefore needs a 256-bit digest. This doubling applies only to collision resistance.

SHA-256 processes fixed-size blocks, mixing each block into a running value. Its final digest exposes the state needed to continue that calculation. This property enables the length-extension attack described below.

Hash functions are used to verify transfers, name content, commit to data, store passwords, link records, and find duplicates. A hash-based commitment binds an author to data to be revealed later. Concealing guessable data also requires adding secret randomness. Password storage uses deliberately expensive hashing to slow guessing.

A digest detects hostile substitution only when the expected digest is trustworthy. An attacker who can replace both a file and its published digest can make the receiver’s hash check pass.

Message Authentication Codes

A message authentication code (MAC), also called an authentication tag, is computed from a message and a secret key. A matching tag provides evidence that a key holder authenticated the message and that its bytes have not changed. A hash alone does not provide sender authentication, and checking integrity with a hash requires a trusted expected digest.

A MAC does not provide confidentiality. The tag can travel in the open, and the message remains readable unless it is also encrypted.

A length extension attack continues a hash calculation from an existing digest. With SHA-256, this makes hashing a secret key followed by the message an insecure MAC construction. An attacker who has the tag and knows or guesses the combined input length can calculate a tag for an extended message without knowing the key. The extension must account for the hash function’s padding.

HMAC is a hash-based MAC that avoids this attack by nesting two hashes, each using a differently prepared version of the key (XORing the key with two different values). The inner hash hashes the key and the message. The outer hash is then applied over a key-derived block followed by the fixed-length inner digest. Continuing a hash calculation from the tag therefore does not produce a valid HMAC for a longer message.

A tag protects only the bytes included in its calculation. A manifest is a structure that contains data about the content, such as a product name, version, and file digest. Authenticating the manifest with a MAC or a signature binds those fields together, allowing changes to the release information to be detected.

Authenticated encryption with associated data (AEAD) combines encryption and authentication, including protection for associated data that remains readable. When encryption and a MAC are separate, encrypt-then-MAC authenticates the ciphertext so a receiver can reject a forgery before decrypting it. Authentication tags protect against ciphertext modification only if the receiver rejects messages whose tags fail before using the plaintext.

Shared secrets have three limitations that are relevant here:

1. Either key holder could have produced any valid tag, so a MAC gives no non-repudiation.

2. The number of pairwise keys grows quadratically with the number of parties (every pair of users needs a secret key). Each pair also needs a way to establish its initial secret securely.

3. A MAC key placed in every software installation allows anyone who extracts it to forge updates accepted by the other installations.

Public Key Cryptography

A one-way function is easy to compute and computationally infeasible to reverse. Example calculations include multiplying large primes versus factoring their product, modular exponentiation versus recovering the exponent, and elliptic curve point multiplication versus recovering the secret multiplier. Recovering the exponent is the discrete logarithm problem. Preimage resistance gives a cryptographic hash its one-way property.

A trapdoor is secret information that makes reversing a one-way function efficient. A one-way function with this property is a trapdoor function. Trapdoors provide one approach to public-key cryptography, but key agreement and signatures can use other constructions. Hash-based one-time signatures can use random secrets as a private key and their digests as the public key, without reversing the hash function.

A public-key scheme generates a mathematically related pair of keys. The public key can be distributed freely, while the private key remains secret. Recovering the private key from the public key must be computationally infeasible.

Distinguish the three public key cryptographic operations:

• Public-key encryption gives confidential delivery to one recipient, but it does not identify the sender.

• A digital signature gives publicly verifiable authentication, and it leaves the message readable.

• Key agreement establishes a shared secret, but by itself does not authenticate the participants.

The main public-key methods we covered are:

• RSA uses modular exponentiation with a modulus formed from two secret prime factors. Knowing those factors allows the private exponent to be calculated.

• Elliptic-curve cryptography (ECC) relies on the difficulty of the elliptic curve discrete logarithm problem. It provides comparable security to RSA with smaller keys: a suitably chosen 256-bit ECC key and a 3072-bit RSA modulus each provide about 128 bits of security against non-quantum attacks.

• Diffie-Hellman provides key agreement, letting two parties calculate the same shared secret without transmitting it. It does not encrypt their messages. Recovering a participant’s secret exponent from its public value is a discrete logarithm problem. The exchange requires a separate way to authenticate the participants.

Public-key operations cost much more than symmetric encryption, so systems use them to establish keys and sign messages. Symmetric ciphers handle bulk data. Secure RSA encryption expands each plaintext block to a ciphertext block the size of its modulus. Common symmetric modes add only a small, bounded overhead per message.

The textbook version of RSA has separate security weaknesses. Its deterministic encryption lets attackers test plaintext guesses, and its mathematical structure permits predictable changes to ciphertext. Later enhancements added randomized encoding to address these attacks.

Digital Signatures

A digital signature is produced from a message and a private signing key. Anyone with the corresponding public key can verify it without gaining the ability to create signatures. Signatures provide three interfaces:

• public, private = generate_keys; create a private signing key and a corresponding verification key.

• signature = sign(digest, private): sign a hash of a message with the signing key.

• true/false = verify(digest, signature, public): verify the signature, against the digest of the message you have using the public key.

Hashing allows signature algorithms to process long messages efficiently (do a hash and then run the hash through the signing or verification functions). A signature can also verify for another message with that digest, which is why it is important that collision resistance must prevent an attacker from choosing two such messages in advance, obtaining a signature on one, and substituting the other.

Signing is conceptually similar, but not the same as encrypting with the private key for all signing algorithms. Verification checks a mathematical relationship among the message, the signature, and the public key. Several signature schemes have no corresponding encryption operation.

A signature supports non-repudiation because a recipient holding only the public key cannot produce it. Attribution still depends on how the private key was protected and whose key it is. A signature cannot identify who used a stolen key or establish that a message is true or software is safe.

Certificates and Trust in a Public Key

A public key can be obtained through an already trusted channel. A key fingerprint is a hash of a public key. Comparing it with a fingerprint obtained from an independently trusted source helps confirm that the correct key was received. However, these trusted communication channels often do not exist (for example, when accessing a website).

A certificate authority (CA) issues a digital certificate, a signed data structure that binds a public key to an identity. It is a trusted third party: an organization trusted to do the appropriate identity verification before issuing a certificate. For a website certificate, domain validation establishes control of the domain name, not that the website is honest or safe. A few of the important fields in a certificate are:

• Subject: the name (organization name, domain name, personal name)

• Public key: the subject’s public key

• Validation period: earliest and latest times the certificate should be used

• CA: the name of the organization that signed this data and vouches that the public key belongs to this subject

• CA signature: the signature of the CA (created with the CA’s private key)

A certificate chain links a certificate through its issuers to an already accepted trust anchor, usually a root certificate in a trust store. Each certificate’s signature is checked using its issuer’s public key. Root certificates are commonly self-signed, but their self-signatures do not establish trust. That trust comes from an independent decision to accept the root.

Certificate validation also checks the validity period, requested domain name, authority of intermediate CAs, and applicable revocation requirements. The server must demonstrate possession of the matching private key, since anyone can copy a public certificate.

Certificates expire, but they may have to be revoked if the subject’s private key has been leaked. A certificate revocation list (CRL) contains a list of revoked certificates from a given CA. This list can be large and become stale between updates. The Online Certificate Status Protocol (OCSP) checks individual certificates, but issuing direct queries adds delays and can reveal browsing activity. Some clients also choose to simply continue if a status check is unavailable, allowing an attacker who blocks the query to suppress that check.

Locally distributed revocation information also avoids a separate client query. Shorter certificate lifetimes limit exposure but do not eliminate the need for revocation.

Signed Software and the Supply Chain

Code signing uses digital signatures to authenticate software and detect changes to its signed content. Verification may be performed by an operating system, installer, or package manager, according to the platform’s policy. The verifier also establishes trust in the signing key, often through a certificate chain.

Secure boot checks boot components before they execute, starting from a key protected by firmware or hardware and continuing through later startup stages.

A valid signature shows that the signed bytes have not changed and were authenticated with the corresponding private key. It does not prove that the software is safe or that the publisher reviewed the exact code being signed. A stolen key can also produce valid signatures.

A software supply chain attack can reach a signed release through several routes:

1. An attacker steals a signing key or obtains a fraudulent certificate. Key theft can leave the cryptographic algorithm unbroken. A fraudulent certificate can result from a broken hash or a compromised CA.

2. An attacker compromises the build system and causes the publisher’s legitimate signing process to authenticate malicious output.

3. An attacker alters a dependency that becomes part of the finished software. The publisher can then sign the affected release without any failure of the signature algorithm.

Defenses address different parts of the release process:

• Reproducible builds produce identical output from the same source and specified build environment. Independent rebuilds can expose differences in a release, but cannot establish that its source is safe.

• Signed provenance records identify the source, tools, and inputs used to build a release. Their value depends on the trustworthiness of the records and the process producing them.

• A software bill of materials (SBOM) lists a product’s components, helping identify affected products when a vulnerable dependency is discovered.

• Public release logs make releases visible to outside monitors, helping expose secretly targeted updates.

• Dependency review limits unnecessary packages, records their versions, and checks changes before accepting updates.

• Hardware-protected keys resist export. Access controls must also restrict which releases the signing service is allowed to sign.

Quantum Computing Attacks

A sufficiently capable quantum computer could solve the factoring and discrete logarithm problems used by RSA, ECC, and Diffie-Hellman. Increasing their key sizes is not a practical long-term defense.

A generic quantum search can reduce an ideal search through \(2^n\) possibilities to roughly \(2^{n/2}\) steps. This applies to symmetric key searches and hash preimage searches. Larger keys and digests can easily compensate for that speedup. A 256-bit symmetric algorithm will provide 128 bits of security if a quantum computer is eventually built that can do such searches.

Harvest now, decrypt later (HNDL) describes recording encrypted traffic for decryption after a capable quantum computer becomes available. Data that must remain confidential for many years needs protection before that happens. Signatures also need a migration plan so long-lived devices can continue rejecting forged software updates.

Post-quantum cryptography uses constructions intended to resist both classical and quantum attacks. Standards exist for key establishment and digital signatures, including a signature scheme built from hash functions.

Protocols can use hybrid key establishment, combining a classical method with a post-quantum method and deriving a key from both results. With a properly designed combination, the shared secret remains protected if at least one method resists the attack.

What You Don’t Need to Study

The following details are not required for the exam:

• Names of historical figures need not be memorized. Understand that scientists used anagrams to commit to discoveries before revealing them, but the method provided weak hiding and weak binding.

• Telegraph codebooks and the calculations behind CRCs, parity, check digits, and other error-detection codes are outside the required material. Distinguish accidental corruption from deliberate changes by an attacker who can recompute or preserve a check value.

• Incident names, malware names, and the organizations involved need not be memorized. Understand the attack patterns they illustrate, including key theft, certificate forgery, build compromise, and malicious dependencies.

• Individual hash-function names need not be memorized beyond recognizing SHA-2 and SHA-3 as current families. Some older 128-bit and 160-bit hashes have design weaknesses that allow collision attacks faster than the generic birthday search.

• No arithmetic is needed. This includes RSA key generation, Diffie-Hellman calculations, elliptic curve equations, and any of the calculations in the appendix in the notes. Focus on what each algorithm accomplishes and the assumptions its security depends on.

• You don’t have to know HMAC padding or the values that are XORed with the key for inner and outer digests.

• Names of standards organizations, the companies maintaining particular trust stores, and the names of post-quantum algorithms need not be memorized.

• Hash compression internals and detailed certificate formats are excluded. Understand the roles of the main certificate fields (subject, public key, issuer, and issuer’s signature), along with the validation checks described above.

• All the fields in a certificate (just know the main ones listed above).

• Certificate transparency

• Names of any of the post-quantum cryptographic algorithms