CVE-2024-21530

Versions of the package cocoon before 0.4.0 are vulnerable to Reusing a Nonce, Key Pair in Encryption when the encrypt, wrap, and dump functions are sequentially called. An attacker can generate the same ciphertext by creating a new encrypted message with the same cocoon object. **Note:** The issue does NOT affect objects created with Cocoon::new which utilizes ThreadRng.

Versions of the package cocoon before 0.4.0 are vulnerable to Reusing a Nonce, Key Pair in Encryption when the encrypt, wrap, and dump functions are sequentially called. An attacker can generate the same ciphertext by creating a new encrypted message with the same cocoon object. **Note:** The issue does NOT affect objects created with Cocoon::new which utilizes ThreadRng.

**Problem**: Trying to create a new encrypted message with the same cocoon object generates the same ciphertext. It mostly affects `MiniCocoon` and `Cocoon` objects with custom seeds and RNGs (where `StdRng` is used under the hood). **Note**: The issue does **NOT** affect objects created with **`Cocoon::new`** which utilizes `ThreadRng`. **Cause**: `StdRng` produces the same nonce because `StdRng::clone` resets its state. **Measure**: Make encryption API mutable (`encrypt`, `wrap`, and `dump`). **Workaround**: Create a new cocoon object with a new **seed** per each encryption. ## How to Reproduce ```rust let cocoon = MiniCocoon::from_password(b"password", &[1; 32]); let mut data1 = "my secret data".to_owned().into_bytes(); let _ = cocoon.encrypt(&mut data1)?; let mut data2 = "my secret data".to_owned().into_bytes(); let _ = cocoon.encrypt(&mut data2)?; // data1: [23, 217, 251, 151, 179, 62, 85, 15, 253, 92, 192, 112, 200, 52] // data2: [23, 217, 251, 151, 179, 62, 85, 15, 253, 92, 192, 112, 200, 52] ``` ## Workaround For `cocoon <= 0.3.3`, create a new cocoon with a different **seed** per each `encrypt`/`wrap`/`dump` call. ```rust let cocoon = MiniCocoon::from_password(b"password", &[1; 32]); let mut data1 = "my secret data".to_owned().into_bytes(); let _ = cocoon.encrypt(&mut data1)?; // Another seed: &[2; 32]. let cocoon = MiniCocoon::from_password(b"password", &[2; 32]); let mut data2 = "my secret data".to_owned().into_bytes(); let _ = cocoon.encrypt(&mut data2)?; // data1: [23, 217, 251, 151, 179, 62, 85, 15, 253, 92, 192, 112, 200, 52] // data2: [53, 223, 209, 96, 130, 99, 209, 108, 83, 189, 123, 81, 19, 1] ```

**Problem**: Trying to create a new encrypted message with the same cocoon object generates the same ciphertext. It mostly affects `MiniCocoon` and `Cocoon` objects with custom seeds and RNGs (where `StdRng` is used under the hood). **Note**: The issue does **NOT** affect objects created with **`Cocoon::new`** which utilizes `ThreadRng`. **Cause**: `StdRng` produces the same nonce because `StdRng::clone` resets its state. **Measure**: Make encryption API mutable (`encrypt`, `wrap`, and `dump`). **Workaround**: Create a new cocoon object with a new **seed** per each encryption. ## How to Reproduce ```rust let cocoon = MiniCocoon::from_password(b"password", &[1; 32]); let mut data1 = "my secret data".to_owned().into_bytes(); let _ = cocoon.encrypt(&mut data1)?; let mut data2 = "my secret data".to_owned().into_bytes(); let _ = cocoon.encrypt(&mut data2)?; // data1: [23, 217, 251, 151, 179, 62, 85, 15, 253, 92, 192, 112, 200, 52] // data2: [23, 217, 251, 151, 179, 62, 85, 15, 253, 92, 192, 112, 200, 52] ``` ## Workaround For `cocoon <= 0.3.3`, create a new cocoon with a different **seed** per each `encrypt`/`wrap`/`dump` call. ```rust let cocoon = MiniCocoon::from_password(b"password", &[1; 32]); let mut data1 = "my secret data".to_owned().into_bytes(); let _ = cocoon.encrypt(&mut data1)?; // Another seed: &[2; 32]. let cocoon = MiniCocoon::from_password(b"password", &[2; 32]); let mut data2 = "my secret data".to_owned().into_bytes(); let _ = cocoon.encrypt(&mut data2)?; // data1: [23, 217, 251, 151, 179, 62, 85, 15, 253, 92, 192, 112, 200, 52] // data2: [53, 223, 209, 96, 130, 99, 209, 108, 83, 189, 123, 81, 19, 1] ```

Las versiones del paquete cocoon anteriores a la 0.4.0 son vulnerables a la reutilización de un par de claves nonce en el cifrado cuando se invocan secuencialmente las funciones de cifrado, envoltura y volcado. Un atacante puede generar el mismo texto cifrado creando un nuevo mensaje cifrado con el mismo objeto cocoon. **Nota:** El problema NO afecta a los objetos creados con Cocoon::new, que utiliza ThreadRng.