Cryptographic goals

Choose the security property

Separate confidentiality, integrity, authenticity, and non-repudiation before selecting a cryptographic operation.

Cryptography solves specific problems. Before you pick a tool, name the problem. The property you need picks the operation for you.

There are four properties you will meet again and again. Confidentiality hides content from anyone without the key. Integrity tells you the data changed. Authenticity tells you who created or approved a message. Non-repudiation goes one step further: the creator cannot later deny producing it. That last one is what digital signatures add over shared-secret authentication.

They sound similar. They are not. Mixing them up is where real systems break.

Why the property comes first

Take a payroll file. We encrypt it before uploading it, but nobody checks who created it. The contents stay private. Then an attacker replaces the file with different encrypted bytes, and nobody notices.

Confidentiality worked. Integrity and authenticity were never asked for, so we never got them. The encryption did exactly what we told it to do, and nothing more.

Each property maps to a different operation:

confidentiality  -> encryption (with a key)
integrity        -> hash comparison against a trusted digest
authenticity     -> MAC (shared secret) or signature (private key)
non-repudiation  -> digital signature only

Notice the difference between a MAC and a signature. A MAC gives authenticity between two parties that share a secret. Either of them could have produced it, so it proves nothing to a third party. Only a signature gives you non-repudiation.

Some designs need several properties at once. An encrypted session cookie needs confidentiality and authenticity together. That is why authenticated encryption exists as a single construction, and we’ll get to it in a later module.

What cryptography does not give you

Availability and authorization are not cryptographic properties. Encrypting a document does not decide who is allowed to request decryption. A valid signature does not mean the signed action is allowed right now.

Name those needs separately. Solve them with access control, not with more encryption. Adding a second layer of encryption to fix an authorization bug is a mistake I see often.

My advice is to write the property down before you touch any API. One line is enough:

this backup needs confidentiality against whoever steals the disk,
and integrity so we notice tampering on restore

That sentence names the property and the attacker. Once you have it, the rest of this course tells you which operation to reach for.

Try this on your own: write the required properties for a private note, a software installer, a session cookie, and a payroll upload. For each one, name the attacker and the evidence the control produces. Then find the case where confidentiality does not matter but authenticity does. The installer is a good candidate. Its contents are public, but you care a lot about who built it.

Lesson completed