CWE-1240: Use of a Risky Cryptographic Primitive
Presentation Filter:
This device implements a cryptographic algorithm using a non-standard or unproven cryptographic primitive. Cryptographic algorithms (or Cryptographic systems) depend on cryptographic primitives as their basic building blocks. As a result, cryptographic primitives are designed to do one very specific task in a precisely defined and highly reliable fashion. For example, one can declare that a specific crypto primitive (like an encryption routine) can only be broken after trying out N different inputs (the larger the value of N, the stronger the crypto). If a vulnerability is found that leads to breaking this primitive in significantly less than N attempts, then the specific cryptographic primitive is considered broken, and the entirety of the cryptographic algorithm (or the cryptographic system) is now considered insecure. Thus, even breaking a seemingly small cryptographic primitive is sufficient to render the whole system vulnerable. Cryptographic primitives are products of extensive reviews from cryptographers, industry, and government entities looking for any possible flaws. However, over time even well-known cryptographic primitives 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 such implementations will be vulnerable to attacks resulting in the exposure of sensitive information and other consequences. The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore. ![]()
![]()
![]()
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance. Languages Class: Language-Independent (Undetermined Prevalence) Operating Systems Class: OS-Independent (Undetermined Prevalence) Architectures Class: Architecture-Independent (Undetermined Prevalence) Technologies Class: System on Chip (Undetermined Prevalence) The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Example 1 Re-using random values may compromise security (bad code) Suppose a Hashing algorithm needs a random value. Instead of using a DRNG (Deterministic Random Number Generator), the designer uses a LFSR to generate the value. While an LFSR does provide pseudo-random number generation service, its entropy (measure of randomness) is less than that of a DRNG. Thus, using an LFSR weakens the strength of the crypto. (good code) If a cryptographic algorithm expects a random number as its input, provide one. Do not provide a pseudo-random value.
Maintenance The example listed does not really illustrate what is called out in the description. Research Gap This HCWE is really an instance of the RNG CWEs and probably should not be a standalone HCWE.
More information is available — Please select a different filter. |
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-2021, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation. |