KO | EN

GitLite

Minimalist Open Source Repository Search Engine

gitlite — search

#dsh #dsh-plugin #developer-tools #ai-agent #claude-code #codex #typescript #ai-agents #deepseek-harness #mcp #cli #rust

Common-Cryptographic-Risks-in-Blockchain-Applications

★ 33 Open GitHub ↗

This document demonstrates the cryptographic algorithms used in blockchain applications and their risks.

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# Common-Cryptographic-Risks-in-Blockchain-Applications

[![Twitter URL](https://img.shields.io/twitter/url/https/twitter.com/slowmist_team.svg?style=social&label=Follow%20%40SlowMist_Team)](https://twitter.com/slowmist_team)

[[中文]](./README_CN.md)

- [Common-Cryptographic-Risks-in-Blockchain-Applications](#common-cryptographic-risks-in-blockchain-applications)
  - [1. Private Key Random Number Security](#1-private-key-random-number-security)
    - [Using JavaScript Math.random or seed-based random number generation based on time](#using-javascript-mathrandom-or-seed-based-random-number-generation-based-on-time)
    - [Using Java's Unsafe Random Number Generation Method to Generate Private Keys](#using-javas-unsafe-random-number-generation-method-to-generate-private-keys)
    - [Android System Fails to Properly Initialize SecureRandom in Certain Versions](#android-system-fails-to-properly-initialize-securerandom-in-certain-versions)
    - [The variable type space for storing random numbers during private key generation is too small](#the-variable-type-space-for-storing-random-numbers-during-private-key-generation-is-too-small)
    - [Libbitcoin Mersenne Twister Weak Entropy Vulnerability](#libbitcoin-mersenne-twister-weak-entropy-vulnerability)
    - [OpenSSL Random Number Generator Security Risk](#openssl-random-number-generator-security-risk)
  - [2. ECDSA Security](#2-ecdsa-security)
    - [secp256r1 Backdoor Issue](#secp256r1-backdoor-issue)
    - [Weak Randomness of k Value in secp256k1 Leading to Private Key Leakage](#weak-randomness-of-k-value-in-secp256k1-leading-to-private-key-leakage)
    - [Reuse of k Value in secp256k1 Leads to Private Key Leakage](#reuse-of-k-value-in-secp256k1-leads-to-private-key-leakage)
    - [Forgeability of ECDSA Signature Values](#forgeability-of-ecdsa-signature-values)
    - [ECDSA and Schnorr Signatures Sharing Random Number k Leads to Private Key Leakage](#ecdsa-and-schnorr-signatures-sharing-random-number-k-leads-to-private-key-leakage)
    - [ECDSA can forge a signature value without providing the message m corresponding to the signature value](#ecdsa-can-forge-a-signature-value-without-providing-the-message-m-corresponding-to-the-signature-value)
    - [ECDSA Signature Nonce Side-Channel Attack Vulnerability](#ecdsa-signature-nonce-side-channel-attack-vulnerability)
    - [Twist Attack Vulnerability in Elliptic Curve Cryptography](#twist-attack-vulnerability-in-elliptic-curve-cryptography)
  - [3. EdDSA Security](#3-eddsa-security)
    - [Private Key Extraction Vulnerability in the Ed25519 Signature Algorithm](#private-key-extraction-vulnerability-in-the-ed25519-signature-algorithm)
    - [Side-Channel Vulnerability in Ed25519 Signature Algorithm in WolfSSL](#side-channel-vulnerability-in-ed25519-signature-algorithm-in-wolfssl)
    - [Ed25519 Curve Cofactor Not Being 1 Leading to Double-Spending Vulnerability](#ed25519-curve-cofactor-not-being-1-leading-to-double-spending-vulnerability)
    - [Ed25519 Extensibility Vulnerability in Historical Versions](#ed25519-extensibility-vulnerability-in-historical-versions)
  - [4. Schnorr Security](#4-schnorr-security)
    - [Schnorr Nonce Reuse or Poor Random Number Generation](#schnorr-nonce-reuse-or-poor-random-number-generation)
    - [Schnorr Related Key Attack](#schnorr-related-key-attack)
    - [Schnorr Side-Channel Attack](#schnorr-side-channel-attack)
  - [5. BLS Security](#5-bls-security)
    - [Extensibility Vulnerability in Filecoin BLS Signature Verification](#extensibility-vulnerability-in-filecoin-bls-signature-verification)
    - [Zero-Value-Related Vulnerabilities in BLS Libraries and the "Splitting Zero" Attack](#zero-value-related-vulnerabilities-in-bls-libraries-and-the-splitting-zero-attack)
    - [BLS Rogue Key Attack Vulnerability in Multi-Signature](#bls-rogue-key-attack-vulnerability-in-multi-signature)
  - [6. RSA Security](#6-rsa-security)
    - [RSA Key Length Too Short](#rsa-key-length-too-short)
    - [Approximate Prime Vulnerability in RSA Key Generation](#approximate-prime-vulnerability-in-rsa-key-generation)
    - [RSA Modulus Reuse Vulnerability](#rsa-modulus-reuse-vulnerability)
    - [RSA Small Public Exponent Vulnerability](#rsa-small-public-exponent-vulnerability)
    - [RSA Small Private Exponent Vulnerability](#rsa-small-private-exponent-vulnerability)
    - [RSA No Padding Short Message Attack Vulnerability](#rsa-no-padding-short-message-attack-vulnerability)
    - [RSA Padding Oracle Attack Vulnerability](#rsa-padding-oracle-attack-vulnerability)
    - [RSA Timing Attack Vulnerability](#rsa-timing-attack-vulnerability)
    - [RSA Malleability Attack Vulnerability](#rsa-malleability-attack-vulnerability)
  - [7. Hash Security](#7-hash-security)
    - [Hash Collision Birthday Attack](#hash-collision-birthday-attack)
    - [Length Extension Attack on Hash Functions](#length-extension-attack-on-hash-functions)
  - [8. AES Security](#8-aes-security)
    - [AES Encryption Key Length Insufficient](#aes-encryption-key-length-insufficient)
    - [IV/Nonce Reuse Attack in AES](#ivnonce-reuse-attack-in-aes)
    - [AES-ECB Mode Weak Encryption Risk](#aes-ecb-mode-weak-encryption-risk)
    - [AES-CBC Padding Attack](#aes-cbc-padding-attack)
  - [9. Other Cryptographic Protocols](#9-other-cryptographic-protocols)
    - [Weak Fiat-Shamir Transformation](#weak-fiat-shamir-transformation)
    - [GG18 and GG20 Paillier Key Vulnerability](#gg18-and-gg20-paillier-key-vulnerability)

## 1. Private Key Random Number Security

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

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

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

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

```cpp
    cl_ulong4 Dispatcher::Device::createSeed() {
        #ifdef PROFANITY_DEBUG
            cl_ulong4 r;
            r.s[0] = 1;
            r.s[1] = 1;
            r.s[2] = 1;
            r.s[3] = 1;
            return r;
        #else
            // Randomize private keys
            std::random_device rd;
            std::mt19937_64 eng(rd()); //@audit rd() The returned value is a 32-bit length random value.
            std::uniform_int_distribution<cl_ulong> distr;
            cl_ulong4 r;
            r.s[0] = distr(eng);
            r.s[1] = distr(eng);
            r.s[2] = distr(eng);
            r.s[3] = distr(eng);
            return r;
        #endif
    }
    ```

- **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^256 range of the secp256k1 curve).

### 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 wallet seeds, which are initialized solely by a 32-bit system time (high_resolution_clock). This limits the entropy space to 2^32 (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.

```cpp
    void pseudo_random_fill(data_chunk& out)
    {
        return pseudo_random::fill<data_chunk>(out);
    }

static uint32_t get_clock_seed()
    {
        const auto now = high_resolution_clock::now();
        return static_cast<uint32_t>(now.time_since_epoch().count());
    }

std::mt19937& pseudo_random::get_twister()
    {
        // Boost.thread will clean up the thread statics using this function.
        const auto deleter = [](std::mt19937* twister)
        {
            delete twister;
        };

// Maintain thread static state space.
        static boost::thread_specific_ptr<std::mt19937> twister(deleter);

// This is thread safe because the instance is thread static.
        if (twister.get() == nullptr)
        {
            // Seed with high resolution clock.
            twister.reset(new std::mt19937(get_clock_seed()));
        } //@audit Used system time, and only 32-bit space instead of 256-bit.

return *twister;
    }
    ```
- **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).

### 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):

```c
    // Application temporarily stores user PIN code
    char pin[4] = "1234";
    // Securely clear the PIN code (seemingly reasonable approach)
    RAND_pseudo_bytes((unsigned char*)pin, sizeof(pin));
    // Generate some random numbers as nonce
    unsigned char nonce[16];
    RAND_pseudo_bytes(nonce, sizeof(nonce));
    // Problem: The nonce may leak information about the erased PIN code
    ```

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.
## 2. ECDSA Security

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

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

- **Exploitation Scenario**

Assume a user signs two messages m1 and m2 with the same private key d and the same k, generating signatures (r, s1) and (r, s2), where:

```cpp
    s1 = k⁻¹(h1 + dr) mod n (h1 is the hash of m1)
    s2 = k⁻¹(h2 + dr) mod n (h2 is the hash of m2)
    //The r value is the same because it is calculated from k and the curve point, independent of the message. After obtaining these two sets of signatures, the attacker calculates:
    // 1. s1 - s2 = k⁻¹(h1 + dr - h2 - dr) = k⁻¹(h1 - h2) mod n
    2. k = (h1 - h2) / (s1 - s2) mod n
    3. Then solve for d from s1 = k⁻¹(h1 + dr) mod n: d = (s1k - h1) / r mod n
    ```

- **Recommendation**

Follow the RFC 6979 standard to generate deterministic but unpredictable k values based on the private key and message hash to prevent reuse.
### 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 Scenarios**

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.

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

- **Exploitation Scenario**

Assume a user generates an ECDSA signature (r, s) and a Schnorr signature (r, s') using the same private key d and random number k.
    The ECDSA signature satisfies: `s = k⁻¹(h + dr) mod n`, where h is the message hash, r is the x-coordinate of the elliptic curve point, and n is the order of the curve.
    The Schnorr signature satisfies: `s' = k + dh mod n`, where h is the message hash.
    After obtaining both sets of signatures, the attacker can eliminate k by solving the equations simultaneously to calculate the private key d: from the Schnorr signature, k = s' - dh mod n, substituting this into the ECDSA signature equation can derive:
    `d=(ss’-h) / (sh+r) mod n`
    In actual cases, some cryptocurrency wallets or smart contracts may have such vulnerabilities due to incorrect implementations (such as reusing k or improper deterministic k generation).

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

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

- **Exploitation Scenario**

Assuming there is a valid signature σ=(r,s) corresponding to message m and hash value e=H(m), the attacker can:
    1. Choose random numbers u,v∈F*n
    2. Calculate R'=(x', y')=uG+vP, where G is the base point and P is the public key
    3. Let r'≡x' mod n
    4. Calculate s'≡r'v^-1 mod n
    5. Calculate e'≡r'uv^-1 mod n
    At this point, the signature (r',s') with the hash value e' can pass verification, but the attacker cannot find the original message m' that satisfies H(m')=e'. Therefore, in a verification system that does not require the original message, this forged signature will be accepted as legitimate.
    This vulnerability has been used to forge identity proofs. Craig Wright once used this principle to forge Satoshi Nakamoto's signature in an attempt to prove that he was the founder of Bitcoin.

- **Recommendation**

When verifying a signature, the original message m must be provided, not just the hash value.

### ECDSA Signature Nonce Side-Channel Attack Vulnerability

- **Severity**

High

- **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**

For the OpenSSL implementation, the vulnerability manifests in two scenarios:

1. **Binary Curve Case** (e.g., sect163r1):

In the function `ec_GF2m_montgomery_point_multiply()`, during the first iteration of the Montgomery ladder algorithm, the `gf2m_Madd()` function is called for point addition. When the second MSB is 1, Z1 equals x² instead of 1, resulting in a time difference in the modular reduction operation. This difference can be observed through a cache timing attack, with a correct detection rate of 99%.

2. **Prime Curve Case** (e.g., NIST P-192):

In the function `ec_mul_consttime()`, based on the value of the second MSB, the algorithm processes points in different coordinate forms during point doubling operations. When the second MSB is 0, the input point is in affine coordinates, causing the `BN_copy()` function to be called instead of the regular field multiplication, resulting in a time difference. This difference can be observed through a cache timing attack, with a correct detection rate of 99.53%.

Researchers have used this leakage to fully recover the private key for P-192 with only about 2³⁵ signatures; for sect163r1, only about 2²⁴ 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:

```c
    // Randomize the Z coordinate during the initialization of the ladder algorithm
    void ec_point_set_from_affine(EC_POINT *out, const EC_AFFINE_POINT *in, BN_CTX *ctx) {
        BN_rand(out->Z, BN_num_bits(group->field), -1, 0); // Randomize the Z coordinate
        BN_mod_mul(out->X, in->x, out->Z, group->field, ctx);
        BN_mod_mul(out->Y, in->y, out->Z, ctx);
    }
    ```
        
### 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.

- **Exploitation Scenario**

Twist attacks combine two types of cryptographic attack methods:

1. **Small-subgroup attacks**: The attacker sends a point of small order (rather than a legitimate curve point) as the public key, inducing the victim to use their private key to compute with it. The attacker then exhaustively searches a limited number of possibilities to extract partial information about the private key.

2. **Invalid-curve attacks**: The attacker sends points that lie on a different curve, exploiting the flaw in standard ECC algorithm implementations that do not verify whether the point is on the correct curve, to obtain additional information about the private key.

The reason these attacks are particularly dangerous is that even when using single-coordinate ladder algorithms to limit the scope of invalid-curve attacks, attackers can still find points of small order on both the original curve and its twist. By using the Chinese Remainder Theorem (CRT), attackers can combine private key information for different moduli and ultimately recover the complete private key.

In many practical implementations, developers may omit point validation due to considerations of simplifying code or improving performance, making the system susceptible to such attacks. This risk is especially significant when the private key is only chosen to be ℓ (the order of the base point) rather than hℓ (the order of the curve), and no cofactor multiplication for the original curve or twist is performed.

- **Recommendation**

Verify that the received point is indeed on the expected curve.

- **References**

[https://safecurves.cr.yp.to/twist.html](https://safecurves.cr.yp.to/twist.html)

[https://mp.weixin.qq.com/s/Ivraz1ejoe9UiYYbeQSRoA](https://mp.weixin.qq.com/s/Ivraz1ejoe9UiYYbeQSRoA)

## 3. EdDSA Security

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

- **Exploitation Scenario**

Consider the following attack scenario:

1. The attacker gains access to the wallet signing interface, which is like `sign(privateKey, message, publicKey)`
    2. The attacker constructs two signing requests for the same message:
    - The first time using the correct private key `k` but replacing it with the attacker-controlled public key `A'`
    - The second time using the same private key `k` and the correct public key `A`
    3. Mathematically, the signing process is as follows:
    - First signature: Calculate `S₁ = r + h(R,A',M) · a`
    - Second signature: Calculate `S₂ = r + h(R,A,M) · a`
    - Where `r` is the deterministically generated random number, which is the same in both signatures
    4. After obtaining the two signatures, the attacker can calculate:
    - `S₁ - S₂ = h(R,A',M) · a - h(R,A,M) · a = (h₁ - h₂) · a`
    - And then solve for `a = (S₁ - S₂) / (h₁ - h₂)`
    5. Once the attacker obtains the value of `a`, they can forge the victim's signature for any message and completely control their account assets

- **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

- **Reference**

[https://mp.weixin.qq.com/s/2zvlE8kMPDtwRyQXNEPegg](https://mp.weixin.qq.com/s/2zvlE8kMPDtwRyQXNEPegg)

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

- **Exploitation Scenario**

The attack is implemented as follows:
    1. The attacker first measures the power consumption curve of the target device while it performs Ed25519 signature operations, collecting about 4,000 signature traces for different messages.
    2. Using differential power analysis, the attacker can extract the intermediate state of the SHA-512 algorithm processing key information:
    ```
    w[16] ← σ1(w[14]) + w[9] + σ0(w[1]) + w[0]
    ```
    where w[14] and w[9] are known parts of the message, while w[1] and w[0] are unknown parts of the auxiliary key.
    3. The attacker recovers the key values k16 = σ0(w[1]) + w[0], k17, k18, and k19 from the power traces, using a divide-and-conquer strategy to attack 8-bit key segments at a time.
    4. By solving the system of equations, the attacker can recover the complete auxiliary key b from these intermediate values.
    5. Once the auxiliary key b is obtained, the attacker can calculate the ephemeral key r = H(b,M) for any message.
    6. For any existing signature (R,S), the attacker can calculate the private scalar a = (S-r)h^(-1) mod l, where h = H(R,A,M).
    7. With the private scalar a, the attacker can forge valid signatures for any message.
    The actual attack was implemented on a 32-bit ARM Cortex-M4F microcontroller running the Ed25519 implementation of WolfSSL 3.10.2. The attack was completely successful, proving the reality of the threat.

- **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:
    ```
    r = H(b || R0 || M) // where R0 is a random value
    ```

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.

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

- **Exploitation Scenario**

On the Bytecoin blockchain, attackers successfully exploited this vulnerability to execute "triple-spending" and "quadruple-spending" attacks:
    1. By selecting low-order points from the G2 subgroup as public keys and key images
    2. Constructing special signature parameters that make the verification equation hold true after point multiplication
    3. Making c (a part of the signature) a multiple of 8, using the properties of the G2 subgroup to make c·P=O and c·I=O
    4. Successfully creating four transactions that spend the same UTXO:
    - cef289d7fab6e35ac123db8a3f06f7675b48067e0dff185c72b140845b8b3b23
    - 7e418cc77935cc349f007cd5409d2b6908e4130321fa6f97ee0fee64b000ff85
    - 5a3db49ef69e1f9dd9b740cabea7328cd3499c29fc4f3295bac3fa5e55384626
    - 74298d301eb4b4da30c06989e0f7ff24a26c90bf4ffc4f2c18f34b7a22cf1136
    This led to the Bytecoin project being airdropped approximately 700 million BCN tokens out of thin air.

- **Recommendation**

Implement subgroup membership checks for all key images to ensure they belong to the large prime-order subgroup G1

```
    // Check if the key image belongs to G1
    if(ℓ·I != O) {
        // Reject the key image
        return false;
    }
    ```

### 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^252 + 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.

- **Reference**

[https://mp.weixin.qq.com/s/m5VWfPT-5gfXiUqBeOF_aQ](https://mp.weixin.qq.com/s/m5VWfPT-5gfXiUqBeOF_aQ)

## 4. Schnorr Security

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

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

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

## 5. BLS Security

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

- **Exploitation Scenario**

Here is an example of the attack scenario:
    1. A miner generates a valid block B, which contains a BLS signature S1 in serialized format.
    2. The attacker can convert this signature to compressed format S2 and create a new block B'.
    3. B and B' have exactly the same content, with only the signature format being different.
    4. Submitting these two blocks to the network, they will be regarded as different blocks due to their different CIDs.
    5. This may lead to:
    - Network forks, with some nodes accepting B and others accepting B'.
    - Consensus failure detection not working properly, as the CID comparison determines that these are two different blocks.
    - Possible bypassing of validation rules for specific transactions or blocks.

- **Recommendation**

Convert all signatures to a unified format (either all serialized or all compressed) before verifying the signatures.

- **Reference**

[https://gist.github.com/wadeAlexC/2490d522e81a796af9efcad1686e6754](https://gist.github.com/wadeAlexC/2490d522e81a796af9efcad1686e6754)

### 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:

1. In the supranational/blst library, zero-length signatures or zero-length messages can cause the program to crash.

2. In modular arithmetic, the error in handling inverse(0) mod p = 0, but 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:

1. **Zero Signature Verification Bypass**:

Attackers create a signature, using a special zero value as part of the signature, exploiting the incorrect handling of zero values in the library to make an invalid signature pass verification. For example, in some implementations, the special handling of zero points in point compression/decompression algorithms can cause the verification function to mistakenly judge a zero-value signature as valid.

2. **Zero Public Key Attack**:

Exploiting the improper handling of zero public keys, attackers can forge valid signatures for certain messages or manipulate signature results in aggregated signature scenarios.

3. **Library Crash Vulnerability**:

```

// Sending zero-length signatures or messages causes the library to crash

blst_verify(NULL, 0, message, message_len, ...); // Program crashes

```

4. **Zero Value Issues in Modular Arithmetic**:

```python
    # Incorrect implementation of modular inverse calculation
    def inverse_mod(a, p):
    # Lack of check for a=0
        return pow(a, p-2, p) # When a=0, the result is 0 instead of an error
    # In the correct case, an exception should be thrown because 0 has no modular inverse
    ```

5. **Zero Value Manipulation in Aggregated Signatures**:

Attackers can construct special signature combinations, exploiting the special properties of zero values in the aggregation process to tamper with the entire aggregated signature result or cause the verification process to produce incorrect results.

- **Recommendation**

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

- **References**

[https://github.com/cryptosubtlety/0](https://github.com/cryptosubtlety/0)

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

- **Exploitation Scenario**

1. Generate rogue public key: (where pki is the honest public key).

$pk_r=g_1^{0}-\sum pk_i$

2. Forge signature: Sign a malicious message with the zero key and calculate the rogue signature to offset the honest signature.

3. Additionally, the attacker can forge a Proof of Possession by reversing the honest proof and multiplying by a new index to bypass the Bilinear Key Encapsulation (B-KEA) assumption.

This can lead to successful aggregate verification, but the actual message is malicious, deceiving the system (such as malicious block injection in L1 blockchain).

- **Recommendation**

Implement strict verification of Proof-of-Possession (PoP) mechanisms, avoid relying on simple summation aggregation; consider using non-linear aggregation or additional randomness.

## 6. RSA Security

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

### 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^924 bits; consider more stringent standards such as |p-q| > 2^(nlen/2) and |p-(n/p)| > 2^(nlen/2);

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

- **Exploitation Scenario**

Assume there are two different RSA key pairs that share the same modulus n but use different public key exponents e₁ and e₂, and corresponding private key exponents d₁ and d₂:
    - Key Pair 1: (n, e₁, d₁)
    - Key Pair 2: (n, e₂, d₂)
    According to the mathematical principles of RSA, we know:
    - e₁·d₁ ≡ 1 (mod φ(n))
    - e₂·d₂ ≡ 1 (mod φ(n))
    The attacker knows the public keys (n, e₁) and (n, e₂). Using the Extended Euclidean Algorithm, if e₁ and e₂ are coprime, the attacker can find integers s and t such that:
    s·e₁ + t·e₂ = gcd(e₁, e₂) = 1
    This implies:
    s·e₁ + t·e₂ ≡ 1 (mod φ(n))
    Through mathematical derivation, we get:
    s·e₁ ≡ 1 - t·e₂ ≡ 1 - t·(1 - e₂·d₂) ≡ 1 - t + t·e₂·d₂ (mod φ(n))
    This indicates that if t is negative, then d₁ ≡ -t·d₂ + ... (mod φ(n)), and the attacker can directly calculate the private key.

- **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;

- **References**
        
        [https://www.members.tripod.com/irish_ronan/rsa/attacks.html](https://www.members.tripod.com/irish_ronan/rsa/attacks.html)

### 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 are mainly manifested in the following attack scenarios:

1. **Direct Root Attack**: If the plaintext message m is small, leading to m³ < n, then the ciphertext c after encryption is actually equal to m³. An attacker can directly calculate m = ∛c without knowing the private key.

2. **Håstad Broadcast Attack**: When the same message is encrypted with the same small exponent e (such as e=3) and sent to multiple recipients (using different moduli n), an attacker can recover the original message using the Chinese Remainder Theorem and direct root calculation.

3. **Coppersmith's Related Message Attack**: If an attacker knows part of the plaintext or multiple messages with mathematical relationships that have been encrypted, they can use Coppersmith's method to recover the complete message in polynomial time.

4. **Bleichenbacher Padding Attack**: Targeting RSA implementations with improper padding mechanisms, a small exponent exacerbates the effectiveness of such attacks.

These vulnerabilities are particularly dangerous in practical applications because many developers may choose small exponents to improve performance, especially in resource-constrained environments, and may not be aware of or may 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 large prime number and still maintains reasonable performance.

### 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:

1. **Wiener Attack**: When d < n^(1/4)/3, attackers can use continued fraction expansion to find a good rational approximation of e/n and effectively recover the private key d.

2. **Boneh-Durfee Attack**: This is an improved version of the Wiener attack, which can successfully recover the private key when d < n^0.292, using lattice basis reduction and the Coppersmith method.

3. **Partial Key Exposure Attack**: If some bits of d are known and d is small, attackers can more easily recover the complete d.

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

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

- **Exploitation Scenario**

In RSA encryption, if padding (such as PKCS#1 or OAEP) is not used and the plaintext message $ m $ is very short (for example, $ m $ is much smaller than the square root of the modulus $ N $), an attacker can use Coppersmith's theorem or other low-decryption-exponent attacks to recover $ m $.

For example:

- Assume the RSA public key is $ (N, e) $, where $ e $ is small (e.g., $ e=3 $).

- The attacker intercepts the ciphertext $ c = m^e \mod N $ and knows that $ m $ is short.

- By using polynomial root-finding or lattice basis reduction techniques, the attacker can efficiently find $ m $ without the private key. This is common in early or insecure RSA implementations, such as in some custom protocols that directly encrypt short messages (e.g., a 16-byte key), leading to practical attacks like the Coppersmith attack demonstrated in the 1990s.

- **Recommendation**

When implementing RSA encryption, use PKCS#1 v2.1 OAEP (Optimal Asymmetric Encryption Padding), which adds randomness and extends the message size.

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

- **Exploitation Scenario**

For example:

- An attacker intercepts a valid RSA ciphertext c (encrypting plaintext m).

- They generate variant ciphertext c' = (c * 2^e) mod N and send it to the server.

- Based on whether the server reports valid padding, the attacker uses the Bleichenbacher algorithm to gradually recover m. This was proven effective in the 1998 Bleichenbacher attack, which affected SSL/TLS implementations and led to variants such as the 2014 ROBOT attack.

- **Recommendation**

Ensure that the RSA decryption and padding validation processes do not leak information in terms of time and return messages.

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

### 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**

For example:

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

## 7. Hash Security

### 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^64 variant messages.

For example:

- An attacker creates 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 with 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.

### 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).

- **Exploitation Scenario**

A project implemented a server-side validation mechanism to protect sensitive API operations. When a user attempts to invoke administrative functions, the system requires a hash value for verification. The validation process is as follows:

1. After the user logs in, the server calculates the hash value using the SHA-256 algorithm:
    ```
    hash = SHA-256(SecretKey + "user_id=1&user_name=aa")
    ```
    Here, SecretKey is a 30-character server-side private key that the user should not know.

2. When the user needs to perform administrative operations, they must provide the corresponding parameters and the correct hash value. The server recalculates the hash and compares it:
    ```
    serverHash = SHA-256(SecretKey + data)
    ```
    If the hash provided by the user matches serverHash, the verification passes and the operation is executed.
    The attacker exploits this vulnerability in the following way:
    
    1. First, they obtain a legitimate hash value through normal login:
    ```
    hash = "37d310d3465506486431fb2c2eb163f0f470479703f66dc9e5fdead8a3390c68"
    ```
    2. Using a length extension attack tool, the attacker tries different lengths (up to 30 attempts) to determine the length of SecretKey.
    3. Once the correct length is determined, the attacker constructs new data by appending malicious parameters "&role=admin" to the original data:
    ```
    newData = "user_id=1&user_name=aa" + padding + "&role=admin"
    ```
    Here, padding is the padding bits added by the SHA-256 algorithm based on the length.
    4. The attacker uses the length extension attack tool to generate a new hash value without knowing SecretKey:
    ```
    newHash = "84ae4ae437eeabf3bd8a26294392770b86f64a81998194156ac003d58a21acd0"
    ```
    5. The attacker submits a request to the administrative API, including the constructed data and the calculated hash value. After the server verifies that the hash matches, it mistakenly grants the attacker administrative privileges.
    This attack allows the attacker to forge valid requests and perform unauthorized operations, including privilege escalation, data modification, or access to sensitive functions, without knowing the server-side key.

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

## 8. AES Security

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

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

- **References**

[https://frereit.de/aes_gcm/](https://frereit.de/aes_gcm/)

### 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).

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

## 9. Other Cryptographic Protocols

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

### 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. [CVE-2023-33241]

The severity of the vulnerability depends on the implementation parameters:

Case 1 (Beta parameter ~ q^5): Attackers can obtain private key share leaks in the first round of the MPC protocol by constructing malicious messages, and only need 16 signatures to recover the complete private key. In a special sub-scenario of the Apache Milagro library, due to the extremely low beta parameter (256 bits), attackers can even recover the key from the signature ceremony records without constructing malicious messages.

Case 2 (Beta parameter ~ N): Attackers need to actively control one of the signing parties and obtain private key leaks throughout the MPC protocol interaction by constructing malicious messages. For the two-party case, it takes 200,000 to 1 billion (failed) signature attempts to extract the complete key.

The attack targets the "Multiplication-to-Addition" phase of the protocol, where attackers construct a malicious Paillier modulus containing 16 small primes, extracting 16 bits of key information per attack, and ultimately recovering the complete private key using the Chinese Remainder Theorem.

- **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^20).

- **References**

https://www.fireblocks.com/blog/gg18-and-gg20-paillier-key-vulnerability-technical-report/

Common-Cryptographic-Risks-in-Blockchain-Applications

Explore Similar Repositories

Was this content helpful?

Recent Feedback

Download README