Cryptography is the cornerstone of Web3 security. From private key generation to transaction signing, every step relies on the correct and secure implementation of cryptographic components. However, in the actual development of Web3 projects, development teams often focus on business logic and performance optimization while overlooking the subtle yet critical aspects of underlying cryptographic implementations. Using insecure random number generators, invoking cryptographic libraries incorrectly, or misunderstanding algorithm characteristics can all introduce fatal vulnerabilities — leading to private key leaks, signature forgeries, and ultimately irreversible asset losses.
Typically, project teams rely on security audits to uncover such issues. However, audits serve as a form of post-event verification and cannot fully cover the entire project lifecycle. Many vulnerabilities originate from the early stages of design and technology selection. Without a foundational understanding of cryptographic security, teams cannot effectively mitigate these risks at their source.
To address this, the SlowMist security team has open-sourced Common- Cryptographic-Risks-in-Blockchain-Applications, aiming to share the practical insights and best practices accumulated through front-line offensive and defensive work. We hope this resource will help project teams establish a robust cryptographic security foundation from the very beginning of development and ultimately build independent and sustainable secure coding capabilities.
1. Using JavaScript Math.random or seed-based random number generation based on time
Severity: High
Description: JavaScript’s Math.random() is a pseudo-random number generator (PRNG) and is not suitable for cryptographic security purposes. Its implementation depends on the browser or JavaScript engine (such as V8’s Xorshift128+), and the seed and algorithm are typically not controllable, leading to insufficient unpredictability and potentially allowing attackers to guess or reproduce the generated random number sequence.
Exploitation Scenario: This can lead to the encryption key being cracked, session hijacking, or game cheating when used to generate cryptographic keys, session tokens, CSRF tokens, or game random events.
Recommendation: Prioritize using crypto.getRandomValues() (Web Crypto API) to generate cryptographically secure random numbers, which is suitable for sensitive scenarios such as keys and tokens.
2. Using Java’s Unsafe Random Number Generation Method to Generate Private Keys
Severity: High
Description: Java’s java.util.Random or java.util.concurrent.ThreadLocalRandom are non-cryptographically secure pseudo-random number generators (PRNGs). Their seeds and algorithms (such as linear congruential generators) are predictable and have insufficient entropy. If these methods are used to generate cryptographic private keys (such as RSA, ECDSA), the generated keys may be predictable and easily derived or reproduced by attackers.
Exploitation Scenario: In Java-based web applications, keys generated using Random may be exploited by attackers to crack TLS sessions or forge JWT tokens.
Recommendation: Switch to java.security.SecureRandom, which is a random number generator designed for cryptographic scenarios and provides high-entropy output suitable for generating private keys. Alternatively, prioritize using standard libraries or frameworks (such as KeyPairGenerator, KeyFactory) to generate keys.
3. Android System Fails to Properly Initialize SecureRandom in Certain Versions
Severity: High
Description: In certain versions of Android (especially early versions, such as 4.1–4.3), java.security.SecureRandom fails to initialize correctly, resulting in insufficient entropy in the generated random numbers. This is usually due to the system entropy pool (such as /dev/urandom) not being sufficiently filled, or defects in the implementation of SecureRandom, causing the generated random number sequence to have a higher predictability. When used for private key generation, it significantly reduces security.
Exploitation Scenario: On affected Android devices, Bitcoin private keys generated using SecureRandom may be cracked, leading to the theft of funds.
Recommendation: Before calling SecureRandom, explicitly call SecureRandom.setSeed() and combine it with high-entropy sources (such as user input or hardware sensor data) to enhance randomness.
4. The variable type space for storing random numbers during private key generation is too small
Severity: High
Description: During the private key generation process, if a variable type with too small a space (such as a 32-bit integer) is used to store random numbers, it will limit the range and entropy of the random numbers, resulting in insufficient strength of the generated private key.
Exploitation Scenario: Attackers can exploit the weakness of the limited range of random numbers to quickly guess the private key through brute force cracking or precomputed attacks (such as rainbow tables). For example, in the case of the Profanity tool, attackers successfully cracked multiple Ethereum wallets by analyzing the patterns of the generated addresses, stealing a large amount of funds.
Recommendation: Use a sufficiently large variable type (such as 256 bits or higher) to store random numbers to support the full key space (such as the 2²⁵⁶ range of the secp256k1 curve).
Description: The bx seed command in Libbitcoin Explorer (versions 3.0.0 to 3.6.0) uses the Mersenne Twister (MT19937) pseudo-random number generator (PRNG) to generate wallet seeds, which are initialized solely by a 32-bit system time (high_resolution_clock). This limits the entropy space to 2³² (approximately 4.3 billion) possible values, far below the secure requirement of 128-bit or 256-bit entropy. Attackers can brute-force the seed, derive the private key, and thus endanger user funds. This vulnerability is known as “Milk Sad” because the first seed phrase it generates starts with “milk sad.”
Exploitation Scenario: The get_clock_seed() function returns a 32-bit system timestamp (uint32_t), which is used as the seed for the Mersenne Twister. Although std::mt19937 generates seemingly random output, its entropy is limited by the 32-bit seed and cannot provide a security level of 128 bits or higher. When pseudo_random_fill fills the output, expanding it to 256 bits is merely a pseudo-random extension and does not increase the actual entropy.
Recommendation: Replace Mersenne Twister with a cryptographically secure random number generator (such as /dev/urandom, C++’s std::random_device paired with a high-entropy source, or OpenSSL’s RAND_bytes).
6. OpenSSL Random Number Generator Security Risk
Severity: High
Description: The random number generator RAND_pseudo_bytes() in the OpenSSL cryptographic library is used to place num pseudo-random bytes into buf, but it has a security design flaw. The pseudo-random byte sequence generated by RAND_pseudo_bytes() is unique if it is long enough, but it is not necessarily unpredictable. They can be used for non-cryptographic purposes and for specific purposes in some cryptographic protocols, but are generally not used for key generation, etc.
Exploitation Scenario: Low Entropy Key Leakage (LESLI), Attackers can obtain the nonce and, by brute-forcing all possible PIN codes and RNG states, recover the original PIN value.
Recommendation: Avoid using RAND_pseudo_bytes, and completely replace it with RAND_bytes while checking its return value.
0x02 ECDSA Security
1. secp256r1 Backdoor Issue
Severity: Medium
Description: secp256r1 (also known as NIST P-256) is a widely used elliptic curve cryptographic algorithm, but there are concerns about potential backdoors in its generated parameters. During the standardization process, the parameters were provided by the NSA, and the lack of a transparent generation process means they may have been deliberately designed to include weaknesses, allowing specific attackers (such as the NSA) to exploit hidden mathematical relationships to decrypt data or forge signatures.
Exploitation Scenario: Attackers may exploit the backdoor (if it exists) by using the mathematical properties of the known parameters to quickly calculate private keys or predict the output of the random number generator, thereby breaking encrypted communications, forging digital signatures, or stealing sensitive data from encryption systems based on secp256r1 (such as TLS, Bitcoin, SSH).
Recommendation: Consider switching to curves with transparently generated parameters, such as Ed25519 or Secp256k1, to reduce the risk of backdoors.
2. Weak Randomness of k Value in secp256k1 Leading to Private Key Leakage
Severity: High
Description: In the ECDSA signing process of the secp256k1 curve, a random number k (nonce) is required for the signature. If the k value is generated by a weak random number generator (e.g., low-entropy source, insecure PRNG, or predictable seed), an attacker may be able to infer the k value by analyzing the signature data and then directly calculate the private key using the mathematical properties of ECDSA. This vulnerability typically arises from the use of insecure random number generators (such as rand(), Math.random()) or insufficient environmental entropy (such as virtual machines or embedded devices).
Exploitation Scenario: An attacker can collect a small amount of signature data (e.g., r and s values) and, combined with the predictability of weak randomness, reconstruct the k value and derive the private key. In blockchain scenarios (such as Bitcoin, Ethereum), this can lead to the exposure of wallet private keys and theft of funds. For example, if the k value is generated based on a timestamp or a fixed seed, an attacker can quickly recover the private key through brute force cracking or pattern analysis. Similar issues have occurred in early cryptographic wallet implementations, where weak random sources were used to generate k values and were subsequently cracked.
Recommendation: Use deterministic k value generation (RFC 6979), which generates a unique k value based on the private key and message hash, avoiding reliance on the quality of the random number generator.
3. Reuse of k Value in secp256k1 Leads to Private Key Leakage
Severity: High
Description: When using ECDSA signatures on the secp256k1 elliptic curve (widely used in cryptocurrencies like Bitcoin), if the same random number k (nonce) is used for two signatures, the r value in the signature will be the same. An attacker can derive the private key by analyzing these two sets of signatures (r, s1) and (r, s2) along with the corresponding message hashes h1 and h2. This vulnerability stems from the mathematical structure of the ECDSA signature equation; the reuse of k allows the attacker to set up a system of equations and directly solve for the private key d.
Recommendation: Follow the RFC 6979 standard to generate deterministic but unpredictable k values based on the private key and message hash to prevent reuse.
4. Forgeability of ECDSA Signature Values
Severity: Medium
Description: The signature value (r, s) of ECDSA (Elliptic Curve Digital Signature Algorithm) is forgeable, meaning that given a valid signature (r, s), another equivalent valid signature (r, -s mod n) can be generated, where n is the order of the elliptic curve. This mathematical property stems from the symmetry of the modular arithmetic in ECDSA signature verification. If the implementation does not normalize signatures (for example, by enforcing the use of “low s values”), attackers can modify the signature without affecting its validity, potentially bypassing signature verification mechanisms or violating the uniqueness requirements of certain protocols.
Exploitation Scenario: Attackers can exploit the forgeability of signatures to create issues in blockchains (such as Bitcoin, Ethereum) or protocols. For example, in Bitcoin transactions, attackers can modify the s value of the transaction signature to generate a new signature, changing the transaction ID (txid), which may lead to the transaction being rejected or trigger a double-spending risk. Additionally, in some smart contracts or multisignature protocols, non-normalized signatures may be used to bypass verification logic, resulting in financial loss or protocol failure. In 2013, the Bitcoin network experienced a transaction malleability attack due to signature forgeability, affecting exchanges such as Mt. Gox.
Recommendation: Enforce the use of “low s values” (s ≤ n/2), follow the RFC 6979 or BIP-66 standards (adopted by the Bitcoin community), and reject non-standard signatures to eliminate forgeability.
5. ECDSA and Schnorr Signatures Sharing Random Number k Leads to Private Key Leakage
Severity: High
Description: In the Elliptic Curve Digital Signature Algorithm (ECDSA) and Schnorr signatures, if the same random number k (nonce) is used when generating signatures, an attacker can derive the private key by analyzing the signature pairs. This vulnerability stems from the mathematical structural similarity between the two signature schemes, which allows the private key to be reverse-engineered from the known signature equations. Whether k is reused multiple times within the same system or between different signature algorithms, the private key will be fully exposed, enabling the attacker to forge signatures or take control of related accounts.
Recommendation: The input parameters in RFC6979 can include “addition data,” and when deriving k, the information of the signature algorithm can be filled into this field. This allows for the secure reuse of k at the algorithm level.
6. ECDSA can forge a signature value without providing the message m corresponding to the signature value
Severity: Low
Description: When verifying an ECDSA signature, if the verification process only requires the hash value of the message rather than the original message itself, an attacker can construct a forged signature that passes verification without knowing the private key. This vulnerability exploits the mathematical characteristics of the ECDSA verification mechanism, allowing the attacker to choose specific numerical combinations to create a forged signature without knowing the corresponding original message or private key.
Recommendation: When verifying a signature, the original message m must be provided, not just the hash value.
Description: LadderLeak is a side-channel vulnerability present in ECDSA implementations, where attackers can obtain the most significant bit information of the random number (nonce) used in the signing process through cache timing analysis. However, the leakage probability is less than 100% (i.e., “less than 1 bit” of information). This vulnerability exists in the OpenSSL 1.0.2 and 1.1.0 branches and the RELIC toolkit version 0.4.0, particularly affecting ECDSA implementations based on the sect163r1 and NIST P-192 curves.The vulnerability stems from minor time differences caused by improper handling of coordinates in the Montgomery ladder algorithm implementation. Attackers can observe these time differences and use statistical methods to infer the most significant bit of the random number k. Even though the leakage rate is less than 100% (e.g., 99% for P-192 and 97.3% for sect163r1), attackers can still fully recover the private key by collecting a sufficient number of signatures using an improved Bleichenbacher Fourier analysis method.
Exploitation Scenario: In the OpenSSL implementation, the vulnerability manifests in two scenarios — the binary curve case (e.g., sect163r1) and the prime curve case (e.g., NIST P-192). Researchers have used this leakage to fully recover the private key for P-192 with only about ²³⁵ signatures; for sect163r1, only about ²²⁴ signatures are needed. This significantly breaks through the limitations of previous attack techniques, which required at least 2 bits of leakage to achieve a feasible attack.
Recommendation: Coordinate Randomization.
8. Twist Attack Vulnerability in Elliptic Curve Cryptography
Severity: High
Description: There is a serious security vulnerability in the implementation of Elliptic Curve Cryptography (ECC), known as “twist attacks.” These attacks exploit the mathematical properties of elliptic curves and security flaws in the implementation, allowing attackers to extract the victim’s private key under certain conditions. This is particularly the case when using single-coordinate ladder algorithms (such as the Montgomery ladder algorithm) to implement Diffie-Hellman key exchange. If appropriate defensive measures are not taken, attackers may successfully obtain private key information.
Recommendation: Verify that the received point is indeed on the expected curve.
0x03 EdDSA Security
1. Private Key Extraction Vulnerability in the Ed25519 Signature Algorithm
Severity: High
Description: This vulnerability exists in the implementation of the Ed25519 signature algorithm library, primarily due to design flaws in some libraries and incorrect use of the algorithm library interface by users. An attacker can manipulate two signing processes, using the same private key but different public keys to sign the same message, and then directly extract the user’s complete private key by analyzing the results of these two signatures. In the standard implementation, the signature calculation should use the unique public key corresponding to the private key. However, many libraries implement an interface like sign(privateKey, message, publicKey), allowing the caller to provide any public key parameter without verifying whether the public key matches the provided private key. This flaw, combined with the characteristic of using deterministic random numbers in the Ed25519 signature algorithm, allows an attacker to eliminate the deterministic invariants in the signing process through two signatures, thereby extracting the private key extension value used for signing, and thus gaining control of the complete private key. This vulnerability affects all Ed25519 implementation libraries that provide this unsafe interface and do not perform public key verification, including various scenarios that may be used for mobile wallets, hardware wallets, and cloud wallets. Similar attack methods also apply to the Schnorr signature algorithm.
Recommendation: Do not provide an interface like sign(privateKey, message, publicKey), but only provide the sign(privateKey, message) interface, and internally calculate the corresponding public key through the private key.
2. Side-Channel Vulnerability in Ed25519 Signature Algorithm in WolfSSL
Severity: High
Description: Ed25519 is an elliptic curve digital signature algorithm (EdDSA), designed to avoid the need for high-quality random numbers in ECDSA. Ed25519 deterministically derives ephemeral keys from messages and auxiliary keys to eliminate the risk of random number generation. However, research has shown that this deterministic design introduces new vulnerabilities in the context of side-channel attacks. A severe power analysis vulnerability has been discovered in the Ed25519 implementation in the WolfSSL library. An attacker can fully recover the private key by collecting approximately 4,000 power traces of signature operations. The vulnerability stems from the SHA-512 hash function used in the deterministic generation of ephemeral keys, which allows attackers to extract key information using differential power analysis (DPA). Specifically, the modular addition operation in the SHA-512 message scheduling function, due to its non-linear nature, produces observable side-channel leakage. This vulnerability poses a serious threat to IoT devices and embedded systems using WolfSSL to implement Ed25519, as these devices are typically more susceptible to physical access and side-channel attacks.
Recommendation: Modify the Ed25519 implementation to add a random value when calculating the ephemeral key, making it impossible for attackers to predict the input to the hash function. Ensure that the entire first 1024-bit data block contains only the key and the random value, and does not include any bits known to the attacker.
3. Ed25519 Curve Cofactor Not Being 1 Leading to Double-Spending Vulnerability
Severity: High
Description: The Edwards25519 elliptic curve has a cofactor of 8, which means the structure of the point group on the curve includes a large prime-order subgroup G1 and a small subgroup G2 of order 8. When constructing cryptographic protocols based on Edwards25519 (such as ring signatures and RingCT), if the situation where the cofactor is not 1 is not properly handled, it can lead to severe double-spending and even multiple-spending attacks. This vulnerability arises from the failure to ensure during the verification process that the key image (a critical component for preventing double-spending) belongs to the correct subgroup, allowing attackers to construct special transactions that enable the same funds to be spent multiple times. It affects all cryptocurrency projects based on the CryptoNote protocol that use the Edwards25519 curve.
Recommendation: Implement subgroup membership checks for all key images to ensure they belong to the large prime-order subgroup G1.
4. Ed25519 Extensibility Vulnerability in Historical Versions
Severity: Medium
Description: The Ed25519 algorithm itself meets the security requirements for chosen-message attacks, but the extensibility issue allows attackers to modify existing signatures to generate new valid signatures, which may lead to vulnerabilities in systems that assume the uniqueness of signatures (such as repeated verification or failure of tamper detection). This has been fixed in the standard RFC 8032, but old implementations (such as ed25519-dalek version 1.0.1) still pose risks.
Exploitation Scenario: In an Ed25519 signature, the signature is composed of (R, s), where s is a scalar. If an attacker obtains a valid signature (R, s) corresponding to message M and public key A, they can construct a new signature (R, s’), where s’ = s + l (l is the order of the subgroup, which is the prime number 2²⁵² + 27742317777372353535851937790883648493). Due to the modular arithmetic properties of the group, the verifier will check s’ * B == R + h * A (where h = Sha512(R || A || M), and B is the base point), which is equivalent to the original signature, leading to the new signature being accepted as well. For example, if the original s = 123, then s’ = 123 + l will also pass the verification, but the signature is no longer unique.
Recommendation: During the signature verification process, add checks in accordance with the RFC 8032 standard: ensure that s < l (the order of the group). If s >= l, reject the signature.
0x04 Schnorr Security
1. Schnorr Nonce Reuse or Poor Random Number Generation
Severity: High
Description: The security of Schnorr signatures heavily relies on the uniqueness and unpredictability of the random number (nonce, k). If the same nonce is reused in different signatures, an attacker can recover the private key through mathematical calculations. This issue has been widely discussed in theory, but there have been no publicly reported cases in the practical application of Schnorr signatures.
Exploitation Scenario: Although not specific to Schnorr signatures, ECDSA (which has a similar mathematical basis to Schnorr signatures) has had incidents of private key leakage due to nonce reuse in Bitcoin and Ethereum. For example, in the early 2010s, some Bitcoin wallets had nonce reuse due to flaws in their random number generators, which were exploited by hackers to steal funds. Schnorr signatures began to be used in Bitcoin’s Taproot upgrade (introduced in 2021), and since its implementation strictly follows the BIP-340 specification (such as deterministic nonce generation), no similar issues have been observed.
Recommendation: Use deterministic nonce generation (such as RFC 6979) or a cryptographically secure random number generator.
2. Schnorr Related Key Attack
Severity: Low
Description: An academic paper published in 2015 analyzed the security of Schnorr signatures and DSA under related key attacks. The study found that the standard Schnorr signature scheme does not meet full RKA (where the attacker can manipulate the signing key and obtain modified signatures) security, and there are theoretical attack methods. For example, an attacker may forge signatures by tampering with the key. However, the study also proposed that minor modifications to the Schnorr signature scheme (such as adjusting the signature generation method) can achieve full RKA security.
Exploitation Scenario: This is not an actual attack incident, but a theoretical analysis indicating that Schnorr signatures may be at risk in specific side-channel attack scenarios (such as tampering with devices).
Recommendation: Implement key integrity checks or use RKA-resistant variant schemes.
3. Schnorr Side-Channel Attack
Severity: Low
Description: Theoretically, the implementation of Schnorr signatures may be vulnerable to side-channel attacks (such as timing attacks, power analysis, or electromagnetic leakage). These attacks exploit the physical information leakage during the signature generation process to derive the private key or nonce.
Exploitation Scenario: Despite extensive academic research on this topic, there are no publicly reported side-channel attack incidents related to Schnorr signatures.
Recommendation: Implement constant-time operations, use hardware or algorithms resistant to side-channel attacks.
0x05 BLS Security
1. Extensibility Vulnerability in Filecoin BLS Signature Verification
Severity: High
Description: An extensibility vulnerability in BLS signature verification was discovered in the Lotus implementation of Filecoin. BLS signatures can be represented in two different forms: serialized and compressed, both of which can be successfully verified by the VerifyCompressed method of the BLST library. However, the block validation logic in Lotus uses the block header CID containing the signature to identify the uniqueness of the block, leading to the following security issues: If the same block uses two different forms of BLS signatures, it will be regarded as two different blocks because their CIDs are different. Attackers can exploit this vulnerability by submitting blocks with the same content but different signature formats, bypassing duplicate block detection, which may lead to blockchain forks, double-spending attacks, or consensus failures.
Recommendation: Convert all signatures to a unified format (either all serialized or all compressed) before verifying the signatures.
2. Zero-Value-Related Vulnerabilities in BLS Libraries and the “Splitting Zero” Attack
Severity: High
Description: Researchers have discovered a series of serious security vulnerabilities related to zero-value handling in four mainstream BLS (Boneh-Lynn-Shacham) cryptographic libraries and the BLS standard draft, collectively referred to as the “splitting zero” attack. These vulnerabilities stem from defects in the handling of the special value “0” in cryptographic algorithms, which can lead to signature verification bypass, private key recovery, denial of service, and other serious security issues. It is particularly noteworthy that the GitHub report also mentioned some additional zero-value-related vulnerabilities, including that in the supranational/blst library, zero-length signatures or zero-length messages can cause the program to crash, and in modular arithmetic, errors arise in handling inverse(0) mod p = 0, whereas inverse(p) mod p = 1. The BLS signature scheme, known for its unique aggregation properties, is widely used in blockchain and distributed systems. These vulnerabilities may have significant security implications for large systems that rely on these libraries.
Exploitation Scenarios: According to the research document, the “splitting zero” attack mainly includes the following types: zero signature verification bypass, zero public key attack, library crash vulnerability, zero-value issues in modular arithmetic, and zero-value manipulation in aggregated signatures.
Recommendation: Clearly define and consistently implement handling strategies for zero values (zero-length inputs, zero points, zero scalars, etc.).
3. BLS Rogue Key Attack Vulnerability in Multi-Signature
Severity: High
Description: In the BLS signature scheme, the aggregation of public keys and signatures is simply achieved by summation. An attacker can create a “rogue key” by setting the secret key to 0 and calculating the additive inverse of the honest keys to nullify the contributions of honest participants.
Recommendation: Implement strict verification of Proof-of-Possession (PoP) mechanisms, avoid relying on simple summation aggregation; consider using non-linear aggregation or additional randomness.
0x06 RSA Security
1. RSA Key Length Too Short
Severity: Medium
Description: The key length of RSA (usually expressed in bits, such as 1024 bits, 2048 bits) determines the size of 𝑛, thereby affecting the computational complexity of factorization. If the key length is too short (e.g., 512 bits or lower), attackers can relatively easily factorize 𝑛 using modern computing resources (such as high-performance computers or distributed computing networks), thereby deriving the private key.
Recommendation: NIST recommends using at least a 2048-bit RSA key; for high-security requirements, 3072-bit or 4096-bit keys can be used.
2. Approximate Prime Vulnerability in RSA Key Generation
Severity: High
Description: The security of the RSA encryption algorithm relies on the computational difficulty of the integer factorization problem, where the modulus n is the product of two large prime numbers p and q. When p and q are chosen too close to each other, a serious security vulnerability arises, making the factorization of n significantly easier and potentially allowing malicious attackers to recover the RSA private key. This vulnerability stems from the fact that Fermat’s factorization method and its variants can efficiently factor composite numbers with factors that are close to each other. When p and q are very close, their average √(pq) is very close to (p+q)/2, and effective factorization can be achieved by trying values around (p+q)/2.
Exploitation Scenario: Specifically, if |p-q| is small, we can define the integer values s = (p+q)/2 and d = (p-q)/2, so that p = s+d, q = s-d, and n = pq = s²-d². This transforms into checking whether n+d² is a perfect square. When p and q are close, the value of d is small, making this search very efficient.
Recommendation: Follow NIST standards (such as FIPS 186–4), which require |p-q| > 2^(nlen/2–100), where nlen is the bit length of the modulus n; for a 2048-bit RSA key, the difference between p and q should be at least 2⁹²⁴ bits; consider more stringent standards such as |p-q| > 2^(nlen/2) and |p-(n/p)| > 2^(nlen/2).
3. RSA Modulus Reuse Vulnerability
Severity: Very High
Description: The security of RSA encryption is based on the difficulty of the integer factorization problem, where the modulus n is the product of two large prime numbers p and q. In a normal RSA implementation, each key pair has a unique modulus n and corresponding unique public key exponent e and private key exponent d. When the modulus n is reused, even with different public key exponents e and private key exponents d, if an attacker obtains multiple public keys using the same modulus, they can recover the private key through simple mathematical calculations.
Recommendation: A new modulus n must be generated each time an RSA key pair is generated; sharing the modulus between different key pairs, users, or systems is prohibited.
4. RSA Small Public Exponent Vulnerability
Severity: High
Description: The security of the RSA algorithm is based on the computational difficulty of factoring large integers, where the public key consists of the modulus n (the product of two large prime numbers p and q) and the exponent e, while the private key mainly consists of the exponent d, satisfying e·d ≡ 1 (mod φ(n)). When a very small value for e is chosen, especially e=3, although the encryption operation is simplified to calculating c = m³ mod n, it introduces mathematical weaknesses.
Exploitation Scenarios: These vulnerabilities mainly manifest in attack scenarios such as Direct Root Attack, Håstad Broadcast Attack, Coppersmith’s Related Message Attack, and Bleichenbacher Padding Attack, and are particularly dangerous in practical applications because many developers may choose small exponents to improve performance, especially in resource-constrained environments, while remaining unaware of or overlooking the associated security risks.
Recommendation: Avoid using e=3, e=5, or other very small values; it is recommended to use e=65537 (2¹⁶+1), which is a large prime number and still maintains reasonable performance.
5. RSA Small Private Exponent Vulnerability
Severity: High
Description: The security of the RSA algorithm is based on the computational difficulty of the integer factorization problem, where the public key consists of the modulus n (the product of two large prime numbers p and q) and the public exponent e, while the private key mainly consists of the exponent d, which satisfies ed ≡ 1 (mod φ(n)). The private key exponent d is used for decryption and signing operations, and its computational complexity is proportional to the size of d. When a small private key exponent d is used, even if the modulus n is very large, the entire encryption system may be compromised. This vulnerability allows attackers to recover the private key through mathematical methods without performing the difficult integer factorization, thereby completely undermining the security guarantee of RSA.
Exploitation Scenario: To improve the efficiency of decryption and signing, some implementations may deliberately choose a smaller value for d, which can lead to several serious mathematical attacks, including the Wiener Attack, Boneh-Durfee Attack, and Partial Key Exposure Attack.
Recommendation: Use a sufficiently large private key exponent d: Ensure that d is at least of the same order as φ(n), and avoid deliberately choosing a small value for d. In practice, randomly selecting e usually results in d being of the same order as φ(n), which is secure.
6. RSA No Padding Short Message Attack Vulnerability
Severity: High
Description: When using RSA to directly encrypt a message ( m ), the encryption process computes ( c = m^e \mod n ), where ( e ) is the public key exponent and ( n ) is the modulus. If the original message ( m ) is very small relative to the modulus ( n ) (( m \ll n )), then ( m^e ) may be less than ( n ), resulting in ( c = m^e ) instead of ( c = m^e \mod n ). In this case, an attacker can simply compute ( m = c^{(1/e)} ) (i.e., take the ( e )-th root of the ciphertext ( c )) to directly recover the original message without knowing the private key.
Recommendation: When implementing RSA encryption, use PKCS#1 v2.1 OAEP (Optimal Asymmetric Encryption Padding), which adds randomness and extends the message size.
7. RSA Padding Oracle Attack Vulnerability
Severity: High
Description: When using PKCS#1 v1.5 padding in RSA encryption, if the server returns specific error messages (e.g., “invalid padding” vs. “other errors”) when decrypting ciphertext with invalid padding, this creates a “padding oracle.” Attackers can repeatedly send modified ciphertexts and observe the responses to narrow down the plaintext range.
Recommendation: Ensure that the RSA decryption and padding validation processes do not leak information in terms of time and return messages.
8. RSA Timing Attack Vulnerability
Severity: High
Description: An RSA timing attack is a side-channel attack where an attacker can infer private key information by precisely measuring the execution time differences in RSA operations (such as decryption or signing), thereby completely breaking the RSA cryptographic system. Even though the RSA algorithm is mathematically secure, its implementation can lead to this serious vulnerability. This type of attack primarily exploits the modular exponentiation operation (m^d mod n) in RSA private key operations, which typically uses algorithms like “square-and-multiply” or “Montgomery reduction.” In these algorithms, the processing time varies based on the bit pattern of the private key d. For example, in the basic square-and-multiply algorithm, an additional multiplication operation is performed when the private key bit is 1, but not when it is 0, resulting in measurable time differences.
Exploitation Scenario: By sending carefully selected messages and measuring the processing time, an attacker can deduce each bit of the private key d. With a sufficient number of measurement samples, the attacker can fully reconstruct the private key, enabling them to decrypt all communications or forge digital signatures.
Recommendation: Ensure that RSA operations are completed in a fixed amount of time, regardless of the private key bit pattern. Use cryptographic libraries that natively support constant-time operations.
9. RSA Malleability Attack Vulnerability
Severity: High
Description: RSA encryption has multiplicative malleability: if c = m^e mod N, then for any k, c’ = (c*k^e) mod N decrypts to m*k mod N. Attackers can exploit this property to manipulate ciphertexts without triggering decryption errors.
Exploitation Scenario: Suppose an encrypted bank transfer message m = “Transfer 100 yuan”, with ciphertext c = m^e mod N. An attacker calculates c’ = c * (2^e) mod N, which decrypts to “Transfer 200 yuan”.This is effective in protocols without signatures, such as early e-cash systems or custom encryption schemes, and has been exploited in real-world attacks, for example, by modifying encrypted votes or financial data, leading to vulnerabilities in some blockchains or protocols in the 2010s.
Recommendation: Combine the use of digital signatures (such as RSA-PSS) or message authentication codes (MAC) to verify message integrity and prevent tampering.
0x07 Hash Security
1. Hash Collision Birthday Attack
Severity: High
Description: The hash birthday attack is based on the “birthday paradox” in probability theory, which can significantly reduce the computational complexity required to find a hash collision. For an n-bit hash function, theoretically, it would take 2^n attempts to find a specific collision, but with the birthday attack, it only takes about 2^(n/2) attempts to find a collision with a 50% probability for any two inputs to produce the same hash value.
Exploitation Scenario: Assuming the use of the MD5 hash function (128-bit output), an attacker can find a collision by generating approximately 2⁶⁴ variant messages. For example, an attacker can create two different contract files A and B (A is legitimate, B is tampered with) such that MD5(A) = MD5(B). If the system uses MD5 to verify signatures, the attacker can forge B using A’s signature, leading to incidents like the 2004 Flaming attack, where MD5 collisions were used to generate fake certificates, or the 2012 Flame malware that exploited collisions to bypass Windows update verification.
Recommendation: Adopt modern hash algorithms with strong collision resistance, such as SHA-256, SHA-3, or BLAKE2, and avoid using algorithms like MD5 and SHA-1 that have been proven to be insecure.
2. Length Extension Attack on Hash Functions
Severity: High
Description: A Length Extension Attack is a cryptographic attack targeting hash functions that use the Merkle-Damgård construction, such as MD5, SHA-1, and the SHA-2 family. An attacker can exploit the internal workings of these hash functions to compute the value of H(message||padding||extension) without knowing the message itself, provided they know H(message) and the length of the message. Here, extension is arbitrary data chosen by the attacker. This attack is feasible because Merkle-Damgård structured hash algorithms process the input into fixed-length data blocks, and the hash value of each block depends on the hash state of the previous block. This means an attacker can continue the hash computation from a known hash state by adding more data blocks without knowing the original data that produced that state. This vulnerability is particularly dangerous in web applications, API authentication, identity verification systems, and blockchain applications, especially when systems use a simple validation pattern like H(secret||message).
Recommendation: Adopt modern hash algorithms that do not use the Merkle-Damgård construction, such as SHA-3 or BLAKE2, which are inherently immune to length extension attacks.
0x08 AES Security
1. AES Encryption Key Length Insufficient
Severity: High
Description: Standard AES supports key lengths of 128 bits, 192 bits, and 256 bits. If the key length used is too short (for example, less than 128 bits, such as 56 bits or lower), the encryption will become vulnerable. Attackers can quickly decrypt the data through brute-force attacks or dictionary attacks, which may lead to the leakage of sensitive information, data tampering, or system intrusion. Especially in modern computing environments, high-performance GPUs and distributed computing can accelerate the cracking process.
Exploitation Scenario: According to the guidelines of NIST (National Institute of Standards and Technology), key lengths below 128 bits are considered insecure and cannot withstand contemporary threats.
Recommendation: Always use AES keys of at least 128 bits, and prioritize 256 bits for higher security. Avoid custom or sub-standard lengths.
2. IV/Nonce Reuse Attack in AES
Severity: High
Description: The IV/Nonce reuse attack is a serious security threat to AES encryption modes. When the same initialization vector (IV) or nonce is reused under the same key, it can lead to severe security issues. In CTR mode, reuse generates the same keystream, allowing attackers to directly obtain the XOR result of two plaintexts through the XOR operation of ciphertexts, and then recover the original plaintext through frequency analysis and other methods. In GCM mode, nonce reuse not only leaks plaintext information but also completely breaks the authentication mechanism, allowing attackers to forge authentication tags. In CBC mode, although the impact is relatively smaller, it still leaks information about identical plaintext blocks. The danger of this attack lies in the fact that it does not require obtaining the key; attackers can infer plaintext content by observing ciphertext patterns, and in some cases, they can even fully recover the key.
Exploitation Scenarios: The most typical case is the Android encryption vulnerability discovered in 2016, where the file system encryption used AES-CBC mode but had a defect in IV generation, leading to the possibility of the same file content being encrypted with the same IV at different times, thus leaking file pattern information. Another famous example is the Key Reinstallation Attack (KRACK) in some WPA2 implementations, where attackers force nonce reuse by replaying handshake messages, leading to the cracking of AES-CCMP encryption streams. In web applications, some developers mistakenly use fixed IVs or predictable IVs based on timestamps to encrypt user data, allowing attackers to infer sensitive information by comparing encrypted data from different users. Similar issues have also occurred in cloud storage services, where design flaws in deduplication mechanisms led to the same files being encrypted with the same parameters, resulting in data leakage.
Recommendation: Ensure that a unique and unpredictable IV/Nonce is used for each encryption operation.
3. AES-ECB Mode Weak Encryption Risk
Severity: High
Description: Electronic Codebook mode (ECB — Electronic Codebook) is an operation mode of AES encryption and has serious security vulnerabilities. The main flaw of ECB mode is that it always generates the same ciphertext block for the same plaintext block, regardless of the block’s position in the message or the content encrypted before. This deterministic encryption mode means that the encrypted data still retains the patterns and structural characteristics of the original data, failing to provide the semantic security required by modern cryptography. Under ECB mode, the ciphertext may reveal the pattern information of the plaintext, allowing attackers to infer part or all of the plaintext content without knowing the key. This weak encryption mode is particularly unsuitable for encrypting large datasets, structured data, or data containing repetitive information.
Exploitation Scenario: When encrypting an image using ECB mode, the outline and main features of the image are still visible after encryption. A classic example is the ECB penguin image, where the outline of the penguin remains clearly distinguishable even after “encryption.”
Recommendation: ECB mode should be completely avoided unless encrypting a single block of data that is smaller than the block size (16 bytes).
4. AES-CBC Padding Attack
Severity: High
Description: The AES-CBC Padding Attack is a side-channel attack targeting symmetric encryption systems using the CBC mode. This attack exploits information leaked by the decryption system during padding validation, allowing attackers to decrypt ciphertext byte by byte without knowing the encryption key. When the encryption system returns any information about whether the padding is valid (such as error messages, return codes, or differences in response times), attackers can systematically modify the ciphertext and observe system responses to gradually deduce the original plaintext content. The attack principle is based on the decryption characteristics of the CBC mode. When ciphertext is decrypted, the previous ciphertext block is XORed with the current decrypted block. By carefully constructing and modifying ciphertext blocks, attackers can use the padding validation mechanism as an “Oracle” to infer the decrypted intermediate values and ultimately recover the complete plaintext data. Additionally, using the CBC-R (CBC Reverse) technique, attackers can even forge ciphertext that can be correctly decrypted by the system.
Exploitation Scenarios: Historically, multiple TLS implementations have been affected by such attacks, such as POODLE (2014) and the “Lucky Thirteen” attack (2013). Attackers can intercept encrypted communications, modify the ciphertext, and analyze server responses to eventually crack the encrypted content.
Recommendation: Adopt AEAD (Authenticated Encryption with Associated Data) cipher modes, such as AES-GCM or ChaCha20-Poly1305.
0x09 Other Cryptographic Protocols
1. Weak Fiat-Shamir Transformation
Severity: High
Description: The Fiat-Shamir transformation is an important method for converting interactive zero-knowledge proof protocols into non-interactive proof protocols, replacing the random challenges between the prover and the verifier with the output of a hash function. The Frozen Heart vulnerability refers to the implementation of the “weak Fiat-Shamir” transformation, which only hashes part of the prover’s message without hashing public information (such as parameters, public inputs, etc.). This allows attackers to forge proofs and deceive verifiers by precomputing the public key A without knowing the secret value. This vulnerability affects several mainstream zero-knowledge proof systems, including Bulletproofs, Plonk, Spartan, and Wesolowski’s VDF.
Recommendation: Ensure that all public input data is also included in the random number generation process in the implementation of the Fiat-Shamir transformation.
2. GG18 and GG20 Paillier Key Vulnerability
Severity: High
Vulnerability Description: This vulnerability exists in the specifications of two widely used multi-party computation (MPC) protocols, GG18 and GG20, affecting over 10 wallets and libraries (including Binance Custody services). The root cause of the vulnerability lies in the protocol implementation, which does not check whether the attacker’s Paillier modulus N contains small factors or is a product of two primes. Attackers can exploit this vulnerability to interact with the signing parties in the MPC protocol, steal their secret shares, and ultimately obtain the master secret key, thereby fully extracting the private key and stealing all funds from the encrypted wallet.
Recommendation: Ensure that the Paillier public keys of the signing parties are checked for small prime factors to prevent attackers from using malicious moduli containing small factors (such as primes of the size of 2²⁰).
Summary
The SlowMist Security Team has open-sourced Common- Cryptographic-Risks-in-Blockchain-Applications on GitHub, aiming to systematically uncover high-risk security vulnerabilities hidden in critical components such as private key generation, digital signatures, hash functions, and symmetric encryption.
Web3 project teams can refer to the detailed analyses of vulnerability principles, exploitation scenarios, and remediation recommendations in this report to deepen their understanding of cryptographic security, avoid common implementation pitfalls, and better safeguard both project and user assets.
About SlowMist
SlowMist is a threat intelligence firm focused on blockchain security, established in January 2018. The firm was started by a team with over ten years of network security experience to become a global force. Our goal is to make the blockchain ecosystem as secure as possible for everyone. We are now a renowned international blockchain security firm that has worked on various well-known projects such as HashKey Exchange, OSL, MEEX, BGE, BTCBOX, Bitget, BHEX.SG, OKX, Binance, HTX, Amber Group, Crypto.com, etc.
SlowMist offers a variety of services that include but are not limited to security audits, threat information, defense deployment, security consultants, and other security-related services. We also offer AML (Anti-money laundering) software, MistEye (Security Monitoring), SlowMist Hacked (Crypto hack archives), FireWall.x (Smart contract firewall) and other SaaS products. We have partnerships with domestic and international firms such as Akamai, BitDefender, RC², TianJi Partners, IPIP, etc. Our extensive work in cryptocurrency crime investigations has been cited by international organizations and government bodies, including the United Nations Security Council and the United Nations Office on Drugs and Crime.
By delivering a comprehensive security solution customized to individual projects, we can identify risks and prevent them from occurring. Our team was able to find and publish several high-risk blockchain security flaws. By doing so, we could spread awareness and raise the security standards in the blockchain ecosystem.
