Common Cryptography Mistakes

What mistakes have the largest impact?

The highest-impact mistakes are system-level. Teams may choose a mechanism without first defining the security service, trust relationships, data lifetime, operational environment, or applicable requirements. They may also assume that naming a recognized algorithm is enough, even though secure operation depends on the surrounding module, interfaces, authentication, software and firmware, sensitive security parameter management, self-tests, lifecycle assurance, and attack mitigation. Cryptography can provide confidentiality, integrity, and authentication, but poor design or weak algorithms can still leave sensitive information at risk.123

A second group of mistakes is operational: unmanaged keys, untracked certificates, excessive trust anchors, incomplete revocation processing, unsafe protocol configuration, and failure to remove obsolete options. These problems are consequential because cryptographic protection has a lifecycle. Keys are generated, established, stored, used, backed up or recovered where applicable, revoked, and destroyed; certificates have owners, status, validity periods, and replacement responsibilities. Security therefore depends on governance and maintenance as much as on the cryptographic primitive.4

1. Design mistakes: starting with an algorithm instead of a requirement

A common design error is to begin with a favorite cipher, hash, or library API rather than identifying what must be protected and from whom. The design should distinguish services such as confidentiality, integrity, authentication, and key establishment, then specify the security strength, data lifetime, trust boundaries, failure behavior, and operational responsibilities. NIST guidance describes cryptographic modules as part of systems that protect sensitive information and identifies module specification, interfaces, roles, services, authentication, operating environment, key management, self-tests, assurance, and attack mitigation as relevant security areas.12

The safer principle is to define an end-to-end security requirement and map each requirement to a mechanism, key, identity, and lifecycle control. Do not treat encryption alone as a complete design: a system may also need integrity protection, authenticated endpoints, protected key establishment, certificate policy, auditability, and recovery procedures. A standard can provide a common reference and conformance tests, but responsibility remains for ensuring that the overall implementation provides an acceptable level of security.13

2. Algorithm, mode, and parameter mistakes

Selecting an algorithm because it is familiar, fast, or available in an API is not a sufficient selection process. NIST’s transition guidance addresses algorithm and key-length changes caused by cryptanalytic advances and more powerful computing, and it recommends planning for transitions rather than waiting for a break or an urgent compliance deadline. It also notes that the guidance is specifically directed at federal agencies protecting sensitive but unclassified information; other organizations must determine which requirements apply to them.5

Another mistake is treating a primitive as a complete construction. AES, for example, is used with a FIPS-approved or NIST-recommended mode of operation, and NIST’s AES material identifies modes as functions that provide services such as confidentiality and authentication. A correct algorithm implementation does not by itself specify the application’s complete construction, parameter handling, nonce or initialization requirements, error behavior, or key lifecycle. The safer principle is to select a standardized scheme and mode appropriate to the application, then verify the exact parameters and integration behavior rather than assembling a construction from primitives.6

Hash functions are also easy to misuse. A hash digest is intended to detect whether a message changed; it is not automatically a substitute for a keyed authenticator, encryption, password-protection scheme, or digital signature. The appropriate hash function depends on the algorithm, scheme, or application and the required minimum security strength. Treating a hash name as a universal security control can therefore create a design mismatch.34

3. Randomness and key-generation mistakes

Keys and other cryptographic values must be generated using an appropriate, security-reviewed process. A predictable or incorrectly seeded random source can undermine an otherwise strong algorithm, because an attacker may reduce the effective uncertainty of keys, nonces, or parameters. The cited NIST material identifies random number generation among the subjects of cryptographic transition guidance and separately points to approved key-management and key-derivation guidance; it does not support treating ordinary application randomness as suitable for cryptographic purposes.5

The safer principle is to use the approved or recommended generation and derivation mechanism required by the selected protocol or application, preserve the required security strength, and test the implementation and its operating assumptions. Do not invent a key-derivation construction merely because a hash function is available. Internet security protocols may define application-specific key-derivation functions, and NIST SP 800-135 provides security requirements for such functions.1

4. Key management and secrets-handling mistakes

A frequent mistake is to think of key management as only storing a secret. NIST defines key management as handling keys and related information across the entire lifecycle, including generation, storage, establishment, entry and output, use, and destruction. It also identifies key usage, cryptoperiod length, parameter validation, public-key validation, inventory management, accountability, audit, survivability, and algorithm and key-size selection as key-management issues.4

A second mistake is placing private or secret keys in an ordinary inventory, ticket, source repository, log, or other broadly accessible record. A key inventory should record references and metadata needed to manage keys and certificates, such as the owner, type, algorithm, length, application, and expiration date, but—unless it is also used for backup or archiving—should not include secret or private keys. The safer principle is to separate inventory metadata from protected key material and to assign accountable owners and authorized operators.4

Authorization must cover key-management functions, not just administrative login. The access-control system should authenticate the requesting entity, verify that it is authorized for the requested function, and enforce applicable constraints before permitting a key or metadata-management service. Systems should also maintain audit records, examine logs for irregularities, and plan for survivability and remedial action.4

5. Certificate-validation mistakes

Certificate validation is more than checking that a certificate is signed. RFC 5280 describes path validation as verifying the binding between the subject distinguished name or subject alternative name and the subject public key, based on the public key of a trust anchor. Trust-anchor selection is a local policy decision, and different paths may use different trust anchors. A verifier that accepts an inappropriate trust anchor, ignores application-specific constraints, or fails to preserve the integrity of trusted-CA information can accept a certificate outside the intended trust policy.7

Time and revocation are also easy to overlook. Certificate validation is performed with respect to a current date and time, and validation is not available for a time outside the certificate’s validity period. Where CRLs are the revocation mechanism, conforming implementations that support them must be functionally equivalent to the specified external behavior when processing conforming CRLs. The safer principle is to define certificate policy, validity-time behavior, revocation behavior, trust anchors, name and path constraints, and failure handling explicitly.7

Too many trust anchors make trusted-CA information difficult to maintain, while only one may restrict a system to a closed community. RFC 5280 also warns that the assurance of a certificate binding cannot exceed the strength of the cryptographic module and algorithms used to generate its signature; short key lengths or weak hash algorithms limit a certificate’s utility. Certificate configuration should therefore be reviewed as a policy and implementation boundary, not treated as a passive browser or operating-system default.7

6. Protocol configuration and library-use mistakes

Protocol security depends on implementing the protocol’s rules, not merely enabling a protocol version. RFC 8446 records implementation pitfalls involving fragmented handshake messages, record-layer behavior, certificate and certificate-request messages, and removal of obsolete SSL, RC4, export-cipher, and MD5 support from configurations supporting TLS 1.3. These examples show why configuration review and interoperability testing matter: edge cases can produce security or interoperability problems even when the nominal protocol version is current.

A library can reduce the amount of cryptographic code an application must write, but it cannot decide the application’s trust policy, data classification, key ownership, certificate constraints, migration obligations, or operational response. Nor does conformance of a primitive prove that the surrounding implementation is secure. FIPS 180-4 states that conformance to the standard does not assure that a particular implementation is secure, while FIPS 140-3 covers broader module design, implementation, and operation requirements. The safer principle is to use maintained, reviewed interfaces, minimize custom cryptographic code, configure explicit policies, and test the complete integration.13

7. Custom cryptography, missing tests, and weak monitoring

Designing a new cipher, protocol, padding rule, certificate validator, or key-management workflow without a compelling and reviewed need is a high-risk choice. The evidence emphasizes public analysis, standards, validation programs, module testing, and the importance of implementation quality. That does not mean a standard or validation label removes all responsibility: the application still has to use the mechanism correctly and meet its own security requirements.13

Testing should cover interfaces, authentication and authorization, self-tests, lifecycle behavior, protocol edge cases, certificate failures, key replacement, and operational recovery. Monitoring should include ownership and status records for keys and certificates, expiration and compromise reporting, access activity, audit-log review, and remedial action. A system that cannot identify which key or certificate is in use, who owns it, or when it must be replaced is difficult to operate safely even if its cryptographic calls are technically correct.4

8. Migration mistakes: waiting until protection is obsolete

A migration mistake is to wait until an algorithm, hash, or key length is formally unacceptable before discovering where it is used. NIST transition guidance recommends planning for changes caused by algorithm breaks, stronger computing techniques, and the potential emergence of quantum computers. It also describes a general approach for moving from one algorithm or key length to another and more specific guidance for stronger keys and more robust algorithms.5

Migration also has a time dimension. Information encrypted while an algorithm was considered secure may have been captured and later decrypted after the algorithm was no longer considered secure. The safer principle is to maintain an inventory of algorithms, key lengths, certificates, protocols, and dependent applications; assign owners; define replacement paths; test interoperability; and prioritize data whose confidentiality must last beyond the expected cryptographic protection period.45

Conclusion

The most effective response to common cryptography mistakes is disciplined engineering rather than a search for a single perfect algorithm. Define the required security services, choose a standardized construction and suitable parameters, use a maintained implementation, protect keys across their lifecycles, enforce certificate and trust policy, configure protocols deliberately, test failure paths, monitor ownership and status, and plan migration early. Standards and validation improve assurance, but the complete system and its operating practices remain responsible for security.1245