Cryptographic protocols and systems depend on cryptographic primitives (and associated algorithms) as their basic building blocks. Some common examples of primitives are digital signatures, one-way hash functions, ciphers, and public key cryptography; however, the notion of "primitive" can vary depending on point of view. See "Terminology Notes" for further explanation of some concepts.
Cryptographic primitives are defined to accomplish one very specific task in a precisely defined and mathematically reliable fashion. For example, suppose that for a specific cryptographic primitive (such as an encryption routine), the consensus is that the primitive can only be broken after trying out N different inputs (where the larger the value of N, the stronger the cryptography). For an encryption scheme like AES-256, one would expect N to be so large as to be infeasible to execute in a reasonable amount of time.
If a vulnerability is ever found that shows that one can break a cryptographic primitive in significantly less than the expected number of attempts, then that primitive is considered weakened (or sometimes in extreme cases, colloquially it is "broken"). As a result, anything using this cryptographic primitive would now be considered insecure or risky. Thus, even breaking or weakening a seemingly small cryptographic primitive has the potential to render the whole system vulnerable, due to its reliance on the primitive. A historical example can be found in TLS when using DES. One would colloquially call DES the cryptographic primitive for transport encryption in this version of TLS. In the past, DES was considered strong, because no weaknesses were found in it; importantly, DES has a key length of 56 bits. Trying N=2^56 keys was considered impractical for most actors. Unfortunately, attacking a system with 56-bit keys is now practical via brute force, which makes defeating DES encryption practical. It is now practical for an adversary to read any information sent under this version of TLS and use this information to attack the system. As a result, it can be claimed that this use of TLS is weak, and that any system depending on TLS with DES could potentially render the entire system vulnerable to attack.
Cryptographic primitives and associated algorithms are only considered safe after extensive research and review from experienced cryptographers from academia, industry, and government entities looking for any possible flaws. Furthermore, cryptographic primitives and associated algorithms are frequently reevaluated for safety when new mathematical and attack techniques are discovered. As a result and over time, even well-known cryptographic primitives can lose their compliance status with the discovery of novel attacks that might either defeat the algorithm or reduce its robustness significantly.
If ad-hoc cryptographic primitives are implemented, it is almost certain that the implementation will be vulnerable to attacks that are well understood by cryptographers, resulting in the exposure of sensitive information and other consequences.
This weakness is even more difficult to manage for hardware-implemented deployment of cryptographic algorithms. First, because hardware is not patchable as easily as software, any flaw discovered after release and production typically cannot be fixed without a recall of the product. Secondly, the hardware product is often expected to work for years, during which time computation power available to the attacker only increases. Therefore, for hardware implementations of cryptographic primitives, it is absolutely essential that only strong, proven cryptographic primitives are used.
| Impact | Details |
|---|---|
|
Read Application Data |
Scope: Confidentiality
Likelihood: High
Incorrect usage of crypto primitives could render the supposedly encrypted data as unencrypted plaintext in the worst case.
|
| Phase(s) | Mitigation |
|---|---|
|
Requirements |
Require compliance with the strongest-available recommendations from trusted parties, and require that compliance must be kept up-to-date, since recommendations evolve over time. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-267].
Effectiveness: High |
|
Architecture and Design |
Ensure that the architecture/design uses the strongest-available primitives and algorithms from trusted parties. For example, US government systems require FIPS 140-3 certification, which supersedes FIPS 140-2 [REF-1192] [REF-267].
Effectiveness: High |
|
Architecture and Design |
Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. As with all cryptographic mechanisms, the source code should be available for analysis. If the algorithm may be compromised when attackers find out how it works, then it is especially weak.
Effectiveness: Discouraged Common Practice |
|
Architecture and Design |
Try not to use cryptographic algorithms in novel ways or with new modes of operation even when you "know" it is secure. For example, using SHA-2 chaining to create a 1-time pad for encryption might sound like a good idea, but one should not do this.
Effectiveness: Discouraged Common Practice |
|
Architecture and Design |
Ensure that the design can replace one cryptographic primitive or algorithm with another in the next generation ("cryptographic agility"). Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. This is especially important for hardware, which can be more difficult to upgrade quickly than software; design the hardware at a replaceable block level.
Effectiveness: Defense in Depth |
|
Architecture and Design |
Do not use outdated or non-compliant cryptography algorithms. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong [REF-267].
Effectiveness: Discouraged Common Practice |
|
Architecture and Design; Implementation |
Do not use a linear-feedback shift register (LFSR) or other legacy methods as a substitute for an accepted and standard Random Number Generator.
Effectiveness: Discouraged Common Practice |
|
Architecture and Design; Implementation |
Do not use a checksum as a substitute for a cryptographically generated hash.
Effectiveness: Discouraged Common Practice |
|
Architecture and Design |
Strategy: Libraries or Frameworks
Use a vetted cryptographic library or framework. Industry-standard implementations will save development time and are more likely to avoid errors that can occur during implementation of cryptographic algorithms. However, the library/framework could be used incorrectly during implementation.
Effectiveness: High |
|
Architecture and Design; Implementation |
When using industry-approved techniques, use them correctly. Don't cut corners by skipping resource-intensive steps (CWE-325). These steps are often essential for the prevention of common attacks.
Effectiveness: Moderate |
|
Architecture and Design; Implementation |
Do not store keys in areas accessible to untrusted agents. Carefully manage and protect the cryptographic keys (see CWE-320). If the keys can be guessed or stolen, then the strength of the cryptography algorithm is irrelevant.
Effectiveness: Moderate |
| Nature | Type | ID | Name |
|---|---|---|---|
| ChildOf | Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. | 327 | Use of a Broken or Risky Cryptographic Algorithm |
| Nature | Type | ID | Name |
|---|---|---|---|
| MemberOf | Category Category - a CWE entry that contains a set of other entries that share a common characteristic. | 310 | Cryptographic Issues |
| Nature | Type | ID | Name |
|---|---|---|---|
| MemberOf | Category Category - a CWE entry that contains a set of other entries that share a common characteristic. | 1205 | Security Primitives and Cryptography Issues |
| Phase | Note |
|---|---|
| Architecture and Design | This weakness is primarily introduced during the architecture and design phase as risky primitives are included. |
| Implementation | Even in cases where the Architectural phase properly specifies a cryptographically secure design, the design may be changed during implementation due to unforeseen constraints. |
Class: Not Language-Specific (Undetermined Prevalence)
Class: Not OS-Specific (Undetermined Prevalence)
Class: Not Architecture-Specific (Undetermined Prevalence)
Class: System on Chip (Undetermined Prevalence)
Example 1
Re-using random values may compromise security.
While an LFSR may provide pseudo-random number generation service, the entropy (measure of randomness) of the resulting output may be less than that of an accepted DRNG (like that used in dev/urandom). Thus, using an LFSR weakens the strength of the cryptographic system, because it may be possible for an attacker to guess the LFSR output and subsequently the encryption key.
Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
| Reference | Description |
|---|---|
|
software uses MD5, which is less safe than the default SHA-256 used by related products
|
|
|
Default configuration of product uses MD5 instead of stronger algorithms that are available, simplifying forgery of certificates.
|
|
|
identity card uses MD5 hash of a salt and password
|
|
|
personal key is transmitted over the network using a substitution cipher
|
|
|
product does not disable TLS-RSA cipher suites, allowing decryption of traffic if TLS 2.0 and secure ciphers are not enabled.
|
|
|
SSL/TLS library generates 16-byte nonces but reduces them to 12 byte nonces for the ChaCha20-Poly1305 cipher, converting them in a way that violates the cipher's requirements for unique nonces.
|
|
|
LDAP interface allows use of weak ciphers
|
|
|
SCADA product allows "use of outdated cipher suites"
|
|
|
Chip implementing Bluetooth uses a low-entropy PRNG instead of a hardware RNG, allowing spoofing.
|
|
|
security product has insufficient entropy in the DRBG, allowing collisions and private key discovery
|
|
|
Dual_EC_DRBG implementation in RSA toolkit does not correctly handle certain byte requests, simplifying plaintext recovery
|
|
|
Recommendation for Dual_EC_DRBG algorithm contains point Q constants that could simplify decryption
|
| Ordinality | Description |
|---|---|
|
Primary
|
(where the weakness exists independent of other weaknesses)
|
| Method | Details |
|---|---|
|
Architecture or Design Review |
Review requirements, documentation, and product design to ensure that primitives are consistent with the strongest-available recommendations from trusted parties. If the product appears to be using custom or proprietary implementations that have not had sufficient public review and approval, then this is a significant concern.
Effectiveness: High |
|
Manual Analysis |
Analyze the product to ensure that implementations for each primitive do not contain any known vulnerabilities and are not using any known-weak algorithms, including MD4, MD5, SHA1, DES, etc.
Effectiveness: Moderate |
|
Dynamic Analysis with Manual Results Interpretation |
For hardware, during the implementation (pre-Silicon / post-Silicon) phase, dynamic tests should be done to ensure that outputs from cryptographic routines are indeed working properly, such as test vectors provided by NIST [REF-1236].
Effectiveness: Moderate |
|
Dynamic Analysis with Manual Results Interpretation |
It needs to be determined if the output of a cryptographic primitive is lacking entropy, which is one clear sign that something went wrong with the crypto implementation. There exist many methods of measuring the entropy of a bytestream, from sophisticated ones (like calculating Shannon's entropy of a sequence of characters) to crude ones (by compressing it and comparing the size of the original bytestream vs. the compressed - a truly random byte stream should not be compressible and hence the uncompressed and compressed bytestreams should be nearly identical in size).
Effectiveness: Moderate |
| Nature | Type | ID | Name |
|---|---|---|---|
| MemberOf | ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). | 1343 | Weaknesses in the 2021 CWE Most Important Hardware Weaknesses List |
| MemberOf | CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. | 1402 | Comprehensive Categorization: Encryption |
Rationale
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.Comments
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.Terminology
Terminology for cryptography varies widely, from informal and colloquial to mathematically-defined, with different precision and formalism depending on whether the stakeholder is a developer, cryptologist, etc. Yet there is a need for CWE to be self-consistent while remaining understandable and acceptable to multiple audiences.
As of CWE 4.6, CWE terminology around "primitives" and "algorithms" is emerging as shown by the following example, subject to future consultation and agreement within the CWE and cryptography communities. Suppose one wishes to send encrypted data using a CLI tool such as OpenSSL. One might choose to use AES with a 256-bit key and require tamper protection (GCM mode, for instance). For compatibility's sake, one might also choose the ciphertext to be formatted to the PKCS#5 standard. In this case, the "cryptographic system" would be AES-256-GCM with PKCS#5 formatting. The "cryptographic function" would be AES-256 in the GCM mode of operation, and the "algorithm" would be AES. Colloquially, one would say that AES (and sometimes AES-256) is the "cryptographic primitive," because it is the algorithm that realizes the concept of symmetric encryption (without modes of operation or other protocol related modifications). In practice, developers and architects typically refer to base cryptographic algorithms (AES, SHA, etc.) as cryptographic primitives.
Maintenance
| CAPEC-ID | Attack Pattern Name |
|---|---|
| CAPEC-97 | Cryptanalysis |
| Submissions | |||
|---|---|---|---|
| Submission Date | Submitter | Organization | |
|
2020年02月10日
(CWE 4.0, 2020年02月24日) |
Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi | Intel Corporation | |
| Contributions | |||
| Contribution Date | Contributor | Organization | |
| 2021年10月18日 | Parbati K. Manna | Intel Corporation | |
| provided detection methods and observed examples | |||
| Modifications | |||
| Modification Date | Modifier | Organization | |
|
2025年09月09日
(CWE 4.18, 2025年09月09日) |
CWE Content Team | MITRE | |
| updated References | |||
|
2025年04月03日
(CWE 4.17, 2025年04月03日) |
CWE Content Team | MITRE | |
| updated Demonstrative_Examples | |||
| 2023年06月29日 | CWE Content Team | MITRE | |
| updated Mapping_Notes | |||
| 2023年04月27日 | CWE Content Team | MITRE | |
| updated References, Relationships | |||
| 2021年10月28日 | CWE Content Team | MITRE | |
| updated Background_Details, Demonstrative_Examples, Description, Detection_Factors, Maintenance_Notes, Name, Observed_Examples, Potential_Mitigations, References, Relationships, Terminology_Notes, Weakness_Ordinalities | |||
| 2021年07月20日 | CWE Content Team | MITRE | |
| updated Maintenance_Notes, Research_Gaps | |||
| 2020年08月20日 | CWE Content Team | MITRE | |
| updated Background_Details, Common_Consequences, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Potential_Mitigations, Related_Attack_Patterns, Research_Gaps | |||
| Previous Entry Names | |||
| Change Date | Previous Entry Name | ||
| 2021年10月28日 | Use of a Risky Cryptographic Primitive | ||
Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2025, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.