4 Cryptography Basics

What cryptography protects

Cryptography uses mathematical algorithms and keys to protect information. Its central goals are confidentiality, integrity, and authentication: keeping data secret, detecting unauthorized changes, and establishing who or what is communicating. Achieving these goals depends on sound algorithms, correct implementation, and careful key management.

A useful starting point is to distinguish the protection each cryptographic tool provides. Encryption primarily supports confidentiality; hashes can help detect changes; and message authentication codes or signatures can support integrity and authentication.

Encryption and key types

Encryption transforms readable plaintext into ciphertext using an algorithm and a key. Decryption uses the appropriate key to recover the plaintext. For example, a messaging app can encrypt a message so that someone who intercepts the ciphertext cannot readily read it without the key.

Encryption alone does not necessarily detect tampering. Systems often use authenticated encryption, which combines confidentiality protection with an integrity check.

Two ways to use keys

In symmetric cryptography, the same secret key—or closely related key material—is used for encryption and decryption. The sender and recipient must both obtain the key securely and keep it secret. This approach is efficient for protecting large amounts of data. AES is a widely used symmetric block cipher.

For example, Alice can encrypt a file with a secret key she shares with Bob, and Bob can use that key to decrypt it. Securely sharing and protecting the key is the main challenge.

In asymmetric cryptography, also called public-key cryptography, a mathematically related public key and private key are used. The public key can be shared, but the private key must be protected. For public-key encryption, a sender encrypts for Bob using Bob’s public key, and Bob decrypts with his private key. Public-key methods can also support key establishment and digital signatures, depending on the algorithm.

Public-key operations are generally less efficient for bulk data. Secure connections therefore often combine approaches: a handshake establishes shared key material, then symmetric encryption protects the connection’s data. TLS 1.3 is an example of this design.

Takeaway: Symmetric encryption is efficient when parties have a shared secret; asymmetric cryptography can help establish trust or shared secrets without first distributing that secret.

Hashing and its limits

A cryptographic hash function maps data of any length to a fixed-length value called a hash or digest. A small change to the input should produce a different digest. It should also be computationally infeasible to find an input matching a chosen digest or to find two inputs with the same digest. The SHA family is specified in NIST’s Secure Hash Standard.

Hashes can help detect changes and are used in other cryptographic operations. However, a hash is not encryption: it is not designed to be decrypted. An unkeyed hash alone also does not authenticate the source. If an attacker changes a message, the attacker may calculate a new hash for the altered message as well.

To authenticate data, systems can use a keyed message authentication code (MAC) or a digital signature. Password storage has a separate requirement: use a password-hashing scheme designed to be slow and salted, rather than storing plain passwords or relying on a fast general-purpose hash alone.

Takeaway: A hash is a fixed-length fingerprint useful for detecting changes, not a way to conceal data or prove its origin by itself.

Signatures and certificates

A digital signature is created with a signer’s private key and checked with the corresponding public key. Verification can provide evidence that the signed data has not changed and that the signature was made with the private key corresponding to that public key. Signature algorithms commonly operate on a digest of the data; if the data changes, verification should fail.

A signature does not encrypt the data, so it does not provide confidentiality. It can support accountability, but it does not by itself prove a person’s real-world identity or make denial impossible. Those conclusions depend on how the public key is bound to the signer and how the private key is controlled.

A digital certificate helps make that identity connection by binding an identity, such as a website’s domain name, to a public key. In common public-key infrastructure (PKI), a certificate authority (CA) signs the certificate. A verifier checks the signature and path to a trusted CA, along with details such as the name, validity period, and intended use.

When a browser connects to a website over TLS, it checks whether the certificate is valid for the requested domain and chains to a trusted authority. TLS then uses a handshake to authenticate the connection and establish keys for protecting data. A certificate does not encrypt traffic by itself; it helps verify the identity claimed for a public key.

Takeaway: Signatures help verify data and its cryptographic origin; certificates help connect public keys to identities. Neither one, by itself, encrypts the data.

Putting the tools together

Cryptographic systems depend on more than the choice of algorithm. Use established protocols and reputable, maintained software rather than inventing algorithms. Protect private and symmetric keys, limit who can access them, and plan for rotation, backup, and compromise.

Choose tools according to their purpose:

• Use encryption for confidentiality.

• Use hashes to help detect changes.

• Use MACs or signatures when authentication and integrity are needed.

• Validate certificates rather than merely accepting them; an unverified public key might belong to an impostor.

The tools work best in combination: a protocol can use certificates to check identities, asymmetric methods to establish shared key material, and symmetric encryption to protect bulk data. Sound key management and implementation remain essential throughout.