Network Encryption

Network traffic crosses many devices and links that are outside the sender's and receiver's control. Without protection, an observer can read message content, while an alteration may go undetected. Passwords, payment data, and documents sent by applications need a mechanism that limits access to their content. HTTPS connections, VPN tunnels, and messaging applications can use encryption, but the protection depends on the protocol and its configuration. The location of encryption also matters: protection on the path to a server does not cover data before transmission or content available after decryption on a host.

is a mechanism that changes plaintext into ciphertext with an algorithm and a key. A receiver with the correct key can recover the plaintext. Encryption protects content confidentiality, while protocols using authenticated encryption can also detect modification. Encryption alone does not authenticate a server, hide every metadata field, or protect data after an application decrypts it. Integrity and authentication come from a signature, an authenticator, or an AEAD mode, depending on the protocol. The key must be bound to the intended party because confidentiality without authentication can permit a man-in-the-middle attack. Key exchange, certificate validation, and record protection are separate stages. A failure in one stage may remain hidden from the cipher itself, so configuration should be checked with the protocol implementation, key store, and error logs.

Core cryptographic concepts

Before choosing an algorithm, distinguish the input data, the procedure, the key, and the set of possible keys. These terms identify what a system protects and where risk can enter. A practical protocol must also define authentication, random-number generation, record format, and the response to a failed integrity check.

Plaintext and ciphertext: The original readable message is plaintext. Applying an encryption algorithm produces ciphertext that should not reveal the content without the correct key. Confidentiality depends on key secrecy and on a correct implementation of the complete protocol.
Algorithm (cipher): This is the mathematical procedure used to transform plaintext into ciphertext and back again. An algorithm can be publicly specified. Security depends on its properties, parameters, implementation, and key protection; secrecy of the procedure is not a security condition.
Key: A key is information that controls an algorithm during encryption and decryption, often represented as a bit string. It is not the same as a password. A key must be generated, delivered, and stored under key-management rules because disclosure can expose the protected data.
Key space: This is the total number of keys allowed by an algorithm. Its size affects the cost of exhaustive search, but security also depends on the cipher design and random-key generation. An 8-bit key has $2^8$ (256) possibilities. Standards and libraries use, among others, 128-, 192-, or 256-bit keys. A 128-bit key space contains $2^{128}$ possibilities, so exhaustive search is not a practical attack under correct implementation assumptions.

Symmetric and asymmetric encryption

Encryption systems use symmetric and asymmetric approaches. The difference concerns how keys are used, the computational cost, and how a secret is distributed. Many protocols use both in one connection: a public-key mechanism authenticates a party or agrees on a secret, and a symmetric cipher protects subsequent records.

Symmetric encryption

uses the same secret key for encryption and decryption. Symmetric ciphers protect large data streams efficiently because operations on blocks or streams require fewer resources than public-key operations. The selected mode defines block processing and initialization values; AEAD modes also provide integrity checking. Reusing a nonce can weaken protection even when the underlying cipher is strong.

Both parties must receive the same secret before exchanging data. The delivery channel must protect that key from reading and replacement. In a larger network, distributing a separate secret to every pair of parties increases the key inventory and requires central management.

Strength: Symmetric ciphers process large amounts of data with low computational overhead. They are therefore used for streams such as file transfers, voice, and video calls.
Weakness (the key exchange problem): Both parties must agree on a shared secret before communication. Sending the key through an unprotected channel lets an observer copy it. A protocol therefore needs protected distribution or a key-agreement mechanism.
Examples: Symmetric ciphers include AES (Advanced Encryption Standard), the obsolete DES (Data Encryption Standard), and the stream cipher ChaCha20.

Asymmetric encryption

uses a pair of mathematically related keys. Public-key cryptography was described in the 1970s and separates publication of one key from protection of the private key. In Diffie-Hellman key agreement, public values help compute a shared secret without revealing the private values. A certificate and trust chain bind a public key to a subject name. The client must validate the name, validity interval, and certificate status according to its policy. It should also reject unsupported protocol versions and cipher suites.

The public key can be distributed to many recipients. The private key remains with its owner and is used to decrypt data intended for that owner. The same pair can support digital signatures, where verification uses the public key.

The public key: It can be published and used to encrypt a message for the owner. The recipient must still verify that the received key belongs to the intended party.
The private key: It is held by the owner and enables decryption of data associated with the public key. Disclosure of the private key undermines confidentiality and signatures created with it.

Strength: Publishing the public key simplifies distribution, while certificates and PKI can bind a key to an identity. The receiving party does not need to send its private key to the other party.
Weakness: Asymmetric operations require more resources than symmetric encryption. They are therefore used for authentication and key agreement, while a symmetric cipher protects the subsequent data stream.
Examples: Asymmetric algorithms include RSA, named after Rivest, Shamir, and Adleman, and ECC (Elliptic Curve Cryptography). Elliptic-curve systems provide comparable security with shorter keys than classic RSA-based systems.

Hybrid protocols

TLS used by HTTPS and IPsec combine authentication or key agreement with symmetric data protection. This division limits the cost of asymmetric operations and protects long data streams with an AEAD cipher. In TLS 1.3, the handshake establishes parameters and secrets, while application records use keys derived by HKDF. Keys for client-to-server and server-to-client traffic are separated.

An abbreviated TLS 1.3 exchange works as follows:

The browser starts the connection, and the server presents a certificate and key-agreement parameters. The certificate contains a public key used to verify the server identity.
The parties agree on a secret with an ephemeral Diffie-Hellman mechanism such as ECDHE. TLS 1.3 does not send a ready-made session key encrypted with the server's public key.
The server signs part of the exchange. The browser checks the signature and certificate chain before accepting the server identity.
Both parties derive independent traffic keys for the two directions from the agreed secret.
For the rest of the session, they use a symmetric AEAD cipher such as AES-GCM or ChaCha20-Poly1305 to protect record content and integrity.

The hybrid protocol combines authentication and secret agreement with efficient data protection. TLS 1.3 defines this exchange in its current protocol specification. The record layer also detects tampering before plaintext is delivered. Implementations should limit protocol versions, select approved AEAD suites, validate certificate names, and handle key-compromise events through their operational procedures.

Encryption algorithms and modes

Block ciphers and modes of operation

Symmetric algorithms like AES are known as block ciphers. This means they operate on fixed-size blocks of data. AES, for instance, operates on blocks of 128 bits (16 bytes). A larger message is processed as a sequence of such blocks under the selected mode, which determines how they are combined.

Encrypting every block independently with the same key exposes repeated patterns. Identical plaintext blocks then produce identical ciphertext blocks. Block ciphers therefore use modes that define block chaining, initialization values, and integrity protection. Initialization parameters do not need to be secret, but they need the uniqueness or randomness required by the selected mode:

Cipher Block Chaining (CBC): Before encryption, a plaintext block is combined with the previous ciphertext block using XOR. The first block needs an initialization vector. CBC hides repeated patterns, but by itself it does not authenticate data or detect modification, so a separate integrity mechanism is required.
Galois/Counter Mode (GCM): GCM uses a counter and requires a nonce that is not repeated with a given key. It is an AEAD mode, so it encrypts data and computes an authentication tag. The recipient rejects a record if tag verification fails. TLS 1.3 uses AEAD ciphers including AES-GCM.

Key management

covers the full key lifecycle. NIST includes generation, distribution, use, protection, rotation, revocation, and destruction. A weakness at any stage can reduce the protection provided by the algorithm. Policy should name the key owner, permitted use, protection level, recovery procedure, and response to suspected compromise.

The main stages are:

Generation: A key needs a random generator suitable for cryptographic use. A predictable generator can allow the key to be reconstructed without breaking the cipher.
Distribution: A key should reach the intended party with protection against reading and replacement. Key agreement, certificates, and PKI are among the mechanisms used for this purpose.
Storage: Access to keys is limited with permissions, and use can be logged. In high-security environments, HSMs protect keys from direct extraction.
Lifetime and rotation: Policy defines how long a key is used, when it is changed, and how it is revoked after suspected disclosure. Rotation limits the data dependent on one key. The schedule should account for backups, backup keys, certificates, and service recovery.

Perfect Forward Secrecy and past-session confidentiality

With PFS, each session uses an ephemeral key agreement. Later disclosure of the server's long-term authentication key is then insufficient to reconstruct the secrets used by a completed session. The property applies to completed sessions that actually used ephemeral agreement and did not retain the required ephemeral secrets. It does not protect an endpoint compromised during an active connection.

comes from ephemeral Diffie-Hellman exchange, such as DHE or ECDHE. The long-term key authenticates the exchange, while the ephemeral secret derives traffic keys. Removing ephemeral secrets after the session makes recorded data harder to recover after a later server-key disclosure. PFS does not replace endpoint protection or correct protocol configuration. Certificate validation remains a separate requirement for authenticating the server. Session resumption and stored tickets also need a policy that accounts for their own secrets and lifetime.