This article is reprinted with permission from Slow Mist Technology, author: Slow Mist Security Team, copyright belongs to the original author.

Cryptography is the cornerstone of Web3 security. From the generation of private keys to the signing of transactions, 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, lacking sufficient vigilance regarding the nuances of underlying cryptographic implementations. The use of insecure random number generators, incorrect calls to cryptographic libraries, or misunderstandings of algorithm characteristics can introduce fatal vulnerabilities, leading to private key leaks, signature forgery, and ultimately causing irretrievable asset losses.

Typically, project teams rely on security audits to identify such issues. However, audits, as a form of post-verification, are difficult to cover the entire project lifecycle. Many vulnerabilities are rooted in the early stages of development choices and design. If the team does not possess basic cryptographic security knowledge, they cannot avoid risks from the source.

Therefore, the Slow Mist Security Team has open-sourced common cryptographic risks in blockchain applications, hoping to consolidate typical cases of cryptographic misuse and best practices accumulated from frontline offense and defense. We expect project teams to build a solid cryptographic security defense from the beginning of development, ultimately establishing independent and continuous secure coding capabilities.

1. Using JavaScript Math.random or time-based seed to generate random numbers

Severity: High

Description: JavaScript's Math.random() is a pseudo-random number generator (PRNG) that is not suitable for cryptographic security scenarios. Its implementation relies on the browser or JavaScript engine (such as V8's Xorshift128+), and the seed and algorithm are often uncontrollable and insufficiently unpredictable, which may lead to the generated random number sequence being guessed or reproduced by attackers.

Usage Scenario: This can lead to key cracking, session hijacking, or game cheating when generating cryptographic keys, session tokens, CSRF tokens, or random events in games.

Recommendation: Preferably use crypto.getRandomValues() (Web Crypto API) to generate cryptographically secure random numbers, suitable for sensitive scenarios such as keys and tokens.

2. Using Java's insecure 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) whose seeds and algorithms (such as linear congruential generators) are predictable and lack entropy. If these methods are used to generate cryptographic private keys (such as RSA, ECDSA), the generated keys may have predictability, making them easy for attackers to derive or reproduce.

Usage 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, providing high-entropy output suitable for generating private keys. Alternatively, prioritize using standard libraries or frameworks (such as KeyPairGenerator, KeyFactory) to generate keys.

Android systems in certain versions have SecureRandom not initialized correctly

Severity: High

Description: In certain Android versions (especially early versions, such as 4.1-4.3), java.security.SecureRandom was not initialized correctly, leading to insufficient entropy in the generated random numbers. This is often due to the system entropy pool (such as /dev/urandom) not being sufficiently filled, or defects in the implementation of SecureRandom, resulting in a higher predictability of the generated random number sequence, significantly reducing security when used for private key generation.

Usage Scenario: On affected Android devices, Bitcoin private keys generated using SecureRandom may be cracked, leading to stolen funds.

Recommendation: Before calling SecureRandom, explicitly call SecureRandom.setSeed() and enhance randomness with high-entropy sources (such as user input or hardware sensor data).

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 keys.

Usage Scenario: Attackers can exploit the weakness of limited random number range to quickly guess private keys through brute force or pre-computation attacks (such as rainbow tables). For example, in the case of the Profanity tool, attackers successfully cracked multiple Ethereum wallets by analyzing the generated address patterns, stealing a large amount of funds.

Recommendation: Use sufficiently large variable types (such as 256 bits or higher) to store random numbers to support the complete key space (such as the 2^256 range of the secp256k1 curve).

Libbitcoin Mersenne Twister weak entropy vulnerability

Severity: High

Description: The bx seed command of 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 (highresolutionclock). This limits the entropy space to 2^32 (about 4.3 billion) possible values, far below the secure requirements of 128-bit or 256-bit entropy. Attackers can reproduce the seed through brute force, thereby deriving private keys and jeopardizing user fund security. This vulnerability is referred to as "Milk Sad," as the first generated seed phrase starts with "milk sad."

Usage Scenario: getclockseed() returns only a 32-bit timestamp (uint32t) as the seed for the Mersenne Twister. Although std::mt19937 generates seemingly random output, its entropy is limited by the 32-bit seed, failing to provide a security level of 128 bits or higher. When pseudorandom_fill fills the output, extending to 256 bits is merely pseudo-random expansion, not increasing actual entropy.

Recommendation: Replace Mersenne Twister with a cryptographically secure random number generator (such as /dev/urandom, C++'s std::randomdevice combined with high-entropy sources, or OpenSSL's RANDbytes).

6. OpenSSL random number generator security risks

Severity: High

Description: The random number generator RANDpseudobytes() in the OpenSSL cryptographic library is used to place num pseudo-random bytes into buf, but it has security design flaws. The pseudo-random byte sequence generated by RANDpseudobytes() is unique if the length is long enough, but it is not necessarily unpredictable. They can be used for non-cryptographic purposes and in certain cryptographic protocols for specific purposes, but are generally not used for key generation, etc.

Vulnerability Example: Low-entropy key leakage (LESLI), where an attacker can recover the original PIN value by obtaining the nonce and brute-forcing all possible PIN codes and RNG states.

Recommendation: Avoid using RANDpseudobytes, completely replace it with RAND_bytes, and check its return value.

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 parameter generation. The parameters were provided by the NSA during the standardization process, lacking a transparent generation process, and 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.

Usage Scenario: Attackers may exploit the backdoor (if it exists) to quickly compute private keys or predict random number generator outputs through the mathematical properties of known parameters, thereby cracking encrypted communications, forging digital signatures, or stealing sensitive data from cryptographic 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 backdoor risks.

2. Weak randomness of k value in secp256k1 leads to private key leakage

Severity: High

Description: In the ECDSA signing process of the secp256k1 curve, a random number k (nonce) is required for signing. If the k value is generated by a weak random number generator (for example, low-entropy sources, insecure PRNGs, or predictable seeds), attackers may infer the k value by analyzing the signature data, and then use the mathematical properties of ECDSA to directly compute the private key. This vulnerability typically arises from using insecure random number generators (such as rand(), Math.random()) or insufficient environmental entropy (such as virtual machines or embedded devices).

Usage Scenario: Attackers can reconstruct the k value and derive the private key by collecting a small amount of signature data (for example, r and s values) combined with the predictability of weak random numbers. In blockchain scenarios (such as Bitcoin, Ethereum), this may lead to wallet private key exposure and stolen funds. For example, if the k value is generated based on a timestamp or fixed seed, attackers can quickly recover the private key through brute force or pattern analysis. Similar issues have occurred in early cryptographic wallet implementations, where k values were cracked due to the use of weak random sources.

Recommendation: Use deterministic k value generation (RFC 6979), generating a unique k value based on the private key and message hash, avoiding reliance on the quality of random number generators.

3. k value reuse 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 signatures will be the same. Attackers 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 arises from the mathematical structure of the ECDSA signature equation, where the reuse of k allows attackers to establish a system of equations to directly solve for the private key d.

Recommendation: Follow the RFC 6979 standard to generate a deterministic but unpredictable k value based on the private key and message hash to prevent reuse.

4. Forgability of ECDSA Signature Values

Severity: Medium

Description: The signature values (r, s) of ECDSA (Elliptic Curve Digital Signature Algorithm) exhibit forgability, 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 arises from the symmetry of the modular arithmetic in ECDSA signature verification. If the implementation does not normalize signatures (for example, enforcing the use of "low s values"), attackers can modify the signature without affecting its validity, potentially bypassing signature verification mechanisms or undermining the uniqueness requirements of certain protocols.

Usage Scenario: Attackers can exploit signature forgability to create issues in blockchain (such as Bitcoin, Ethereum) or protocols. For example, in Bitcoin transactions, attackers can modify the s value of a transaction signature to generate a new signature, changing the transaction ID (txid), leading to transaction rejection or triggering double-spending risks. Additionally, in certain smart contracts or multi-signature protocols, non-normalized signatures may be used to bypass verification logic, resulting in fund losses or protocol failures. In 2013, the Bitcoin network experienced transaction malleability attacks due to signature forgability, affecting exchanges like Mt. Gox.

Recommendation: Enforce the use of "low s values" (s ≤ n/2), adhere to the RFC 6979 or BIP-66 standards (adopted by the Bitcoin community), and reject non-normalized signatures to eliminate forgability.

5. Shared Random Number k in ECDSA and Schnorr Signatures Leading 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 shared during signature generation, attackers can derive the private key by analyzing the signatures. This vulnerability arises from the mathematical similarity of the two signature schemes, allowing the private key to be inferred from known signature equations. Whether signing multiple times within the same system or reusing k across different signature algorithms, the private key can be fully exposed, enabling attackers to forge signatures or control related accounts.

Recommendation: The input parameters in RFC 6979 can include "addition data." When generating k, the information about the signature algorithm can be filled into this field, allowing for secure reuse of k at the algorithmic level.

6. ECDSA Can Produce Forged Signature Values Without Providing the Corresponding Message m

Severity: Low

Description: When verifying ECDSA signatures, if the verification process only requires the hash of the message rather than the original message itself, attackers can construct a forgery that passes verification based on known valid signatures without knowing the private key. This vulnerability exploits the mathematical properties of the ECDSA verification mechanism, allowing attackers to create forged signatures by selecting specific value combinations without knowing the corresponding original message or private key.

Recommendation: The original message m must be provided during signature verification, not just the hash value.

7. Nonce Side-Channel Attack Vulnerability in ECDSA Signatures

Severity: High

Description: LadderLeak is a side-channel vulnerability present in ECDSA implementations, where attackers can obtain information about the most significant bits of the random number (nonce) used during the signing process through cache timing analysis, although the leakage probability is less than 100% (i.e., "less than 1 bit" of information). This vulnerability exists in OpenSSL versions 1.0.2 and 1.1.0, as well as in RELIC toolkit version 0.4.0, particularly affecting ECDSA implementations based on curves sect163r1 and NIST P-192. The vulnerability arises from slight timing differences due to improper coordinate handling in the Montgomery ladder algorithm implementation. Attackers can observe these timing differences and use statistical methods to infer the most significant bit of the random number k. Even if this leakage rate is below 100% (e.g., 99% for P-192 and 97.3% for sect163r1), attackers can fully recover the private key after collecting a sufficient number of signatures using improved Bleichenbacher Fourier analysis methods.

Vulnerability Example: For OpenSSL implementations, the vulnerability manifests in both binary curve cases (such as sect163r1) and prime curve cases (such as NIST P-192). Researchers have successfully recovered the complete private key for P-192 with approximately 2^35 signatures; for sect163r1, only about 2^24 signatures were needed. This significantly breaks the limitations of previous attack techniques, which required at least 2 bits of leakage for a feasible attack.

Recommendation: Coordinate randomization.

8. Twist Curve Attack Vulnerability in Elliptic Curve Cryptography

Severity: High

Description: A serious security vulnerability exists in elliptic curve cryptography (ECC) implementations, known as "twist attacks." These attacks exploit the mathematical properties of elliptic curves and security flaws in implementations, allowing attackers to extract the victim's private key under specific conditions. Particularly when using single-coordinate ladder algorithms (such as the Montgomery ladder algorithm) for 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.

1. Private Key Extraction Vulnerability in 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 usage of algorithm library interfaces by users. Attackers can manipulate two signing processes, using the same private key but different public keys to sign the same message, and then analyze the results of these two signatures to directly extract the user's complete private key. In standard implementations, signature calculations should use the unique public key corresponding to the private key. However, many libraries implement interfaces like sign(privateKey, message, publicKey), allowing callers to provide arbitrary public key parameters without verifying whether the public key matches the provided private key. This flaw, combined with the deterministic random number usage characteristic of the Ed25519 signature algorithm, allows attackers to eliminate the deterministic invariants in the signing process through two signatures, thereby extracting the private key extension value usable for signing, ultimately gaining complete control over the private key. This vulnerability affects all Ed25519 implementation libraries that provide such unsafe interfaces 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 interfaces like sign(privateKey, message, publicKey); only provide the sign(privateKey, message) interface, and internally calculate the corresponding public key from 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 aims to eliminate the risks of random number generation by deterministically deriving ephemeral keys from messages and auxiliary keys. However, research has shown that this deterministic design introduces new vulnerabilities in side-channel attack environments. A severe power analysis vulnerability was discovered in the Ed25519 implementation of the WolfSSL library, where attackers can fully recover the private key by collecting power traces from approximately 4,000 signature operations. The vulnerability arises from the use of the SHA-512 hash function in the deterministic generation of the ephemeral key, allowing attackers to extract key information using differential power analysis (DPA). Specifically, the modular addition operation used in the SHA-512 message scheduling function produces observable side-channel leakage due to its non-linear characteristics. This vulnerability poses a serious threat to IoT devices and embedded systems using WolfSSL's Ed25519 implementation, as these devices are often 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 random value, without including any bits known to the attacker.

3. Double-Spending Vulnerability Caused by Cofactor Not Equal to 1 in Ed25519

Severity: High

Description: The Edwards25519 elliptic curve has a cofactor of 8, meaning that the group structure of points on the curve includes a large prime order subgroup G1 and a small order subgroup G2 with an order of 8. When building cryptographic protocols (such as ring signatures and RingCT) based on Edwards25519, if this cofactor not equal to 1 is not handled correctly, it may lead to serious double-spending or even multiple-spending attacks. This vulnerability arises from the failure to ensure that the key image (a critical component for preventing double-spending) belongs to the correct subgroup during the verification process, allowing attackers to construct special transactions that enable the same funds to be spent multiple times. This 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. Extensibility Vulnerability in Historical Versions of Ed25519

Severity: Medium

Description: The Ed25519 algorithm itself satisfies the security of chosen-message attacks, but the extensibility issue allows attackers to modify existing signatures to generate new valid signatures, potentially leading to vulnerabilities in systems that assume signature uniqueness (such as duplicate verification or tampering detection failures). This issue has been fixed in the standard RFC 8032, but older implementations (such as ed25519-dalek version 1.0.1) still carry risks.

Vulnerability Example: In Ed25519 signatures, the signature consists 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, a prime number 2^252 + 27742317777372353535851937790883648493). Due to the properties of modular arithmetic in the group, the verifier will check s' * B == R + h * A (where h = Sha512(R || A || M), B is the base point), which is equivalent to the original signature, leading to the acceptance of the new signature as well. For example, if the original s = 123, then s' = 123 + l will also pass verification, but the signature is no longer unique.

Recommendation: During the signature verification process, add checks according to the RFC 8032 standard to ensure s < l (the order of the group). If s >= l, reject the signature.

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 across different signatures, an attacker can recover the private key through mathematical calculations. This issue has been widely discussed theoretically, but there have been no publicly reported cases of nonce reuse in practical applications of Schnorr signatures.

Vulnerability Example: Although not specific to Schnorr signatures, ECDSA (which has a similar mathematical foundation to Schnorr signatures) has experienced incidents in Bitcoin and Ethereum where nonce reuse led to private key leakage. For example, in the early 2010s, some Bitcoin wallets suffered from nonce reuse due to flaws in 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 due to its implementation following strict BIP-340 specifications (such as deterministic nonce generation), similar issues have not been observed.

Recommendation: Use deterministic nonce generation (such as RFC 6979) or cryptographically secure random number generators.

2. Schnorr Related-Key Attack

Severity: Low

Description: A 2015 academic paper analyzed the security of Schnorr signatures and DSA under related-key attacks. The study showed that the standard Schnorr signature scheme does not meet complete RKA (related-key attack) security when facing RKA (where an attacker can manipulate the signing key and obtain modified signatures), presenting theoretical attack methods. For example, an attacker might forge signatures by tampering with the key.

Vulnerability Example: This is not an actual attack event but a theoretical analysis indicating that Schnorr signatures may face risks in specific side-channel attack scenarios (such as tampering with devices).

Recommendation: Incorporate key integrity checks in implementations or use RKA-resistant variant schemes.

3. Schnorr Side-Channel Attacks

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 physical information leakage during the signature generation process to deduce the private key or nonce.

Vulnerability Example: Although there has been extensive research on this in academia, there have been no publicly reported side-channel attack incidents related to Schnorr signatures.

Recommendation: Implement constant-time operations and use side-channel-resistant hardware or algorithms.

1. Extensibility Vulnerability in Filecoin BLS Signature Verification

Severity: High

Description: A vulnerability related to extensibility was discovered in the BLS signature verification of Filecoin's Lotus implementation. BLS signatures can be represented in two different forms: serialized and compressed, both of which can be successfully verified using the VerifyCompressed method of the BLST library. However, the block verification logic in Lotus uses the CID of the block header containing the signature to identify block uniqueness, leading to the following security issue: the same block, if signed in two different forms of BLS signatures, will be considered two different blocks because their CIDs differ. An attacker can exploit this vulnerability by submitting blocks containing the same content but different signature formats, bypassing duplicate block detection, potentially leading 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 signatures.

2. Zero-Value Related Vulnerabilities and "Zero-Value Splitting" Attacks in BLS Libraries

Severity: High

Description: Researchers have discovered a series of severe 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 "splitting zero" attacks. These vulnerabilities stem from flaws in handling the special value "0" in cryptographic algorithms, potentially leading to signature verification bypass, private key recovery, denial of service, and other serious security issues. Notably, the GitHub report also mentioned additional zero-value-related vulnerabilities, including: in the supranational/blst library, zero-length signatures or zero-length messages cause program crashes; in modular p operations, the handling error of inverse(0) mod p = 0, but inverse(p) mod p = 1. BLS signature schemes are widely used in blockchain and distributed systems due to their unique aggregation properties, and these vulnerabilities could have significant security implications for large systems relying on these libraries.

Vulnerability Example: According to research documents, "zero-value splitting" attacks mainly include zero signature verification bypass, zero public key attacks, library crash vulnerabilities, zero-value issues in modular operations, 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. Rogue Key Attack Vulnerability in BLS Multisignatures

Severity: High

Description: In the BLS signature scheme, the aggregated public key and signature are achieved through simple summation. An attacker can create a "rogue key" by setting the secret key to 0 and calculating the additive inverse of the honest key to offset the contributions of honest participants.

Recommendation: Implement strict verification of the Proof-of-Possession (PoP) mechanism to avoid relying on simple summation aggregation; consider using nonlinear aggregation or additional randomness.

1. RSA Key Length Too Small

Severity: Medium

Description: The key length of RSA (usually expressed in bits, such as 1024 bits, 2048 bits) determines the size of n, thereby affecting the computational complexity of factorization. If the key length is too short (such as 512 bits or lower), attackers can relatively easily factor n using modern computational resources (such as high-performance computers or distributed computing networks), thereby deducing the private key.

Recommendation: NIST recommends using at least 2048-bit RSA keys; for high-security requirements, 3072-bit or 4096-bit keys may 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 large integer factorization problem, where the modulus n is the product of two large primes p and q. When p and q are chosen too close together, it creates a severe security vulnerability, making the factorization of n significantly easier, potentially leading to the recovery of the RSA private key by malicious attackers. This vulnerability arises from Fermat's factorization method and its variants, which can efficiently factor composite numbers with close factors. When p and q are very close, their average √(pq) is very close to (p+q)/2, allowing effective factorization by trying values near (p+q)/2.

Vulnerability Example: Specifically, if |p-q| is small, we can define integer values s = (p+q)/2 and d = (p-q)/2, then p = s+d, q = s-d, and n = pq = s²-d². This transforms into finding 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) requiring |p-q| > 2^(nlen/2-100), where nlen is the bit length of modulus n; for 2048-bit RSA keys, the difference between p and q should be at least 2^924 bits; consider stricter standards such as |p-q| > 2^(nlen/2) and |p-(n/p)| > 2^(nlen/2).

3. RSA Modulus Reuse Vulnerability

Severity: Critical

Description: The security of RSA encryption is based on the difficulty of the large integer factorization problem, where the modulus n is the product of two large primes p and q. In normal RSA implementations, each key corresponds to a unique modulus n and a corresponding unique public exponent e and private exponent d. When the modulus n is reused, even with different public exponent e and private exponent d, as long as 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 created; sharing the modulus across 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 large integer factorization, where the public key consists of the modulus n (the product of two large primes p and q) and the exponent e, while the private key mainly consists of the exponent d, satisfying e·d ≡ 1 (mod φ(n)). When an extremely small value of e is chosen, particularly e=3, although the encryption operation simplifies to calculating c = m³ mod n, it introduces mathematical weaknesses.

Vulnerability Example: These vulnerabilities mainly manifest in direct square root attacks, Håstad broadcast attacks, Coppersmith related-message attacks, and Bleichenbacher padding attacks. They are particularly dangerous in practical applications, as many developers may choose small exponents to improve performance, especially in resource-constrained environments, and may be unaware of or overlook the associated security risks.

Recommendation: Avoid using e=3, e=5, or other very small values; it is recommended to use e=65537 (2^16+1), which is a larger prime while still maintaining 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 large integer factorization problem, where the public key consists of the modulus n (the product of two large primes p and q) and the public exponent e, while the private key mainly consists of the exponent d, satisfying ed ≡ 1 (mod φ(n)). The private exponent d is used for decryption and signing operations, and its computational complexity is proportional to the size of d. When a very small private exponent d is used, even if the modulus n is very large, the entire encryption system may be compromised. This vulnerability allows an attacker to recover the private key through mathematical methods without performing difficult integer factorization, thereby completely undermining RSA's security guarantees.

Vulnerability Example: To improve decryption and signing efficiency, some implementations may deliberately choose smaller d values, leading to several serious mathematical attacks, such as Wiener attacks, Boneh-Durfee attacks, and partial key exposure attacks.

Recommendation: Use sufficiently large private exponent d. Ensure that d is at least on the same order of magnitude as φ(n), avoiding the deliberate choice of small d values. 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 exponent and n is the modulus. If the original message m is very small relative to the modulus n (m << 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: Implement RSA encryption using PKCS#1 v2.1 OAEP (Optimal Asymmetric Encryption Padding), which adds randomness and expands 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 when decrypting invalidly padded ciphertext (e.g., "invalid padding" vs. "other error"), this creates a "padding oracle." An attacker can repeatedly send modified ciphertexts and observe the responses to narrow down the plaintext range.

Vulnerability Example: An attacker intercepts a valid RSA ciphertext c (which encrypts plaintext m). They generate a variant ciphertext c' = (c * 2^e) mod N and send it to the server. Depending on whether the server reports the padding as valid, the attacker uses the Bleichenbacher algorithm to gradually recover m. This was proven effective in the 1998 Bleichenbacher attack, which affected SSL/TLS implementations, leading to variants like the ROBOT attack in 2014.

Recommendation: Ensure that the RSA decryption and padding verification process does not leak information in terms of timing or returned messages.

8. RSA Timing Attack Vulnerability

Severity: High

Description: RSA timing attacks are a type of side-channel attack where an attacker can gradually deduce private key information by precisely measuring the time differences in RSA operations (such as decryption or signing). This can completely compromise the RSA cryptosystem. Even if the RSA algorithm itself is mathematically secure, its implementation may lead to this serious vulnerability. Such attacks primarily exploit the modular exponentiation (m^d mod n) operations in RSA private key operations, which often use algorithms like "square-and-multiply" or "Montgomery reduction." In these algorithms, 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, while no operation occurs when the bit is 0, leading to measurable time differences.

Vulnerability Example: An attacker can infer each bit of the private key d by sending carefully chosen messages and measuring processing times. With enough measurement samples, the attacker can completely reconstruct the private key, allowing them to decrypt all communications or forge digital signatures.

Recommendation: Ensure that RSA operations complete in constant time, regardless of the private key bit pattern. Use cryptographic libraries that natively support constant-time operations.

9. RSA Exponentiation Attack Vulnerability

Severity: High

Description: RSA encryption has multiplicative homomorphism; if c = m^e mod N, then for any k, c' = (c * k^e) mod N decrypts to m * k mod N. An attacker can exploit this property to manipulate ciphertext without triggering decryption errors.

Vulnerability Example: Suppose an encrypted bank transfer message m = "Transfer 100 yuan," with ciphertext c = m^e mod N. The attacker computes c' = c * (2^e) mod N, which decrypts to "Transfer 200 yuan." This is effective in protocols without signatures, such as early electronic cash systems or custom encryption schemes, and has been exploited in actual attacks, such as modifying encrypted votes or financial data, leading to vulnerabilities in some blockchains or protocols in the 2010s.

Recommendation: Use digital signatures (such as RSA-PSS) or message authentication codes (MAC) to verify message integrity and prevent tampering.

1. Hash Collision Birthday Attack

Severity: High

Description: The hash birthday attack is based on the "birthday paradox" in probability theory, which allows significantly reducing the computational complexity required to find hash collisions. For an n-bit hash function, theoretically, 2^n attempts are needed to find a specific collision, but using the birthday attack, only about 2^(n/2) attempts are needed to achieve a 50% probability of finding two different inputs that produce the same hash value.

Vulnerability Example: Suppose the MD5 hash function (128-bit output) is used; an attacker can generate about 2^{64} variant messages to find a collision. For example, the attacker creates two different contract files A and B (A is legitimate, B is tampered), 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: Use modern hash algorithms with strong collision resistance, such as SHA-256, SHA-3, or BLAKE2, and avoid using MD5 and SHA-1, which have been proven insecure.

2. Hash Function Length Extension Attack

Severity: High

Description: The hash function length extension attack is a cryptographic attack against hash functions that use the Merkle-Damgård structure (such as MD5, SHA-1, and SHA-2 series). An attacker can exploit the internal workings of these hash functions to compute H(message||padding||extension) without knowing the original message, given H(message) and the length of the message, where extension is any data chosen by the attacker. This attack is feasible because the Merkle-Damgård structure hashes inputs in fixed-length blocks, and the hash value of each block depends on the hash state of the previous block. This means that an attacker can continue computing from a known hash state, adding more data blocks without knowing the original data that produced that state. Such vulnerabilities are particularly dangerous in web applications, API authentication, identity systems, and blockchain applications, especially when systems use simple verification patterns like H(secret||message).

Recommendation: Use modern hash algorithms that do not use the Merkle-Damgård structure, such as SHA-3 or BLAKE2, which are inherently immune to length extension attacks.

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 low (for example, below 128 bits, such as 56 bits or lower), the encryption becomes weak, and attackers can quickly decrypt data through brute-force attacks or dictionary attacks. This may lead to sensitive information leakage, data tampering, or system intrusion, especially in modern computing environments where high-performance GPUs and distributed computing can accelerate the cracking process.

Vulnerability Example: According to NIST (National Institute of Standards and Technology) guidelines, key lengths below 128 bits are considered insecure and unable to withstand contemporary threats.

Recommendation: Always use at least a 128-bit AES key, with a preference for 256 bits to provide higher security. Avoid custom or below-standard lengths.

2. IV/Nonce Reuse Attack in AES

Severity: High

Description: IV/Nonce reuse attacks are a serious security threat to AES encryption modes. When the initialization vector (IV) or nonce is reused under the same key, it leads 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 the ciphertexts, and subsequently recover the original plaintext using frequency analysis and other methods. In GCM mode, nonce reuse not only leaks plaintext information but also completely undermines 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 merely by observing ciphertext patterns, and in some cases, they may even fully recover the key.

Vulnerability Example: The most typical case is the Android encryption vulnerability discovered in 2016, where the file system encryption used AES-CBC mode but had flaws in IV generation, leading to the same file content potentially producing the same IV when encrypted at different times, thereby leaking file pattern information. Another well-known example is the key reinstallation attack (KRACK) in some WPA2 implementations, where attackers forced the reuse of Nonce by replaying handshake messages, resulting in the compromise of AES-CCMP encrypted streams. In web applications, some developers incorrectly used 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 due to design flaws in deduplication mechanisms, the same file might use the same encryption parameters, leading to data leakage.

Recommendation: Ensure that each encryption operation uses a unique and unpredictable IV/Nonce.

3. AES-ECB Mode Weak Encryption Risk

Severity: High

Description: Electronic Codebook mode (ECB) is an operation mode of AES encryption that 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 previously encrypted. This deterministic encryption mode allows the encrypted data to retain the pattern and structural characteristics of the original data, failing to provide the semantic security required by modern cryptography. In ECB mode, the ciphertext may leak information about the plaintext's patterns, enabling 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.

Vulnerability Example: When encrypting images using ECB mode, the contours and main features of the image remain visible after encryption. A classic example is the ECB penguin image, where the outline of the penguin is still clearly discernible even after "encryption."

Recommendation: Avoid using ECB mode entirely unless encrypting a single block of data that is smaller than the block size (16 bytes).

4. AES-CBC Ciphertext Padding Attack

Severity: High

Description: The AES-CBC ciphertext padding attack (Padding Oracle Attack) is a side-channel attack against symmetric encryption systems using CBC mode. This attack exploits information leaked by the decryption system when validating padding, 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 response time differences), attackers can systematically modify the ciphertext and observe the system's responses to gradually deduce the original plaintext content. The attack principle is based on the decryption characteristics of the CBC mode, where the previous ciphertext block is XORed with the currently decrypted block. By carefully constructing and modifying ciphertext blocks, attackers can use the padding verification mechanism as an "Oracle" to infer decrypted intermediate values, ultimately recovering the complete plaintext data. Additionally, through CBC-R (CBC Reverse) techniques, attackers can even forge ciphertext that can be correctly decrypted by the system.

Vulnerability Example: Historically, several TLS implementations have been affected by such attacks, such as the POODLE (2014) and "Lucky Thirteen" (2013) attacks. Attackers can intercept encrypted communications, modify the ciphertext, and analyze server responses to ultimately crack the encrypted content.

Recommendation: Use AEAD (Authenticated Encryption with Associated Data) cipher modes, such as AES-GCM or ChaCha20-Poly1305.

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 by replacing the random challenges from the prover and verifier with the output of a hash function. The Frozen Heart vulnerability refers to the use of a "weak Fiat-Shamir" transformation in the implementation, where only part of the prover's message is hashed without hashing public information (such as parameters, public inputs, etc.). This allows attackers to forge proofs and deceive verifiers without knowing the secret value by precomputing the public key A. 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 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 multiparty computation (MPC) protocols, GG18 and GG20, affecting over 10 wallets and libraries (including Binance Custody Services). The root of the vulnerability lies in the protocol implementation not checking whether the attacker's Paillier modulus N contains small factors or is a biprime. Attackers can exploit this vulnerability to interact with the signing parties in the MPC protocol, stealing their secret shares and ultimately obtaining the main secret key, thereby completely extracting the private key and stealing all funds in the encrypted wallet.

Recommendation: Ensure that the Paillier public key of the signing party is checked for small prime factors to prevent attackers from using malicious moduli containing small factors (such as primes of size 2^20).

The Slow Mist Security Team has open-sourced a report on common cryptographic risks in blockchain applications, aimed at systematically revealing high-risk security vulnerabilities hidden in core aspects such as private key generation, digital signatures, hash functions, and symmetric encryption. Web3 project teams can refer to this article for an analysis of various vulnerabilities, exploitation scenarios, and remediation recommendations, deepening their understanding of cryptographic security and avoiding common implementation pitfalls, thereby more effectively safeguarding the security of projects and users' assets.

Related Reading: Market Resilience Under Flash Crash Testing: How the ADL Mechanism Protects Fund Security

Original text: “Slow Mist Production | Common Cryptographic Risks in Blockchain Applications”

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。