Cryptography Standard

A cryptography standard specifies the algorithms, key lengths, and protocols that systems must use when encrypting data, authenticating communications, or verifying integrity. This standard establishes minimum cryptographic requirements for all systems under organisational control. Systems processing data subject to specific regulatory requirements or handling particularly sensitive information may impose stricter controls, but no system may use cryptographic mechanisms weaker than these baselines.

The standard applies to all cryptographic operations: data encryption at rest and in transit, digital signatures, certificate issuance and validation, key exchange, password hashing, and random number generation. Third-party services must demonstrate equivalent cryptographic controls through vendor assessment; direct application of this standard to externally managed systems is not feasible, but contractual requirements must mandate equivalent protection.

Symmetric encryption

Encryption using the same key for both encryption and decryption. Efficient for bulk data encryption but requires secure key distribution.

Asymmetric encryption

Encryption using mathematically related key pairs where data encrypted with one key can only be decrypted with the other. Enables secure key exchange and digital signatures.

Key length

The size of a cryptographic key measured in bits. Longer keys provide greater resistance to brute-force attacks but increase computational cost.

Cipher suite

A combination of algorithms used together in TLS: key exchange, authentication, bulk encryption, and message authentication.

Approved algorithms

Cryptographic algorithm selection balances security strength against performance, interoperability, and implementation maturity. Algorithms in the approved list have undergone extensive cryptanalysis, have well-tested implementations available, and provide adequate security margins for current and near-future threats.

Symmetric encryption algorithms

Symmetric algorithms encrypt and decrypt data using a single shared key. The following table lists approved algorithms with their required minimum key lengths and acceptable use cases.

AES with 128-bit keys provides approximately 2^128 possible key combinations, which remains computationally infeasible to brute-force with current or projected technology. AES-256 provides additional security margin and is required for data classified as high sensitivity. The distinction between 128-bit and 256-bit AES matters primarily for defense against quantum computing threats; Grover’s algorithm theoretically reduces effective key strength by half, making AES-128 equivalent to 64-bit security and AES-256 equivalent to 128-bit security in a post-quantum context.

Galois/Counter Mode (GCM) provides authenticated encryption, combining confidentiality with integrity verification in a single operation. AES-GCM is the preferred mode for new implementations. Cipher Block Chaining (CBC) mode provides confidentiality but not integrity; CBC implementations must pair encryption with a separate HMAC using a distinct key to detect tampering. CBC without authentication is vulnerable to padding oracle attacks.

ChaCha20-Poly1305 serves as an alternative to AES-GCM where hardware AES acceleration is unavailable. On devices without AES-NI instructions, ChaCha20 performs faster in software while providing equivalent security. Mobile devices and embedded systems benefit from ChaCha20-Poly1305.

Asymmetric encryption and key exchange algorithms

Asymmetric algorithms use key pairs for encryption, digital signatures, and key exchange. Computational cost exceeds symmetric algorithms by orders of magnitude, so asymmetric cryptography typically protects symmetric keys rather than bulk data.

RSA key strength scales non-linearly with key length. A 2048-bit RSA key provides approximately 112 bits of security, equivalent to a 112-bit symmetric key. A 3072-bit RSA key provides approximately 128 bits of security. New deployments should use 3072-bit RSA keys or elliptic curve alternatives; 2048-bit keys remain acceptable for existing systems until 2030.

Elliptic curve cryptography provides equivalent security to RSA with substantially shorter keys. A 256-bit ECDSA key provides approximately 128 bits of security, matching a 3072-bit RSA key. The NIST P-256, P-384, and P-521 curves have broad support across platforms and libraries. Curve25519 variants (Ed25519 for signatures, X25519 for key exchange) offer simpler implementation with reduced risk of subtle vulnerabilities from incorrect usage.

Hash functions

Hash functions produce fixed-length digests from arbitrary input data. Cryptographic hash functions must resist collision attacks (finding two inputs with the same hash), preimage attacks (finding an input matching a given hash), and second preimage attacks (finding a different input matching a known input’s hash).

SHA-256 serves as the standard hash function for most applications including certificate signatures, code signing, and integrity verification. SHA-384 and SHA-512 provide larger output sizes for applications requiring additional security margin or longer digest lengths.

SHA-3 functions use an entirely different construction (Keccak sponge) from SHA-2, providing algorithm diversity. Organisations with defence-in-depth requirements may mandate SHA-3 for critical applications to avoid single-algorithm dependency.

BLAKE2 and BLAKE3 offer performance advantages over SHA-2 and SHA-3 while providing equivalent security. BLAKE3 parallelises efficiently across multiple cores and achieves several times the throughput of SHA-256 on modern processors.

Password hashing functions

Password hashing requires specialised functions designed to be computationally expensive, preventing rapid offline attacks against captured password databases. General-purpose hash functions like SHA-256 are unsuitable for password storage because they execute too quickly.

Argon2id is the recommended password hashing function, selected through the Password Hashing Competition. Argon2id combines resistance to both GPU-based attacks (through memory hardness) and side-channel attacks. The specified parameters target approximately 1 second of computation on a typical server, balancing user experience against attack resistance.

bcrypt remains acceptable and enjoys widespread library support. A cost factor of 12 produces approximately 250ms of computation per hash on current hardware; increase the cost factor as hardware performance improves. bcrypt has a 72-byte input limit; longer passwords should be pre-hashed with SHA-256.

scrypt provides memory-hard hashing similar to Argon2 but with less tunable parameters and without Argon2’s side-channel resistance mode. scrypt is acceptable where Argon2 support is unavailable.

Prohibited algorithms

The following algorithms have known weaknesses and must not be used for any security purpose. Systems using these algorithms require migration to approved alternatives.

MD5 and SHA-1 produce collisions where two different inputs yield identical hashes. For digital signatures, this enables attackers to substitute malicious content for legitimate content while preserving signature validity. MD5 collision attacks require seconds of computation; SHA-1 collision attacks require approximately $45,000 of cloud compute resources.

DES and 3DES use 64-bit block sizes. In CBC mode, birthday paradox collisions become probable after 2^32 blocks (32 GB), enabling the Sweet32 attack to recover plaintext. Modern bulk encryption requires 128-bit block sizes.

RC4 has multiple statistical biases in its output stream. TLS connections using RC4 leak plaintext bytes through traffic analysis. No mitigation exists; RC4 must be disabled entirely.

TLS requirements

Transport Layer Security (TLS) protects data in transit between systems. TLS version, cipher suite, and certificate configuration determine connection security.

Protocol versions

TLS 1.3 eliminates legacy cryptographic options, removes vulnerable features like renegotiation and compression, and reduces handshake latency. All systems capable of TLS 1.3 must enable it. TLS 1.2 remains acceptable for compatibility with older clients but must be configured with only approved cipher suites.

TLS 1.1 and earlier versions have structural vulnerabilities that no configuration can fully mitigate. These versions must be disabled server-side even if client compatibility is affected. Clients unable to negotiate TLS 1.2 or higher represent security risks themselves.

TLS 1.3 cipher suites

TLS 1.3 supports only authenticated encryption modes. The following cipher suites are approved:

Configure servers to prefer AES-256-GCM for clients with AES hardware acceleration. ChaCha20-Poly1305 provides better performance on mobile devices without hardware AES support; clients will negotiate appropriately.

TLS 1.2 cipher suites

TLS 1.2 offers many cipher suite options, most of which are insecure. Only the following cipher suites are approved for TLS 1.2:

These cipher suites share essential security properties: ephemeral key exchange (ECDHE) providing forward secrecy, authenticated encryption (GCM or Poly1305), and strong authentication (ECDSA or RSA). Cipher suites using static key exchange (RSA key exchange), CBC mode, or weak authentication (export ciphers, anonymous authentication) are prohibited.

Forward secrecy ensures that compromise of a server’s long-term private key does not enable decryption of previously recorded traffic. ECDHE generates unique session keys for each connection; the session keys cannot be derived from the server’s certificate private key.

TLS configuration requirements

HTTP Strict Transport Security (HSTS) instructs browsers to access the domain only over HTTPS, preventing downgrade attacks. The max-age directive specifies how long browsers should remember this instruction; 31536000 seconds equals one year. Include the includeSubDomains directive if all subdomains support HTTPS.

Session tickets encrypt session state for client storage, enabling resumption without server-side state. Ticket encryption keys must rotate frequently; compromise of a ticket key enables decryption of all sessions encrypted with that key. Disable session tickets if key rotation cannot be automated.

Certificate requirements

Digital certificates bind public keys to identities, enabling authentication of servers, clients, and code. Certificate security depends on the certificate authority’s trustworthiness, the certificate’s cryptographic parameters, and proper validation by relying parties.

Certificate parameters

Certificate validity periods balance operational overhead against compromise exposure. Shorter validity limits the window during which a compromised key endangers systems. Public certificate authorities enforce 398-day maximum validity following CA/Browser Forum requirements. Internal certificates may extend to 825 days but should prefer shorter validity where automation supports frequent renewal.

Wildcard certificates (*.example.org) simplify certificate management but increase blast radius if compromised. A compromised wildcard private key enables impersonation of any subdomain. For internet-facing services, prefer specific certificates with automated renewal over wildcards.

Certificate authority requirements

Internal certificate authorities require careful key protection. The root CA private key should reside in an offline hardware security module (HSM), brought online only for signing intermediate CA certificates. Intermediate CAs handle day-to-day issuance and can operate online with HSM-protected keys.

Certificate Transparency provides public audit logs of all issued certificates. Monitors detect misissued certificates, including those from compromised CAs. All public certificates must be submitted to CT logs; browsers increasingly require CT compliance.

Certificate lifecycle

Automated certificate management through the ACME protocol (implemented by Let’s Encrypt and other CAs) eliminates manual renewal processes that cause expiry outages. Configure automated renewal to execute 30 days before expiry, providing margin for troubleshooting failures.

Revoke certificates immediately upon suspected private key compromise. Revocation through CRL or OCSP informs relying parties that the certificate should not be trusted. However, revocation checking is unreliable; some clients skip revocation checks or soft-fail on check failures. Treat revocation as defence in depth, not primary protection.

Key management requirements

Cryptographic keys require protection throughout their lifecycle: generation, storage, distribution, use, rotation, and destruction. Key compromise negates all cryptographic protection provided by that key.

Key generation

Cryptographic keys must be generated using cryptographically secure random number generators. Modern operating systems provide suitable CSPRNGs: /dev/urandom on Linux, BCryptGenRandom on Windows, SecRandomCopyBytes on macOS/iOS. Application code should use these system facilities rather than implementing random number generation.

Hardware security modules provide the strongest key generation guarantees, generating keys internally using dedicated hardware entropy sources and preventing key export. Use HSMs for certificate authority keys, root encryption keys, and other high-value long-term keys.

Key storage

Key-encryption keys (KEKs) protect data-encryption keys (DEKs), enabling encrypted DEK storage alongside encrypted data. Compromise of encrypted data without the KEK does not expose data even if DEKs are stored with the ciphertext. This hierarchy limits the keys requiring HSM protection to the relatively small number of KEKs.

Secrets management services (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) provide secure storage, access control, and audit logging for secrets including cryptographic keys. Application code retrieves secrets at runtime rather than embedding them in configuration.

Key rotation

Key rotation limits exposure from undetected compromise. If an attacker obtains a key, they can access only data encrypted during that key’s lifetime. Automated rotation reduces operational burden while maintaining security.

Data re-encryption during DEK rotation requires reading encrypted data, decrypting with the old key, encrypting with the new key, and writing the result. For large datasets, this process may take considerable time; implementations should support concurrent access during rotation.

Key destruction

Key destruction must be verifiable and irreversible. For software keys, overwrite key material before deallocation; rely on cryptographic erasure where direct overwrite is impractical (flash storage, SSDs). HSMs provide auditable key destruction functions.

Retain encrypted backups only if corresponding decryption keys are preserved. Destroying keys while retaining encrypted data effectively destroys the data.

Encryption requirements by data classification

Data classification determines minimum encryption requirements. Higher classifications require stronger algorithms, longer keys, and more rigorous key management.

Full-disk encryption (FDE) protects data when devices are powered off or storage is physically removed. FDE does not protect against logical access by authenticated users or malware running on the system. File-level or database encryption provides additional protection for sensitive data.

Mutual TLS (mTLS) authenticates both client and server, preventing unauthorised clients from connecting even if they can reach the network endpoint. Service-to-service communication for restricted data requires mTLS to verify service identity.

Field-level encryption

Certain data fields require encryption independent of storage or transport encryption. Field-level encryption protects data from privileged database administrators, backup operators, and other principals with infrastructure access but without need-to-know for specific data content.

Field-level encryption increases complexity: encrypted fields cannot be searched or indexed without additional mechanisms (deterministic encryption or searchable encryption schemes). Design data models to minimise fields requiring encryption while protecting all fields that contain sensitive data.

Exceptions

Exceptions to this standard require documented approval from the information security function. Exception requests must include:

• Specific requirement(s) excepted
• Technical or business justification
• Compensating controls
• Risk assessment
• Review date (maximum 12 months for algorithm exceptions; 24 months for key length exceptions)
• Accountable individual

Legacy system exceptions for deprecated algorithms must include migration timelines. New systems may not receive exceptions for prohibited algorithms; design changes to use approved alternatives are required.

See also

• Information Security Policy
• Data Classification
• Encryption Standards
• Certificate Management
• API Credential Rotation