Weakness (CWE)
CWE-1240: Use of a Cryptographic Primitive with a Risky Implementation
To fulfill the need for a cryptographic primitive, the product implements a cryptographic algorithm using a non-standard, unproven, or disallowed/non-compliant cryptographic implementation.
More detail
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.
How to prevent it (8 mitigations)
-
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].
-
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].
-
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.
-
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.
-
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.
-
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].
-
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.
-
Architecture and Design, Implementation
Do not use a checksum as a substitute for a cryptographically generated hash.
Source: MITRE CWE-1240
28 results · Feed
-
High 8.5
Misuse and Misconfiguration of Cryptographic Algorithm in Bluetooth Communication
Misuse and misconfiguration in Bluetooth communication in SwitchBot Door Lock Series allows an attacker to bypass the electronic lock and access controls via a manipulated communication protocol.
-
Medium 5.3
HCL Hive is affected by use of a cryptographic primitive with a risky implementation
HCL Hive Keycloak IAM Instance is affected by insufficient granularity of access control which could allow an attacker unauthorized access to resources.
-
High 7.4
HCL Hive is affected by use of a cryptographic primitive with a risky implementation
HCL Hive is affected by a cryptographic primitive with a risky implementation which could allow an attacker unauthorized lateral compromise or widespread credential leakage if a single internal component is breached.
-
Medium 5.5
Windows Key Guard Security Feature Bypass Vulnerability
Use of a cryptographic primitive with a risky implementation in Windows Key Guard allows an authorized attacker to bypass a security feature locally.
-
High 8.9
Plonky3 MultiField32Challenger: transcript malleability and challenge entropy loss
Plonky3 is a toolkit for polynomial IOPs (PIOPs). Prior to versions 0.4.3 and 0.5.3, an attacker controlling prover-side observations can craft distinct transcripts that produce identical challenges, breaking the binding property of Fiat-Shamir. This issue ha…
-
Low 3.8
Function Abusement Vulnerability in ZTE ZXUniPOS NDS-LTE
This vulnerability stems from a business logic flaw.Attackers can exploit legitimate application functions in unintended and abnormal ways, deviating from the designer's expectations, to carry out malicious attacks.
-
High 7.5
Apache Tomcat: EncryptInterceptor vulnerable to padding oracle attack by default
Padding Oracle vulnerability in Apache Tomcat's EncryptInterceptor with default configuration. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.18, from 10.0.0-M1 through 10.1.52, from 9.0.13 through 9..115, from 8.5.38 through 8.5.100, from 7.0.…
-
High —
libcrux has All-Zero Key Generation Upon Catastrophic RNG Failure
The libcrux-ed25519 key generation samples Ed25519 secret keys from a provided CSPRNG in a loop for up to 100 attempts until a non-zero key is found. If a non-zero key could not be sampled within 100 attempts the key generation function would silently continu…
-
Medium 5.9
Multiple Vulnerabilities in IBM Concert Software
IBM Concert 1.0.0 through 2.2.0 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information
-
Low 2.3
uTLS has a Chrome Parrot Fingerprint Vulnerability due to GREASE ECH Cipher Suite Mismatch
uTLS is a fork of crypto/tls, created to customize ClientHello for fingerprinting resistance while still using it for the handshake. Versions 1.6.0 through 1.8.0 contain a fingerprint mismatch with Chrome when using GREASE ECH, related to cipher suite selecti…
-
High 8.3
`libparsec_crypto` does not check for weak order point of curve 25519
Parsec is a cloud-based application for cryptographically secure file sharing. In versions on the 3.x branch prior to 3.6.0, `libparsec_crypto`, a component of the Parsec application, does not check for weak order point of Curve25519 when compiled with its Ru…
-
Medium 6.4
RustCrypto: Signatures has timing side-channel in ML-DSA decomposition
RustCrypto: Signatures offers support for digital signatures, which provide authentication of data using public-key cryptography. Prior to version 0.1.0-rc.2, a timing side-channel was discovered in the Decompose algorithm which is used during ML-DSA signing …
-
Medium 5.6
Elliptic Cryptanalysis vulnerability when `k` has leading zeros
The ECDSA implementation of the Elliptic package generates incorrect signatures if an interim value of 'k' (as computed based on step 3.2 of RFC 6979 https://datatracker.ietf.org/doc/html/rfc6979 ) has leading zeros and is susceptible to cryptanalysis, which …
-
Medium 5.9
Apache StreamPark: Uses the user’s password as the secret key
When issuing JSON Web Tokens (JWT), Apache StreamPark directly uses the user's password as the HMAC signing key (e.g., with the HS256 algorithm). An attacker can exploit this vulnerability to perform offline brute-force attacks on the user's password using a …
-
Medium 6.7
Dell CloudLink, versions prior to 8.2, contain use of a Cryptographic Primitive with a Risky Implementation vulnerabili…
-
High 7.8
Windows Cryptographic Services Information Disclosure Vulnerability
Use of a cryptographic primitive with a risky implementation in Windows Cryptographic Services allows an authorized attacker to disclose information locally.
-
Medium 5.5
Windows Cryptographic Services Information Disclosure Vulnerability
Use of a cryptographic primitive with a risky implementation in Windows Cryptographic Services allows an authorized attacker to disclose information locally.
-
Medium 5.4
Post-Quantum Secure Feldman's Verifiable Secret Sharing has Inadequate Fault Injection Countermeasures in `secure_redundant_execution`
Post-Quantum Secure Feldman's Verifiable Secret Sharing provides a Python implementation of Feldman's Verifiable Secret Sharing (VSS) scheme. In versions 0.8.0b2 and prior, the `secure_redundant_execution` function in feldman_vss.py attempts to mitigate fault…
-
Low 3.7
Dell PowerProtect DD, versions prior to DDOS 8.3.0.0, 7.10.1.50, and 7.13.1.10 contains a use of a Cryptographic Primit…
-
High 8.6
Soundness issue with Plonky2 look up tables
Plonky2 is a SNARK implementation based on techniques from PLONK and FRI. Lookup tables, whose length is not divisible by 26 = floor(num_routed_wires / 3) always include the 0 -> 0 input-output pair. Thus a malicious prover can always prove that f(0) = 0 for …
-
High —
PQClean has a correctness error in HQC decapsulation
### Impact A correctness error has been identified in the reference implementation of the HQC key encapsulation mechanism. Due to an indexing error, part of the secret key is incorrectly treated as non-secret data. This results in an incorrect shared secret v…
-
Low 3.8
Dell Key Trust Platform, v3.0.6 and prior, contains Use of a Cryptographic Primitive with a Risky Implementation vulner…
-
Medium —
Laravel Encrypter Component Potential Decryption Failure Leading to Unintended Behavior
The Laravel Encrypter component is susceptible to a vulnerability that may result in decryption failure, leading to an unexpected return of `false`. Exploiting this issue requires the attacker to manipulate the encrypted payload before decryption. When combin…
-
Low —
Laravel Encrypter Failure to decryption vulnerability
A potential exploit of the Laravel Encrypter component that may cause the Encrypter to fail on decryption and unexpectedly return false. To exploit this, the attacker must be able to modify the encrypted payload before it is decrypted. Depending on the code w…
-
Medium 6.2
Silicon Labs EFR32xxx parts with classic key storage do not use hardware accelerated AES-CCM
Ember ZNet between v7.2.0 and v7.4.0 used software AES-CCM instead of integrated hardware cryptographic accelerators, potentially increasing risk of electromagnetic and differential power analysis sidechannel attacks.
-
High 8.3
B&R products use insufficient communication encryption
B&R Automation Studio Upgrade Service and B&R Technology Guarding use insufficient cryptography for communication to the upgrade and the licensing servers. A network-based attacker could exploit the vulnerability to execute arbitrary code on the products or s…
-
Critical 9.8
FTP uses unsecure encryption mechanisms
The FTP server used on the B&R Automation Runtime supports unsecure encryption mechanisms, such as SSLv3, TLSv1.0 and TLS1.1. An network-based attacker can exploit the flaws to conduct man-in-the-middle attacks or to decrypt communications between the affecte…
-
Medium 6.5
scalarmult() vulnerable to degenerate public keys
sodiumoxide 0.0.13 and older scalarmult() vulnerable to degenerate public keys