pk.org: Computer Security/Lecture Notes

Integrity and Public Key Cryptography

Paul Krzyzanowski – 2026-09-19

title: Integrity Study Guide subtitle: What to know from the integrity and public key cryptography lecture author: Paul Krzyzanowski date: 2026-09-21

A hash detects change but cannot say who made it. A key added to the hash fixes that between two parties who share a secret. A key that splits into a public half and a private half fixes it for one signer and any number of verifiers. A certificate says whose key it is.

Integrity and Authenticity

Integrity means data has not been modified. Authenticity means it came from the source it claims. You need to be able to separate both from confidentiality, which hides content and does nothing to prevent change. Know that an encrypted message can still be altered in transit, and that the recipient may not notice if the data is not readable text.

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.

Know the seven properties and what each one prevents:

Be able to explain why second preimage resistance and collision resistance are different and who each one protects against. Collision resistance is the stronger requirement, because the attacker chooses both messages.

You should be able to explain why collisions must exist, using the pigeonhole principle, and why finding one is cheaper than you would guess. Searching for a second preimage takes about \(2^n\) work for an \(n\)-bit digest, while searching for any collision at all takes about \(2^{n/2}\), because every new message can be compared against every message already tried. This is the birthday problem. The design consequence is that a digest has to be twice as long as the collision resistance you want, which is why 256 bits is the current floor. The doubling applies to collisions only, since finding a preimage still costs about \(2^n\).

Know the general shape of how a hash function is built: a small function mixes each fixed-size block of the message into a running value, and the value left after the last block is the digest. You do not need the internals, but you do need this fact, because it is what makes length extension possible.

Know what hash functions are used for: verifying a transfer, naming content, committing to data now and revealing it later, storing passwords, linking records in a chain, and finding duplicates.

Finally, know where a hash stops. A published digest only helps if it reaches you through a channel the attacker does not control. An attacker who can replace a file on a download page can usually replace the digest sitting next to it, and the same applies to a digest that travels alongside the data over one connection.

Message Authentication Codes

A message authentication code (MAC), also called an authentication tag, is computed from a message and a secret key. Be able to state the two things a matching tag establishes at once: the message was not altered, and it was produced by someone holding the key. A hash gives only the first.

Know that a MAC is not encryption, that the tag can travel in the open, and that an application needing confidentiality has to encrypt separately.

Understand why hashing a key in front of a message is not a MAC. Because the digest is everything the function was holding when it finished, an attacker who has the tag can continue the calculation and produce a valid tag for a longer message without knowing the key. This is a length extension attack. HMAC avoids it by nesting two hashes, each using a differently prepared version of the key, so the value you receive is not a state anyone can resume from.

Know that a tag protects only the bytes it covers. A tag over a file says nothing about a version number sitting beside it, which is why a release is described by a signed manifest binding the product, version, and file digest together.

Understand authenticated encryption with associated data (AEAD): encryption and a tag in one operation, with the option to authenticate readable data such as a header. Know the encrypt-then-MAC rule for designs that keep the two separate, and know that these tags are what makes a stream cipher’s malleability harmless.

Be ready to explain the three limits of a shared secret, since they are what motivate everything after:

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

  2. Pairwise keys grow as the square of the number of parties, and nothing tells two strangers how to get the first one.

  3. Public software distribution breaks the model outright, because a key placed in every installation lets every customer forge updates.

Public Key Cryptography

Know the definition of a one-way function and be able to give examples: multiplication against factoring, modular exponentiation against the discrete logarithm problem, and scalar multiplication on an elliptic curve. A cryptographic hash is also one-way.

A trapdoor is secret information that makes an otherwise infeasible calculation easy, and a trapdoor function is a one-way function that has one. Know that a hash function has no trapdoor, which is why hashing alone cannot produce a key pair.

Know that the public key is published, the private key is kept secret, the pair is generated together, and the private key cannot be computed from the public key.

Be able to distinguish the three operations and say what each one does and does not give you:

For RSA, know that it builds its trapdoor from factoring and that the public and private exponents are related through the modulus, whose factors are the secret. For elliptic-curve cryptography, know that it rests on a different hard problem and reaches the same security with much smaller keys. You should be able to say roughly why a 256-bit elliptic curve key is comparable to a 3072-bit RSA modulus. For Diffie-Hellman, know that the two parties arrive at a shared secret neither transmitted, that it is not encryption, and that by itself it authenticates nobody.

Know why public key algorithms are not used for bulk data: they are orders of magnitude slower, ciphertext expands to the size of the modulus, and anyone can encrypt a guess with a public key and compare it against an intercepted ciphertext.

Digital Signatures

A digital signature is produced from a message and a private signing key and verified with the public key. Know the roles: the signer holds one key, and anyone can verify.

Understand why the signature is computed over a digest rather than the message, and understand the consequence. If an attacker can produce two documents with the same digest, a signature obtained on the harmless one also verifies for the other, which is why collision resistance, and not just second preimage resistance, is required.

Do not describe signing as encrypting with the private key. Verification checks a mathematical relationship among the message, the signature, and the public key, and several schemes have no encryption operation at all.

Know what a signature establishes and what it leaves open. It supports non-repudiation, because the recipient could not have produced it. It says nothing about who was at the keyboard if the key was stolen, and nothing about whether the message is true or the software is safe.

Certificates and Trust in a Public Key

A public key can reach you over a channel you already trust, or you can compare a key fingerprint out of band. At scale, a certificate authority checks a binding between a key and an identity and signs a statement about it. That statement is a digital certificate.

Know the fields a certificate carries and know how a certificate chain is verified: each certificate’s signature is checked with the key above it, up to a trust anchor in the trust store. Understand that a root certificate is self-signed and that its self-signature establishes nothing, since anyone can self-sign. A root is trusted because it was placed in the trust store.

Know the other checks: validity period, the name being connected to, what an intermediate is permitted to sign, revocation status, and proof that the other party actually holds the private key.

Understand why revocation works poorly. Revocation lists go stale, and online status checks leak browsing behavior, add a round trip, and are treated as passing when they fail. Know the responses: a server sending a recent signed status with the connection, shorter certificate lifetimes, and Certificate Transparency, which requires a certificate to appear in a public append-only log before browsers will accept it, so a usable certificate cannot be hidden from the owner of the name.

Signed Software and the Supply Chain

Code signing applies a signature to executable code, and the operating system verifies the signature and the certificate chain before running it. Know that secure boot extends the same idea downward, with each stage verifying the next.

Know exactly what a valid signature proves: this publisher signed these bytes, and they have not changed since. It does not prove the software is safe, and it does not prove the publisher knew what was in it.

Be able to describe the three ways a software supply chain attack reaches a signed release, and what fails in each:

  1. The signing key or certificate is compromised, in which case a cryptographic mechanism failed.

  2. The build system is compromised, in which case the cryptography is perfect and the signature is valid.

  3. A dependency is compromised, in which case the attacker became an authorized publisher and no mechanism was ever tested.

Know the defenses at the level of what each one attacks: reproducible builds let an outsider confirm a binary matches its source, provenance records describe how a binary was produced, a software bill of materials says what a product contains, transparency logs make a release public, dependency discipline limits what gets pulled in, and hardware-protected keys keep a signing key from being carried away.

Quantum Computing Attacks

Know the asymmetry, which is the whole point of this section. A quantum algorithm would break factoring and discrete logarithms, which takes out RSA, elliptic curves, and Diffie-Hellman, and larger keys do not help. Against key search and preimage search, the speedup is only a square root, which halves those security levels and is handled by using larger keys. Collision resistance is set by the birthday bound and is not affected in the same way.

Understand harvest now, decrypt later: recording encrypted traffic is cheap, so confidentiality has to be migrated before the hardware exists. A signature forged decades from now cannot retroactively change what was installed today.

Know that replacement standards exist for key establishment and for signatures, that deployment is hybrid so a connection stays secure unless both the classical and the new algorithm fall, and that one of the new signature schemes is built from hash functions alone.

What You Don’t Need to Study

You don’t need to remember the names of any of the historical figures in these notes. Know that seventeenth-century scientists published anagrams to claim a discovery without revealing it, and that this is a commitment scheme whose binding was weak.

You don’t need to remember which codebook or which telegraph company used which scheme. Know that error detection was designed against noise and fails against an adversary, who can recompute or adjust a check value.

You don’t need to remember any of the incidents by name, including the malware, the companies, or the certificate authorities involved. Know the shapes they illustrate: a broken hash function can forge a certificate, a compromised build produces a valid signature, and a compromised dependency needs no cryptographic break at all.

You don’t need to remember the names of specific hash functions beyond knowing that SHA-2 and SHA-3 are current and that older 128-bit and 160-bit functions have had their collision resistance broken.

You don’t need to do any of the arithmetic. RSA key generation, the Diffie-Hellman exchange, the elliptic curve equations, the HMAC padding constants, and everything in the appendix are there so the mechanisms are not magic. Know what each algorithm accomplishes and what problem makes it hard to reverse.

You don’t need to remember which organization publishes which standard, which company maintains which trust store, or the names of the post-quantum algorithms.

You don’t need to know the internals of a hash function’s compression step, or the details of certificate formats beyond the fields and what they are for.