SlowMist: Common Cryptographic Risks in Blockchain Applications

0x01 Private Key Random Number Security

1. Generate random numbers using JavaScript's Math.random or a time-based seed.

• Severity: High

• Description: JavaScript's `Math.random()` is a pseudo-random number generator (PRNG), which is unsuitable for cryptographically secure scenarios. Its implementation depends on the browser or JavaScript engine (such as V8's Xorshift128+), and the seed and algorithm are often uncontrollable and unpredictable, potentially leading to the generated random number sequences being guessed or reproduced by attackers.

• Use cases: This could lead to key breaches, session hijacking, or game cheating when generating encryption keys, session tokens, CSRF tokens, or random game events.

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

2. Generate the private key using Java's insecure random number generation method.

• 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 lack 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.

• Use cases: In Java-based web applications, keys generated using Random may be exploited by attackers to crack TLS sessions or forge JWT tokens.

• Recommendation: Use java.security.SecureRandom instead. It's 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 or KeyFactory) to generate keys.

1. In some versions of Android, SecureRandom fails to initialize correctly.

• Severity: High

• Description: In some Android versions (especially earlier versions, such as 4.1-4.3), java.security.SecureRandom fails to initialize correctly, resulting in insufficient entropy for the generated random numbers. This is usually due to an insufficiently filled system entropy pool (such as /dev/urandom) or a flaw in the implementation of SecureRandom, which makes the generated random number sequence highly predictable, significantly reducing security when used for private key generation.

• Use case: On affected Android devices, Bitcoin private keys generated using SecureRandom may be compromised, 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.

1. The space for storing random numbers during private key generation is too small.

• Severity: High

• Description: If a variable type with too little space (such as a 32-bit integer) is used to store random numbers during the private key generation process, it will limit the range and entropy of the random numbers, resulting in insufficient strength of the generated private key.

• Use Cases: Attackers can exploit the limited range of random numbers to quickly guess private keys through brute-force attacks or pre-computation attacks (such as rainbow tables). For example, in the case of the Profanity tool, attackers successfully cracked multiple Ethereum wallets and stole large sums of money by analyzing the generated address patterns.

• Recommendation: Use a sufficiently large variable type (e.g., 256 bits or more) to store random numbers to support the full key space (e.g., the 2^256 range of the secp256k1 curve).

1. Libbitcoin Mersenne Twister Weak Entropy Vulnerability

• Severity: High

• 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 a wallet seed, which is initialized only with a 32-bit system time (high_resolution_clock). This results in the entropy space being limited to 2^32 (approximately 4.3 billion) possible values, far below the secure 128-bit or 256-bit entropy requirement. Attackers can reproduce the seed through brute-force attacks, thereby deducing the private key and jeopardizing user funds. This vulnerability is known as "Milk Sad" because the first seed phrase generated begins with "milk sad".

• Use cases : `get_clock_seed()` returns a 32-bit system timestamp (uint32_t), which can be used as a seed for the Mersenne Twister. While `std::mt19937` generates seemingly random output, its entropy is limited by the 32-bit seed, making it unable to provide a 128-bit or higher level of security. When filling the output with `pseudo_random_fill`, expanding it to 256 bits is merely a pseudo-random expansion 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 with a high-entropy source, or OpenSSL's RAND_bytes).

6. Security Risks of OpenSSL Random Number Generators

• Severity: High

• Description: The OpenSSL cryptographic library's random number generator RAND_pseudo_bytes() is used to put `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 its length 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.

• Example of a vulnerability: 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 RAND_pseudo_bytes, replace it entirely with RAND_bytes and check 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 cryptography algorithm, but there are concerns about potential backdoors in its parameter generation. During the standardization process, the parameters were provided by the NSA, lacking transparency in the generation process. This could be intentionally designed to contain weaknesses, allowing specific attackers (such as the NSA) to exploit hidden mathematical relationships to decrypt data or forge signatures.

• Use cases: Attackers may exploit backdoors (if they exist) to quickly calculate private keys or predict the output of random number generators by taking advantage of the mathematical properties of known parameters, thereby cracking encrypted communications, forging digital signatures, or stealing sensitive data in secp256r1-based encryption systems (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. The weak randomness of the 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 the signature. If the value of k is generated by a weak random number generator (e.g., a low-entropy source, an insecure PRNG, or a predictable seed), an attacker could infer the value of k by analyzing the signature data and then directly calculate the private key using the mathematical properties of ECDSA. This vulnerability typically stems from the use of insecure random number generators (such as rand(), Math.random()) or insufficient environmental entropy (such as virtual machines or embedded devices).

• Use Cases: Attackers can reconstruct the value of k and deduce the private key by collecting a small amount of signature data (e.g., r and s values) and combining it with the predictability of weak random numbers. In blockchain scenarios (such as Bitcoin and Ethereum), this could lead to the exposure of wallet private keys and the theft of funds. For example, if the k value is generated based on a timestamp or a fixed seed, attackers can quickly recover the private key through brute-force attacks or pattern analysis. Similar problems have occurred in early crypto wallet implementations, which were compromised due to the use of weak random sources to generate the k value.

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

3. Reusing the 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 such as Bitcoin), if two signatures use the same random number k (nonce), the value of r in the signatures will be identical. An attacker can deduce the private key by analyzing these two signature sets (r, s1) and (r, s2) and their corresponding message hashes h1 and h2. This vulnerability stems from the mathematical structure of the ECDSA signature equations; the reuse of k allows attackers to construct a system of equations and directly solve for the private key d.

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

4. The malleability of ECDSA signature values

• Severity: Medium

• Description: ECDSA (Elliptic Curve Digital Signature Algorithm) signature values ​​(r, s) exhibit malleability, 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 modular symmetry of ECDSA signature verification. If an unnormalized signature is implemented (e.g., forcing the use of a "low s value"), an attacker could modify the signature without affecting its validity, potentially bypassing signature verification mechanisms or violating the uniqueness requirements of certain protocols.

• Use Cases: Attackers can exploit signature malleability to create problems in blockchains (such as Bitcoin and Ethereum) or protocols. For example, in Bitcoin transactions, an attacker can modify the `s` value of the transaction signature to generate a new signature, changing the transaction ID (txid), causing the transaction to be rejected or triggering double-spending risks. Furthermore, in some smart contracts or multi-signature protocols, unnormalized signatures can be used to bypass verification logic, resulting in financial losses or protocol failure. In 2013, the Bitcoin network experienced a transaction malleability attack due to signature malleability, affecting exchanges such as Mt. Gox.

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

5. ECDSA and Schnorr signatures share the same random number k, leading to private key leakage.

• Severity: High

• Description: In Elliptic Curve Digital Signature Algorithm (ECDSA) and Schnorr signatures, if the same random number k (nonce) is used when generating signatures, an attacker can deduce the private key by analyzing the signature. This vulnerability stems from the similarity in the mathematical structure of the two signature schemes, allowing the private key to be deduced from the known signature equation. Whether signing multiple times within the same system or reusing k across different signature algorithms, the private key will be completely exposed, enabling an attacker to forge signatures or control related accounts.

• Recommendation: RFC6979 allows the input parameter to include "addition data". When generating k, the signature algorithm information can be filled into this field, thus enabling secure reuse of k at the algorithm level.

6. ECDSA can forge signature values ​​when it does not require the message m corresponding to the signature value.

• Severity: Low

• Description: When verifying ECDSA signatures, if the verification process only requires the hash value of the message instead of the original message itself, an attacker can construct a forged signature that passes verification based on a known legitimate signature, without knowing the private key. This vulnerability exploits the mathematical properties of the ECDSA verification mechanism, allowing attackers to choose specific combinations of values ​​to create forged signatures without knowing the corresponding original message or private key.

• Recommendation: When verifying signatures, the original message m must be required, not just the hash value.

7. Nonce side-channel attack vulnerability in ECDSA signatures

• Severity: High

• Description: LadderLeak is a side-channel vulnerability in ECDSA implementations. Attackers can obtain the most significant bit of the nonce used in the signing process through cached timing analysis, but the probability of leakage is less than 100% (i.e., "less than 1 bit" of information). This vulnerability exists in OpenSSL branches 1.0.2 and 1.1.0, as well as RELIC toolkit version 0.4.0, specifically affecting ECDSA implementations based on the curves section163r1 and NIST P-192. The vulnerability stems from a small time difference caused by improper coordinate handling in the Montgomery trapezoidal algorithm implementation. Attackers can observe this time difference and use statistical methods to infer the most significant bit of the nonce k. Even though this leakage rate is less than 100% (e.g., 99% for P-192 and 97.3% for section163r1), attackers can still fully recover the private key by collecting a sufficient number of signatures using an improved Bleichenbacher Fourier analysis method.

• Vulnerability examples: Vulnerabilities in OpenSSL implementations manifest in both binary curve cases (e.g., sect163r1) and prime number curve cases (e.g., NIST P-192). 

  
  

  1. Scalability Vulnerability in Filecoin BLS Signature Verification

  
  

  • Severity: High

  
  

  • Description: A scalability vulnerability has been discovered in the BLS signature verification mechanism of Filecoin's Lotus implementation. BLS signatures can be represented in two different forms : serialized and compressed. Both forms can be successfully verified using the `VerifyCompressed` method of the BLST library. However, Lotus's block verification logic uses the block header CID, which includes the signature, to identify block uniqueness. This leads to the following security issue: the same block using two different forms of BLS signatures will be considered two different blocks because their CIDs are different. Attackers can exploit this vulnerability by submitting blocks containing the same content but with different signature formats, bypassing duplicate block detection, potentially leading to blockchain forks, double spend attack, or consensus failures.

  
  

  • Recommendation: Before verifying signatures, convert all signatures to a uniform format (either use serialization or compression).

  
  

  2. Zero-value related vulnerabilities and "zero-value splitting" attacks in the BLS library

  
  

  • Severity: High

  
  

  • Description: Researchers have discovered a series of critical 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 the handling of the special value "0" in cryptographic algorithms, potentially leading to signature verification bypass, private key recovery, denial-of-service attacks, and other serious security issues. Of particular note, the GitHub report also mentions additional zero-value-related vulnerabilities, including: in the supranational/blst library, zero-length signatures or zero-length messages cause program crashes; and in modulo p operations, the handling of inverse(0) mod p = 0, but inverse(p) mod p = 1 is incorrect. BLS signature schemes are widely used in blockchains and distributed systems due to their unique aggregation properties, and these vulnerabilities could have significant security implications for large systems that rely on these libraries.

  
  

  • Vulnerability Examples: 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 modulo operations, and zero-value manipulation in aggregate signatures.
    

  • Recommendation: Clearly define and consistently implement strategies for handling zero values ​​(zero-length inputs, zero points, zero scalars, etc.).

  
  

  3. Rogue Key Attack Vulnerability in BLS Multisignature

  
  

  • Severity: High

  
  

  • Description: In the BLS signature scheme, the aggregation of the public key and the signature is achieved simply by summing. An attacker can create a "rogue key" by setting the secret key to 0 and calculating the additive inverse of the honest key to negate the contributions of honest participants.

  
  

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

     

  0x06 RSA Security

   

  
  

  1. Hash Collision Birthday Attack

  
  

  • Severity: High

  
  

  • Description: Hash birthday attacks are based on the "birthday paradox" in probability theory. This principle can be used to significantly reduce 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 a birthday attack, only about 2^(n/2) attempts are needed to find that any two inputs produce the same hash value with a 50% probability.

  
  

  • Vulnerability Example: Assuming the MD5 hash function (128-bit output) is used, an attacker can find a collision by generating approximately 2^64 variant messages. For example, an attacker creates two different contract files A and B (A is valid, B is tampered with) such that MD5(A) = MD5(B). If the system uses MD5 to verify signatures, an attacker can use the signature of A to forge B, leading to situations such as the MD5 collision used to generate fake certificates in the 2004 Flaming attack, or the 2012 Flame malware exploiting 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 algorithms such as MD5 and SHA-1, which have been proven to be insecure.

  
  

  2. Hash function length extension attack

  
  

  • Severity: High

  
  

  • Description: A length extension attack is a cryptographic attack targeting hash functions using the Merkle-Damgård structure (such as the MD5, SHA-1, and SHA-2 series). Attackers exploit the internal workings of these hash functions to calculate the value of H(message||padding||extension) knowing only H(message) and its length, without needing to know the message itself, where extension is arbitrary data chosen by the attacker. This attack is feasible because Merkle-Damgård hash algorithms divide the input into 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 calculating from a known hash state, adding more blocks without knowing the original data that generated that state. This type of vulnerability is particularly dangerous in web applications, API verification, identity authentication systems, and blockchain applications, especially when the system uses simple verification patterns like H(secret||message).

  
  

  • Recommendation: Use modern hash algorithms that do not have a Merkle-Damgård structure, such as SHA-3 and BLAKE2, as these algorithms are naturally immune to length extension attacks.

     

  0x08 AES Security

   

  
  

  1. Weak Fiat-Shamir Transform

  
  

  • Severity: High

  
  

  • Description: The Fiat-Shamir transformation is an important method for converting interactive zero-knowledge proof protocols into non-interactive proof protocols. It replaces the random challenges in 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 of the Fiat-Shamir transformation. This means that only a portion of the prover's message is hashed, without hashing public information (such as parameters, public inputs, etc.). This allows an attacker to forge a proof and deceive the verifier using a pre-computed 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 common input data are included in the random number generation process in the Fiat-Shamir transformation implementation.

  
  

  2. Paillier Key Vulnerabilities in GG18 and GG20

  
  

  • Severity: High

  
  

  • Vulnerability Description: This vulnerability exists in the specifications of two widely used Multi-Party Computation (MPC) protocols, GG18 and GG20, affecting more than 10 wallets and libraries (including Binance Custody Service). The root of the vulnerability lies in the protocol implementation's failure to check whether the attacker's Paillier modulus N contains small factors or is a double prime number. An attacker could exploit this vulnerability to interact with the signer in the MPC protocol, steal their secret shards, and ultimately obtain the master secret key, thereby gaining complete control of the private key and stealing all funds from the encrypted wallet.

  
  

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

     

  Summarize

  SlowMist Security Team has open-sourced "Common Cryptographic Risks in Blockchain Applications," aiming to systematically reveal high-risk security risks hidden in core aspects such as private key generation, digital signatures, hash functions, and symmetric encryption. Web3 projects can refer to this article for its analysis of the principles, exploitation scenarios, and remediation suggestions for various vulnerabilities, deepening their understanding of cryptographic security, avoiding common implementation pitfalls, and thus more effectively protecting the assets of their projects and users.