Cryptography Fundamentals

Cryptography fundamentals. This is a heavily tested area, and most of the marks come from keeping a few distinctions straight.

The scene. A developer tells you the passwords in the database are encrypted, and that the same system provides message integrity and proves who sent what, all with one shared key everyone has. Three different cryptographic ideas have been blurred into one. Passwords should be hashed, not reversibly encrypted; integrity and sender-proof come from different mechanisms; and a key everyone shares cannot prove who did anything.

So what does cryptography provide. Three different things, and it helps to name them. Confidentiality, keeping data secret, through encryption. Integrity, detecting whether data has changed, through hashing. And authentication and non-repudiation, proving who sent something, through digital signatures. No single mechanism provides all of these.

Encryption comes in two forms. Symmetric encryption uses one shared secret key to both encrypt and decrypt. It is fast, which suits bulk data, but it has a key-distribution problem: the secret has to be shared with every party securely. Asymmetric encryption uses a public-private key pair. What one key locks, only the other can unlock. This solves distribution, the public key can be published openly, but it is slower.

So the shortcut is: one shared key, or a key pair. In practice systems combine them, asymmetric to exchange a key securely, then symmetric for the bulk of the data. When a question contrasts them, symmetric is one shared key, asymmetric is a key pair.

Now the most reliable trap in this area: hashing is not encryption. A hash is a one-way function. It turns any input into a fixed-length value, the same input always produces the same hash, and any change to the input changes the hash. That lets you detect alteration, which is integrity.

But a hash is not encryption. You cannot reverse it to recover the original data, and it provides no confidentiality, the hash is not a hidden version of the input. This is precisely why passwords are hashed, not encrypted: the system never needs to recover the password, only to check whether a login attempt hashes to the same value. When a question asks what hashing provides, it is integrity, and the giveaway that it is not encryption is that it cannot be reversed.

Non-repudiation, a sender being unable to deny they sent something, comes from a digital signature created with the sender’s private key. Because only the sender holds that key, only they could have produced the signature, so they cannot credibly deny it, and the recipient, verifying with the sender’s public key, also confirms the message is authentic and unaltered.

And a shared symmetric key cannot provide non-repudiation, because both parties hold the same key, so either could have produced the result and neither is uniquely bound to it. This is why the developer’s single shared key fails at proving who sent what. It cannot prove who.

So the developer’s one-thing-does-everything is wrong. Confidentiality, integrity and non-repudiation come from different tools, and non-repudiation in particular needs a private key only one party holds.

Think of the three properties as hide, verify, bind. Encryption hides data. Hashing verifies integrity. Signatures bind an action to one identity. Match the mechanism to the goal, and the questions get easy.

So carry this away. Hashing is one-way and gives integrity, encryption is reversible and gives confidentiality, and passwords are hashed precisely because they should never be recoverable. And non-repudiation comes from a private-key digital signature, never from a key that everyone shares.