[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <2e0fe4b0-8508-428f-9472-34c0421326a7@oracle.com>
Date: Thu, 19 Feb 2026 10:26:22 -0800
From: Alan Coopersmith <alan.coopersmith@...cle.com>
To: oss-security@...ts.openwall.com
Subject: Default IV & other issues in aes-js & pyaes modules, &
strongMan VPN manager
https://blog.trailofbits.com/2026/02/18/carelessness-versus-craftsmanship-in-cryptography/
reports:
> Two popular AES libraries, aes-js and pyaes, “helpfully” provide a default IV
> in their AES-CTR API, leading to a large number of key/IV reuse bugs. These
> bugs potentially affect thousands of downstream projects.
>
[...]
>
> Reusing a key/IV pair leads to serious security issues: if you encrypt two
> messages in CTR mode or GCM with the same key and IV, then anybody with access
> to the ciphertexts can recover the XOR of the plaintexts, and that’s a very
> bad thing.
>
[...]
>
> As you might guess from the names, aes-js and pyaes are JavaScript and Python
> libraries that implement the AES block cipher. They’re pretty widely used: the
> Node.js package manager (npm) repository lists 850 aes-js dependents as of this
> writing, and GitHub estimates that over 700,000 repositories integrate aes-js
> and nearly 23,000 repositories integrate pyaes, either as direct or indirect
> dependencies.
>
[...]
>
> The default IV problem
> ----------------------
> We’ll start with the biggest concern Trail of Bits identified: when
> instantiating AES in CTR mode, aes-js and pyaes do not require an IV.
> Instead, if no IV is specified, libraries will supply a default IV of
> 0x00000000_00000000_00000000_00000001.
>
> Worse still, the documentation provides examples of this behavior as
> typical behavior. For example, this comes from the pyaes README:
>
> aes = pyaes.AESModeOfOperationCTR(key)
> plaintext = "Text may be any length you wish, no padding is required"
> ciphertext = aes.encrypt(plaintext)
>
> The first line ought to be something like
> aes = pyaes.AESModeOfOperationCTR(key, iv),
> where iv is a randomly generated value. Users who follow this example will
> always wind up with the same IV, making it inevitable that many (if not most)
> will wind up with a key/IV reuse bug in their software. Most people are looking
> for an easy-to-use encryption library, and what’s simpler than just passing in
> the key?
>
> That apparent simplicity has led to widespread use of the “default,” creating
> a multitude of key/IV reuse vulnerabilities.
>
> Other issues
> ============
>
> Lack of modern cipher modes
> ---------------------------
>
> aes-js and pyaes don’t support modern cipher modes like AES-GCM and
> AES-GCM-SIV. In most contexts where you want to use AES, you likely want to
> use these modes, as they offer authentication in addition to encryption.
> This is no small issue: even for programs that use aes-js or pyaes with
> distinct key/IV pairs, AES CTR ciphertexts are still malleable: if an
> attacker changes the bits in the ciphertext, then the resulting bits in the
> plaintext will change in exactly the same way, and CTR mode doesn’t provide
> any way to detect this. This can allow an attacker to recover an ECDSA key
> by tricking the user into signing messages with a series of related keys.
>
> Cipher modes like GCM and GCM-SIV prevent this by computing keyed “tags”
> that will fail to authenticate when the ciphertext is modified, even by a
> single bit. Pretty nifty feature, but support is completely absent from
> aes-js and pyaes.
>
> Timing problems
> ---------------
>
> On top of that, both aes-js and pyaes are vulnerable to side-channel attacks.
> Both libraries use lookup tables for the AES S-box, which enables cache-timing
> attacks. On top of that, there are timing issues in the PKCS7 implementation,
> enabling a padding oracle attack when used in CBC mode.
>
> Lack of updates
> ---------------
>
> aes-js hasn’t been updated since 2018. pyaes hasn’t been touched since 2017.
> Since then, a number of issues have been filed against both libraries.
> Here are just a few examples:
>
> - Outdated distribution tools for pyaes (it relies on distutils,
> which has been deprecated since October 2023)
> - Performance issues in the streaming API
> - UTF-8 encoding problems in aes-js
> - Lack of IV and key generation routines in both
>
> Developer response
> ------------------
>
> Finally, in 2022, an issue was filed against aes-js about the default IV
> problem. The developer’s response ended with the following:
>
> The AES block cipher is a cryptographic primitive, so it’s very important
> to understand and use it properly, based on its application. It’s a
> powerful tool, and with great power, yadda, yadda, yadda. :)
>
[...]
>
> In November 2025, we reached out to the maintainer via email and via X, but we received no response.
>
[...]
>
> We identified several pieces of software impacted by the default IV behavior
> in pyaes and aes-js. Many of the programs we found have been deprecated, and
> we even found a couple of vulnerable wallets for cryptocurrencies that are no
> longer traded. We also picked out a large number of programs where the security
> impact of key/IV reuse was minimal or overshadowed by larger security concerns
> (for instance, there were a few programs that reused key/IV pairs, but the key
> was derived from a 4-digit PIN).
>
> However, one of the programs we found struck us as important: a VPN management
> suite.
>
> strongMan VPN Manager
> ---------------------
>
> strongMan is a web-based management tool for folks using the strongSwan VPN
> suite. It allows for credential and user management, initiation of VPN
> connections, and more. It’s a pretty slick piece of software; if you’re into
> IPsec VPNs, you should definitely give it a look.
>
> strongMan stored PKCS#8-encoded keys in a SQLite database, encrypted with AES.
> As you’ve probably guessed, it used pyaes to encrypt them in CTR mode, relying
> on the default IV. In PKCS#8 key files, RSA private keys include both the
> decryption exponent and the factors of the public modulus. For the same modulus
> size, the factors of the modulus will “line up” to start at the same place in
> the private key encodings about 99.6% of the time. For a pair of 2048-bit
> moduli, we can use the XOR of the factors to recover the factors in a matter
> of seconds.
>
> Even worse, the full X.509 certificates were also encrypted using the same
> key/IV pair used to encrypt the private keys. Since certificates include a
> huge amount of predictable or easily guessable data, it’s easy to recover
> the keystream from the known X.509 data, and then use the recovered keystream
> to decrypt the private keys without resorting to any fancy XORed-factors
> mathematical trickery.
>
> In short, if a hacker could recover a strongMan user’s SQLite file, they
> could immediately impersonate anyone whose certificates are stored in the
> database and even mount person-in-the-middle attacks. Obviously, this is
> not a great outcome.
>
> We privately reported this issue to the strongSwan team. Tobias Brunner,
> the strongMan maintainer, provided an absolute model response to a security
> issue of this severity. He immediately created a security-fix branch and
> collaborated with Trail of Bits to develop stronger protection for his users.
> This patch has since been rolled out, and the update includes migration tools
> to help users update their old databases to the new format.
>
> Doing it right
> --------------
>
> There were several viable approaches to fixing this issue. Adding a unique IV
> for each encrypted entry in the database would have allowed strongMan to keep
> using pyaes, and would have addressed the immediate issue. But if the code has
> to be changed, it may as well be updated to something modern.
>
> After some discussion, several changes were made to the application:
>
> - pyaes was replaced with a library that supports modern cipher modes.
> - CTR mode was replaced with GCM-SIV, a cipher mode that includes
> authentication tags.
> - Tag-checking was integrated into the decryption routines.
> - A per-entry key derivation scheme is now used to ensure that key/IV pairs
> don’t repeat.
>
> On top of all that, there are now migration scripts to allow strongMan users
> to seamlessly update their databases.
>
> There will be a security advisory for strongMan issued in conjunction with this
> fix, outlining the nature of the problem, its severity, and the measures taken
> to address it. Everything will be out in the open, with full transparency for
> all strongMan users.
See the full original blog post for further details and some strong opinions
omitted above.
For the strongMan issue, see:
https://github.com/strongswan/strongMan/security/advisories/GHSA-88w4-jv97-c8xr
--
-Alan Coopersmith- alan.coopersmith@...cle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
