Encryption Protects Confidentiality

If the requirement is to prevent unauthorized people from reading information, encryption is the appropriate tool. The original plaintext is transformed into ciphertext, and someone without the required key should not be able to read the original data.

Symmetric encryption uses the same secret key for encryption and decryption. It is efficient and works well when the communicating parties already have a secure way to share that secret. Its challenge is key distribution: everyone who can decrypt the data must possess the secret key. Sharing that securely is a challenge.

Asymmetric encryption separates those capabilities into a public key and a private key. Data encrypted for a recipient can be protected using the recipient's public key and recovered using the corresponding private key. This helps solve the key-distribution problem with symetric encryption, although public-key operations are generally not the mechanism used to encrypt large amounts of application data directly.

Primary Security Property

Hashing Detects Change, but Does Not Prove Authorship

A cryptographic hash function, the same mechanism used to store passwords securely, produces a fixed-size digest from input data. If the input changes, the digest should change as well. This makes hashing useful for checking whether a file or message has been altered or is the same as the original.

That is why software vendors often publish checksums for downloads. If the hash you calculate matches the hash published by a trusted source, you have evidence that the file you received is the same file represented by that published value.

A hash by itself does not prove who created the file. Anyone who can modify the file could also calculate a new hash. Integrity only becomes meaningful when the expected digest is obtained through a channel you trust.

Primary Security Property

Digital Signatures Add Identity to Integrity

A digital signature combines hashing with asymmetric cryptography. The signer creates a digest of the data and uses a private signing key to produce a signature associated with that digest. Someone with the corresponding public key can verify the signature.

Successful verification provides two important pieces of evidence: the data has not changed since it was signed, and the signature was produced using the private key associated with the public key used for verification.

Notice what is not happening: the original data does not have to be hidden. A signed driver, executable, package, or operating-system update can remain completely visible while still allowing the recipient to verify its origin and integrity.

Primary Security Properties

The Direction of Trust Is Different

One useful way to separate the two concepts is to ask which key operation must remain private.

With public-key encryption, a sender can use the recipient's public key to protect information intended for that recipient. The recipient's private key enables recovery of the plaintext. The private capability belongs to the person who is allowed to read the message.

With a digital signature, the signer uses a private key to create the signature, while anyone who has the corresponding public key can verify it. The private capability belongs to the person or organization making the claim of authorship.

The algorithms may come from the same family of cryptographic ideas, but the system is solving a different trust problem.

Real Systems Often Need Both

Confidentiality, integrity, and authenticity are separate requirements, so a system may need more than one mechanism. A message can be encrypted so unauthorized parties cannot read it and also signed so the recipient can verify its origin and detect tampering.

The important architectural habit is to identify the security requirement first and then choose the mechanism. Starting with the technology instead of the requirement makes it easy to assume that "using cryptography" automatically solves every security problem.

A Practical Example: Software Updates

Software updates are a useful example because confidentiality is usually not the primary concern. Everyone may be allowed to download the update. What matters is whether the package actually came from the expected vendor and whether it was modified after publication.

That is a signature problem. The software can remain public while the signature provides a mechanism for verifying authenticity and integrity before installation.

Encrypting the update would solve a different problem: it would restrict who could read the package. Unless secrecy is actually required, that additional property does not address the main risk.

Architectural Takeaway

Security controls should map to specific security properties. Encryption protects confidentiality. Hashing helps detect change. Digital signatures combine integrity checking with a verifiable claim tied to a signing key. Certificates and trust infrastructure then help answer another question: whether the public key itself belongs to the identity you think it does.

The technologies are related, but the design questions are distinct. A secure architecture begins by asking what must be protected and from whom.