Default IV Flaw in aes-js and pyaes Libraries Exposes Thousands of Projects to Key Reuse Attacks
Trail of Bits disclosed that two widely used AES libraries, aes-js and pyaes, supply a default IV in CTR mode, causing widespread key/IV reuse vulnerabilities across thousands of downstream projects.
Trail of Bits has disclosed a critical design flaw in two popular AES libraries, aes-js (npm, ~850 dependents) and pyaes (PyPI, ~23,000 repositories), that undermines the security of countless applications. When instantiating AES in CTR mode, both libraries do not require an initialization vector (IV). Instead, they silently supply a default IV of `0x00000000_00000000_00000000_00000001`. This seemingly helpful behavior leads directly to key/IV reuse, a cryptographic sin that can allow attackers to recover plaintext XOR or decrypt all secrets if one is compromised.
The impact is severe. Reusing a key/IV pair in CTR mode means that if an attacker obtains two ciphertexts encrypted with the same key and IV, they can compute the XOR of the plaintexts. Even in the best case, the security of all encrypted data degrades to the security of the weakest secret. Trail of Bits noted that the libraries' documentation even provides examples that omit the IV, encouraging users to follow this dangerous pattern. For instance, the pyaes README shows `aes = pyaes.AESModeOfOperationCTR(key)` as typical usage, when it should require a randomly generated IV.
Beyond the default IV issue, both libraries lack support for modern authenticated encryption modes like AES-GCM and AES-GCM-SIV. Without authentication, AES-CTR ciphertexts are malleable: an attacker can flip bits in the ciphertext and correspondingly alter the plaintext without detection. This can enable attacks such as ECDSA key recovery through related-key signing. Additionally, both libraries are vulnerable to side-channel attacks because they use lookup tables for the AES S-box, enabling cache-timing attacks, and their PKCS7 padding implementation is susceptible to padding oracle attacks in CBC mode.
The libraries have also been abandoned for years: aes-js hasn't been updated since 2018, and pyaes since 2017. Numerous issues have been filed, including problems with outdated distribution tools, performance issues, and encoding bugs. An issue about the default IV was filed against aes-js in 2022, but the developer's response was dismissive, essentially telling users to understand cryptography properly before using the library.
Trail of Bits contrasted this with the response from strongSwan, an affected VPN vendor, whose maintainer provided a model response for security vendors. The stark difference between the two reactions illustrates what Trail of Bits calls the difference between carelessness and craftsmanship in cryptography. The firm emphasized that while they typically work to fix systemic threats through static analysis tools and documentation, this particular bug's outsized impact on the ecosystem required public disclosure.
Developers relying on aes-js or pyaes are urged to migrate to libraries that enforce proper IV handling and support authenticated encryption modes. For now, any application using these libraries with the default IV is vulnerable to key reuse attacks, and the lack of updates means no patches are forthcoming. The incident serves as a cautionary tale about the dangers of cryptographic libraries that prioritize convenience over security.