Timedora

6 Cryptography Fundamentals

Learn how encryption, hashes, authentication mechanisms, signatures, key exchange, certificates, and key management work together to protect information.

What cryptography provides

Cryptography uses mathematical algorithms and keys to help protect information. It can help provide confidentiality, integrity, and authentication, but it does not by itself secure a system. Correct implementation, trusted identities, and careful matter just as much.

and data protection

transforms readable data, called plaintext, into ciphertext using an algorithm and a key. Decryption uses the corresponding key to recover the plaintext.

uses the same secret key for and decryption. It is efficient for large amounts of data, but communicating parties need a secure way to establish and protect their shared key.

uses a related public/private key pair. A public key may be shared, but its private key must be protected. Some asymmetric schemes support , while others support signatures or key establishment; these uses are not interchangeable.

Modern protocols commonly combine both approaches: asymmetric techniques authenticate parties and establish shared secret material, while symmetric authenticated protects the data. , such as AES-GCM, provides confidentiality and checks that encrypted data and any unencrypted associated data have not been altered. A nonce, or IV, must be generated and used according to the algorithm’s requirements.

Hashes and message authentication

A maps data of any length to a fixed-size digest. A secure hash is designed to make it impractical to recover the input from its digest, find a different input with the same digest, or find any two inputs with matching digests. SHA-2 and SHA-3 are standardized hash families. Hashing is not : a digest cannot be decrypted to reveal the original message.

A plain hash can help detect accidental changes if the expected digest is trusted. It does not prove who created the data, because an attacker who can replace both the message and digest can recompute the digest.

A uses a shared secret key to authenticate data and detect tampering. For example, a service and client that share a key can use a MAC to check that a message came from someone who knows that key and was not modified.

Password storage is a separate use case. Do not store passwords as plaintext or as a single fast hash. Use a password-hashing scheme designed to resist guessing, with a unique salt per password and appropriate work factors.

Digital signatures

A is generated with a private signing key and checked with the corresponding public key. In common schemes, the signing process includes hashing the message. A valid signature helps verify that the signed data has not changed and that it was signed using the matching private key. It does not encrypt the data, and it identifies a person or organization only if the public key has been reliably associated with that identity.

For example, a software publisher can sign a release. A user’s system checks the signature with the publisher’s trusted public key; is not needed for this integrity and origin check. A is not automatically proof that a named human personally approved something. That conclusion depends on how the signing key is controlled and how identity is established.

and derived keys

, also called key agreement, lets parties establish shared secret material over a communication channel. Diffie–Hellman and elliptic-curve Diffie–Hellman are widely used examples. The resulting shared secret is generally input to a to produce keys for specific purposes.

alone does not authenticate the parties. Without authentication, an attacker may establish separate keys with each party and relay or alter their communication.

TLS 1.3 illustrates how these mechanisms can work together: peers negotiate parameters and establish shared secrets, authenticate the handshake using certificates and signatures or another supported method, and derive traffic keys for protected communication. Ephemeral Diffie–Hellman can provide : later compromise of a long-term authentication key does not, by itself, reveal previously recorded session traffic, provided ephemeral secrets and session keys were handled and erased appropriately.

Certificates and trust

A is a digitally signed statement that associates a public key with a subject, such as a website name or organization. In the common X.509 public-key infrastructure, a certificate authority (CA) signs certificates, and a client checks a chain of certificates back to a trust anchor it accepts. Validation also considers details such as the requested name, validity period, and permitted uses.

A certificate does not make a website safe or guarantee that its operator is honest. It helps a client authenticate that it is communicating with the entity named in a valid certificate, according to the client’s trust and validation rules. A certificate’s public key is not secret; its authenticity and correct use are what matter.

Managing keys throughout their lifecycle

covers the key’s full lifecycle: generation, establishment or distribution, storage, use, backup where appropriate, rotation or replacement, revocation when needed, and destruction. Cryptographic strength depends on protecting keys as well as on the algorithms.

Sound practices include:

  • Generate keys with cryptographically secure random-number generators.

  • Restrict access to secret and private keys; use protected hardware or managed key services where appropriate.

  • Use different keys for different purposes, and establish clear ownership, expiration, rotation, and recovery procedures.

  • Keep keys and backups protected, and securely revoke or destroy keys that are compromised or no longer needed.

  • Never hard-code secrets in source code or send private keys as if they were public certificates.

How the mechanisms fit together

protects confidentiality; hashes produce fixed-size digests; MACs authenticate data using a shared secret; and digital signatures support integrity checks and public-key authentication. establishes shared secret material, while KDFs derive purpose-specific keys. Certificates bind public keys to identities through a trust system. These mechanisms are effective only when used in suitable protocols and supported by careful .