Encryption Standards

This reference specifies cryptographic requirements for protecting data confidentiality and integrity. Use it to select algorithms, determine key lengths, configure protocols, and verify compliance of existing implementations.

Symmetric Encryption

Symmetric encryption uses identical keys for encryption and decryption. The sender and recipient must both possess the same secret key, making key distribution the primary operational challenge.

Approved Algorithms

Algorithm	Mode	Key Length (bits)	Status	Use Cases
AES	GCM	256	Required	Data at rest, TLS, file encryption
AES	GCM	128	Permitted	Legacy systems, performance-constrained
AES	CBC	256	Permitted	Legacy compatibility only
AES	CBC	128	Permitted	Legacy compatibility only
ChaCha20	Poly1305	256	Permitted	Mobile, low-power devices

AES-GCM provides authenticated encryption, combining confidentiality with integrity verification in a single operation. The 256-bit key length provides a security margin against future cryptanalytic advances and quantum computing threats. AES-128 remains cryptographically secure for current threat models but offers less margin.

Galois/Counter Mode (GCM) produces a 128-bit authentication tag alongside ciphertext. Verification failure during decryption indicates tampering or corruption. Never ignore authentication tag verification failures.

Cipher Block Chaining (CBC) requires separate integrity protection through HMAC or similar mechanisms. New implementations must use GCM; CBC remains permitted only for interoperability with systems that cannot be upgraded.

ChaCha20-Poly1305 provides equivalent security to AES-256-GCM with better performance on devices lacking AES hardware acceleration. ARM processors without ARMv8 cryptographic extensions benefit from ChaCha20.

Prohibited Algorithms

Algorithm	Reason	Migration Deadline
DES	56-bit key breakable in hours	Immediate removal
3DES	64-bit block size enables Sweet32 attack	31 December 2025
RC4	Statistical biases enable plaintext recovery	Immediate removal
Blowfish	64-bit block size, limited key schedule	Immediate removal

Systems using prohibited algorithms require documented remediation plans with executive approval for any operation beyond migration deadlines.

Asymmetric Encryption

Asymmetric encryption uses mathematically related key pairs: a public key for encryption and a private key for decryption. The public key can be freely distributed; the private key must remain confidential.

Approved Algorithms

Algorithm	Key Length (bits)	Status	Use Cases
RSA	4096	Required	New implementations
RSA	3072	Permitted	Existing systems
RSA	2048	Permitted until 2030	Legacy only
ECDSA	P-384	Required	Digital signatures
ECDSA	P-256	Permitted	Performance-constrained
ECDH	P-384	Required	Key agreement
ECDH	P-256	Permitted	Performance-constrained
Ed25519	256	Permitted	Signatures, SSH keys
X25519	256	Permitted	Key agreement

RSA key sizes reflect the computational cost of factoring large integers. A 2048-bit RSA key provides approximately 112 bits of security; 3072-bit provides 128 bits; 4096-bit provides approximately 140 bits. The security level indicates the equivalent symmetric key strength.

Elliptic Curve Cryptography (ECC) achieves equivalent security with shorter keys. A 256-bit elliptic curve key provides approximately 128 bits of security, comparable to 3072-bit RSA. The P-384 curve provides approximately 192 bits of security.

Curve25519 implementations (Ed25519 for signatures, X25519 for key exchange) use a curve designed to resist implementation errors. These algorithms provide 128 bits of security with consistent performance characteristics that reduce timing side-channel risks.

Key Length Equivalence

Security Level (bits)	Symmetric	RSA	Elliptic Curve
112	3DES (deprecated)	2048	P-224 (deprecated)
128	AES-128	3072	P-256, Curve25519
192	AES-192	7680	P-384
256	AES-256	15360	P-521

Select key lengths based on the sensitivity and retention period of protected data. Data retained beyond 2030 should use 256-bit symmetric or P-384 elliptic curve equivalents to provide margin against cryptanalytic advances.

Prohibited Configurations

Configuration	Reason	Migration Deadline
RSA-1024	Factorable with moderate resources	Immediate removal
RSA-512	Factorable in hours	Immediate removal
ECDSA P-192	Below minimum security threshold	Immediate removal
DSA	Limited to 1024-bit in many implementations	Immediate removal

Hash Functions

Cryptographic hash functions produce fixed-length digests from arbitrary input. Secure hash functions resist collision attacks (finding two inputs with identical output) and preimage attacks (finding an input producing a specific output).

Approved Functions

Algorithm	Output (bits)	Status	Use Cases
SHA-256	256	Required	General purpose
SHA-384	384	Permitted	High-security contexts
SHA-512	512	Permitted	High-security contexts
SHA3-256	256	Permitted	New implementations
BLAKE2b	Up to 512	Permitted	Performance-critical
BLAKE3	256	Permitted	High-throughput

SHA-256 provides 128 bits of collision resistance, sufficient for all current applications. SHA-384 and SHA-512 provide additional security margin for long-term protection requirements.

SHA-3 uses a fundamentally different construction (Keccak sponge) than SHA-2. This provides defence-in-depth: a cryptanalytic breakthrough against SHA-2 would not automatically compromise SHA-3.

BLAKE2 and BLAKE3 offer higher performance than SHA-2 while maintaining equivalent security. BLAKE3 parallelises across multiple cores, achieving throughput exceeding 10 GB/s on modern processors.

Password Hashing

Password storage requires specialised functions designed to be computationally expensive, resisting brute-force attacks against stolen password databases.

Algorithm	Parameters	Status
Argon2id	Memory: 64 MB, Iterations: 3, Parallelism: 4	Required for new systems
bcrypt	Cost factor: 12 minimum	Permitted
scrypt	N: 2^15, r: 8, p: 1	Permitted
PBKDF2-SHA256	600,000 iterations minimum	Legacy only

Argon2id combines resistance to GPU-based attacks (through memory-hardness) with resistance to side-channel attacks. The parameters specify 64 MB of memory per hash operation, 3 iterations over that memory, and 4 parallel threads. Adjust parameters to achieve 0.5 to 1 second computation time on target hardware.

bcrypt cost factor 12 produces approximately 0.3 seconds computation time on a 2024 server processor. Increase cost factor by 1 for each doubling of available attacker computing power, approximately every 18 months.

PBKDF2 iteration counts require regular increases to maintain security. The 600,000 minimum reflects 2024 computing capabilities; increase by 100,000 annually.

Prohibited Hash Functions

Algorithm	Reason	Migration Deadline
MD5	Collision attacks trivial	Immediate removal
SHA-1	Collision attacks demonstrated	Immediate removal
MD4	Completely broken	Immediate removal

MD5 and SHA-1 remain acceptable only for non-security purposes such as checksums for data integrity where adversarial manipulation is not a concern.

Transport Layer Security

TLS (Transport Layer Security) protects data in transit between systems. Configuration determines which protocol versions, cipher suites, and certificate types are acceptable.

Protocol Versions

Version	Status	Notes
TLS 1.3	Required	Default for new implementations
TLS 1.2	Permitted	With approved cipher suites only
TLS 1.1	Prohibited	Protocol weaknesses
TLS 1.0	Prohibited	Protocol weaknesses
SSL 3.0	Prohibited	POODLE vulnerability
SSL 2.0	Prohibited	Fundamentally broken

TLS 1.3 removes legacy cipher suites, simplifies the handshake to a single round trip, and mandates forward secrecy. All new services must implement TLS 1.3 as the preferred protocol.

TLS 1.2 remains necessary for compatibility with older clients. When TLS 1.2 is enabled, restrict cipher suites to those providing forward secrecy and authenticated encryption.

TLS 1.3 Cipher Suites

Cipher Suite	Status
TLS_AES_256_GCM_SHA384	Required
TLS_AES_128_GCM_SHA256	Permitted
TLS_CHACHA20_POLY1305_SHA256	Permitted

TLS 1.3 cipher suite names omit key exchange algorithms because TLS 1.3 mandates ephemeral key exchange (forward secrecy) for all suites.

TLS 1.2 Cipher Suites

Cipher Suite	Status	Notes
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384	Required	Primary
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256	Permitted	Fallback
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384	Required	With EC certificates
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256	Permitted	Fallback
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384	Permitted	DHE fallback

Cipher suites without ECDHE or DHE do not provide forward secrecy. A compromised server private key would enable decryption of all past recorded traffic. Prohibit non-forward-secret suites.

Prohibited TLS Configurations

Configuration	Reason
RC4 cipher suites	Statistical biases enable attack
CBC cipher suites in TLS 1.0/1.1	BEAST, Lucky13 vulnerabilities
DES/3DES cipher suites	Insufficient key length
Export cipher suites	Deliberately weakened
NULL cipher suites	No encryption
Anonymous key exchange	No authentication
Static RSA key exchange	No forward secrecy
DH parameters below 2048 bits	Logjam vulnerability

Certificate Requirements

Attribute	Requirement
Key algorithm	RSA-4096 or ECDSA P-384
Signature algorithm	SHA-256 minimum
Validity period	398 days maximum
Subject Alternative Name	Required; CN deprecated
Certificate Transparency	Required for public certificates
OCSP Stapling	Required where supported

Certificates signed with SHA-1 are rejected by current browsers and must not be deployed.

                          TLS HANDSHAKE (1.3)

Client                                                              Server
  |                                                                   |
  |---(1) ClientHello-------------------------------------------->    |
  |       Supported versions                                          |
  |       Cipher suites                                               |
  |       Key share (ECDHE public key)                                |
  |                                                                   |
  |    <---(2) ServerHello----------------------------------------|   |
  |            Selected version                                       |
  |            Selected cipher                                        |
  |            Key share (ECDHE public key)                           |
  |                                                                   |
  |    <---(3) EncryptedExtensions--------------------------------|   |
  |    <---(4) Certificate----------------------------------------|   |
  |    <---(5) CertificateVerify----------------------------------|   |
  |    <---(6) Finished-------------------------------------------|   |
  |                                                                   |
  |       [Client derives traffic keys]                               |
  |                                                                   |
  |---(7) Finished----------------------------------------------->    |
  |                                                                   |
  |    <========= Encrypted Application Data =======>                 |
  |                                                                   |

Figure 1: TLS 1.3 handshake completes in one round trip, with forward secrecy established before server authentication

Encryption at Rest

Data at rest requires encryption to protect against physical theft, improper disposal, and unauthorised storage access.

Storage Encryption Hierarchy

+-------------------------------------------------------------------+
|                     ENCRYPTION LAYERS                             |
+-------------------------------------------------------------------+
|                                                                   |
|  +------------------------------------------------------------+   |
|  |                 APPLICATION LAYER                          |   |
|  |  Field-level encryption for sensitive columns              |   |
|  |  Searchable encryption where supported                     |   |
|  |  Example: Encrypted PII fields in database                 |   |
|  +------------------------------------------------------------+   |
|                              |                                    |
|                              v                                    |
|  +------------------------------------------------------------+   |
|  |                 DATABASE LAYER                             |   |
|  |  Transparent Data Encryption (TDE)                         |   |
|  |  Encrypted tablespaces, redo logs, backups                 |   |
|  |  Example: PostgreSQL pgcrypto, MySQL InnoDB encryption     |   |
|  +------------------------------------------------------------+   |
|                              |                                    |
|                              v                                    |
|  +------------------------------------------------------------+   |
|  |                 FILESYSTEM LAYER                           |   |
|  |  Encrypted filesystems (LUKS, VeraCrypt, FileVault)        |   |
|  |  Protects all files on volume                              |   |
|  |  Example: LUKS on Linux data volumes                       |   |
|  +------------------------------------------------------------+   |
|                              |                                    |
|                              v                                    |
|  +------------------------------------------------------------+   |
|  |                 DISK/HARDWARE LAYER                        |   |
|  |  Self-encrypting drives (SEDs), TPM-bound keys             |   |
|  |  Hardware acceleration, minimal performance impact         |   |
|  |  Example: OPAL 2.0 compliant SSD                           |   |
|  +------------------------------------------------------------+   |
|                                                                   |
+-------------------------------------------------------------------+

Figure 2: Defence in depth through multiple encryption layers

Each layer provides protection against different threats. Full-disk encryption protects against physical theft but not against malware on a running system. Application-level encryption protects data even from database administrators but increases application complexity.

Requirements by Data Classification

Classification	Minimum Encryption	Key Management
Public	None required	N/A
Internal	Full-disk encryption	Local key escrow
Confidential	Full-disk and database TDE	Centralised key management
Restricted	All layers including field-level	HSM-protected keys

Full-Disk Encryption Specifications

Platform	Technology	Configuration
Linux	LUKS2	AES-256-XTS, Argon2id PBKDF
Windows	BitLocker	AES-256, TPM + PIN
macOS	FileVault 2	AES-256-XTS, Recovery key escrow
Mobile (Android)	File-based encryption	AES-256-XTS per-file keys
Mobile (iOS)	Data Protection	AES-256 per-file, class keys

XTS mode is designed for storage encryption, protecting against manipulation attacks that could otherwise recover plaintext through sector modification.

BitLocker must use TPM with PIN or startup key. TPM-only configuration enables attack via cold boot or DMA.

Database Encryption

Database	Native TDE	Algorithm	Notes
PostgreSQL	pgcrypto extension	AES-256	Column-level; TDE via filesystem
MySQL/MariaDB	InnoDB tablespace	AES-256-CBC	Native TDE available
SQL Server	TDE	AES-256	Enterprise edition required
MongoDB	Encrypted Storage Engine	AES-256-CBC	Enterprise edition required
SQLite	SQLCipher	AES-256-CBC	Community extension

Open-source databases often require filesystem-level encryption or extensions to achieve encryption at rest. Plan for this during database selection.

Key Management

Cryptographic key management determines the actual security of encryption. Weak key management undermines strong algorithms.

Key Lifecycle

+------------------------------------------------------------------+
|                     KEY LIFECYCLE                                |
+------------------------------------------------------------------+
|                                                                  |
|  +------------+                                                  |
|  |            |                                                  |
|  | GENERATION +---> Strong random source (CSPRNG)                |
|  |            |     HSM generation for high-value keys           |
|  +-----+------+                                                  |
|        |                                                         |
|        v                                                         |
|  +-----+------+                                                  |
|  |            |                                                  |
|  |   STORAGE  +---> Encrypted key store                          |
|  |            |     HSM for master keys                          |
|  |            |     Separation of key and encrypted data         |
|  +-----+------+                                                  |
|        |                                                         |
|        v                                                         |
|  +-----+------+                                                  |
|  |            |                                                  |
|  |DISTRIBUTION+---> Key wrapping for transport                   |
|  |            |     Secure channels only                         |
|  |            |     Split knowledge for high-value keys          |
|  +-----+------+                                                  |
|        |                                                         |
|        v                                                         |
|  +-----+------+                                                  |
|  |            |                                                  |
|  |    USE     +---> Access controls and logging                  |
|  |            |     Key use separation (signing vs encryption)   |
|  +-----+------+                                                  |
|        |                                                         |
|        v                                                         |
|  +-----+------+                                                  |
|  |            |                                                  |
|  |  ROTATION  +---> Scheduled replacement                        |
|  |            |     Re-encryption of protected data              |
|  |            |     Old key retained for decryption only         |
|  +-----+------+                                                  |
|        |                                                         |
|        v                                                         |
|  +-----+------+                                                  |
|  |            |                                                  |
|  |DESTRUCTION +---> Cryptographic erasure                        |
|  |            |     HSM zeroisation                              |
|  |            |     Destruction verification                     |
|  +------------+                                                  |
|                                                                  |
+------------------------------------------------------------------+

Figure 3: Key lifecycle from generation through destruction

Key Rotation Periods

Key Type	Maximum Active Period	Retention After Rotation
TLS server certificates	398 days	Until expiry
Data encryption keys (symmetric)	2 years	Until all data re-encrypted
Key encryption keys	3 years	7 years for recovery
Signing keys	3 years	10 years for verification
Root CA keys	20 years	Indefinite

Rotation periods balance security against operational overhead. Shorter periods limit exposure from key compromise but increase management burden.

Key Storage Requirements

Key Sensitivity	Storage Requirement
User passwords (derived)	Encrypted database, never plaintext
Service account credentials	Secrets manager (HashiCorp Vault, AWS Secrets Manager)
Application encryption keys	Key management service with access logging
Master keys	Hardware Security Module (HSM)
Root CA private keys	Offline HSM, air-gapped

Hardware Security Modules (HSMs) generate and store keys in tamper-resistant hardware. Keys never leave the HSM in plaintext; cryptographic operations execute within the module. Cloud HSM services (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM) provide HSM capabilities without physical hardware management.

Key Derivation

Key Derivation Functions (KDFs) generate encryption keys from passwords or master keys. KDFs ensure that related keys do not reveal information about each other.

Function	Use Case	Parameters
HKDF-SHA256	Deriving subkeys from master key	Extract-then-expand
PBKDF2-SHA256	Deriving keys from passwords	600,000+ iterations
Argon2id	Deriving keys from passwords	As specified in password hashing
scrypt	Deriving keys from passwords	N=2^15, r=8, p=1

When encrypting data with a password, derive a unique key for each encryption operation using a random salt. Store the salt alongside the ciphertext.

Algorithm Selection

+------------------------------------------------------------------+
|                  ALGORITHM SELECTION                             |
+------------------------------------------------------------------+
|                                                                  |
|  What is the primary requirement?                                |
|        |                                                         |
|        +----> Confidentiality (bulk data)                        |
|        |            |                                            |
|        |            +----> AES-256-GCM                           |
|        |                                                         |
|        +----> Confidentiality (key exchange)                     |
|        |            |                                            |
|        |            +----> ECDH P-384 or X25519                  |
|        |                                                         |
|        +----> Integrity only (no confidentiality)                |
|        |            |                                            |
|        |            +----> HMAC-SHA256 or SHA-256                |
|        |                                                         |
|        +----> Digital signature                                  |
|        |            |                                            |
|        |            +----> ECDSA P-384 or Ed25519                |
|        |                                                         |
|        +----> Password storage                                   |
|        |            |                                            |
|        |            +----> Argon2id                              |
|        |                                                         |
|        +----> Password-based encryption                          |
|        |            |                                            |
|        |            +----> Argon2id + AES-256-GCM                |
|        |                                                         |
|        +----> TLS configuration                                  |
|                     |                                            |
|                     +----> TLS 1.3 with AES-256-GCM              |
|                                                                  |
+------------------------------------------------------------------+

Figure 4: Algorithm selection based on security requirement

Cryptographic Agility

Systems must support cryptographic algorithm replacement without fundamental redesign. This requires:

Protocol negotiation allowing clients and servers to agree on algorithms without code changes. TLS cipher suite negotiation exemplifies this pattern.

Key versioning enabling decryption with old keys while encrypting only with current keys. Include key identifier with ciphertext.

Algorithm identifiers stored alongside ciphertext indicating which algorithm produced it. Do not assume a single algorithm across all encrypted data.

Modular cryptographic interfaces allowing algorithm replacement through configuration rather than code modification.

Post-Quantum Considerations

Current public-key algorithms (RSA, ECDSA, ECDH) are vulnerable to attack by sufficiently powerful quantum computers. While such computers do not currently exist, “harvest now, decrypt later” attacks capture encrypted traffic today for future decryption.

Algorithm Type	Quantum-Resistant Alternative	Status
Key exchange	ML-KEM (Kyber)	NIST standardised 2024
Digital signature	ML-DSA (Dilithium)	NIST standardised 2024
Digital signature	SLH-DSA (SPHINCS+)	NIST standardised 2024

Organisations handling data requiring protection beyond 2035 should evaluate hybrid key exchange combining classical ECDH with ML-KEM. TLS 1.3 supports hybrid key exchange through the X25519Kyber768 mechanism.

Symmetric algorithms (AES-256) and hash functions (SHA-256, SHA-3) require only doubled key lengths to resist quantum attacks. AES-256 provides 128 bits of post-quantum security.

Configuration Examples

OpenSSL TLS 1.2/1.3 Configuration

# /etc/ssl/openssl.cnf (excerpt)

[system_default_sect]
MinProtocol = TLSv1.2
CipherSuites = TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256
CipherString = ECDHE+AESGCM:DHE+AESGCM
Curves = P-384:P-256
SignatureAlgorithms = ECDSA+SHA384:RSA-PSS+SHA384:ECDSA+SHA256:RSA-PSS+SHA256

Nginx TLS Configuration

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;

# TLS 1.3 ciphers
ssl_conf_command Ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256;

# TLS 1.2 ciphers
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;

ssl_ecdh_curve secp384r1:prime256v1;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

ssl_stapling on;
ssl_stapling_verify on;

LUKS2 Volume Creation

# Create LUKS2 encrypted volume with Argon2id
cryptsetup luksFormat --type luks2 \
    --cipher aes-xts-plain64 \
    --key-size 512 \
    --hash sha256 \
    --pbkdf argon2id \
    --pbkdf-memory 262144 \
    --pbkdf-parallel 4 \
    --pbkdf-force-iterations 8 \
    /dev/sdX

# Verify configuration
cryptsetup luksDump /dev/sdX

GPG Key Generation

# Generate Ed25519 signing key with Curve25519 encryption subkey
gpg --quick-generate-key "Name <email@example.org>" ed25519 cert 3y
gpg --quick-add-key <KEYID> cv25519 encr 2y
gpg --quick-add-key <KEYID> ed25519 sign 2y

Compliance Mapping

Standard	Relevant Requirements	This Document Addresses
GDPR Art. 32	Encryption as appropriate safeguard	Algorithm selection, key management
ISO 27001 A.10.1	Cryptographic controls	All sections
PCI DSS Req. 3.5, 4.1	Key management, transmission encryption	Key management, TLS
NIST SP 800-57	Key management recommendations	Key lifecycle, rotation
NIST SP 800-131A	Algorithm transitions	Approved/prohibited algorithms
CIS Controls 3.10, 3.11	Encryption of data at rest and in transit	Storage, TLS

Encryption Standards

Symmetric Encryption

Approved Algorithms

Prohibited Algorithms

Asymmetric Encryption

Approved Algorithms

Key Length Equivalence

Prohibited Configurations

Hash Functions

Approved Functions

Password Hashing

Prohibited Hash Functions

Transport Layer Security

Protocol Versions

TLS 1.3 Cipher Suites

TLS 1.2 Cipher Suites

Prohibited TLS Configurations

Certificate Requirements

Encryption at Rest

Storage Encryption Hierarchy

Requirements by Data Classification

Full-Disk Encryption Specifications

Database Encryption

Key Management

Key Lifecycle

Key Rotation Periods

Key Storage Requirements

Key Derivation

Algorithm Selection

Cryptographic Agility

Post-Quantum Considerations

Configuration Examples

OpenSSL TLS 1.2/1.3 Configuration

Nginx TLS Configuration

LUKS2 Volume Creation

GPG Key Generation

Compliance Mapping

See Also

Thanks for the feedback!

Help us improve