February 21, 2026

When crypto meets “it just works”

Carelessness versus Craftsmanship in Cryptography

Default-gate: Easy settings, risky secrets — 'make it safe' vs 'you get what you paid for'

TLDR: Trail of Bits flagged risky defaults in two popular encryption libraries that can expose secrets, sparking a massive debate. Commenters split between demanding safer-by-default tools and defending open-source “as-is” code, making this a clash of craft versus convenience with real-world security stakes.

Trail of Bits dropped a spicy audit bomb: two wildly popular encryption libraries, aes-js and pyaes, quietly use a built-in “starter value” (an IV) in a way that can leak secrets when reused. Translation: encrypt two different messages with the same setup and attackers can start piecing your secrets together like a jigsaw. One vendor, strongSwan, responded like pros; the aes-js/pyaes maintainer? Let’s just say the vibe was… shrug emoji. With these libs showing up in hundreds of thousands of repos, the comment section went full courtroom drama.

The top take: make the safe thing the easy thing. One user pleaded to “just pick a random IV and stick it in front of the message” so normal folks never have to learn crypto jargon. Others fired back with the classic open-source defense: it’s free, it’s “as-is,” and no one owes you enterprise-grade security — cue the mic drop: “You get what you paid for.” People dunked on the docs teaching bad habits, joked about joining the IV League, and compared the default to using “password123” for your padlock. A side thread roasted the lack of modern modes like GCM (a safer, verified flavor of AES), while pragmatists begged libraries to simply refuse to run without a proper random value. Craftsmanship vs carelessness? The code is messy, but the comments are pure theater.

Key Points

  • aes-js and pyaes default to a fixed IV (0x...0001) in AES-CTR when none is provided, enabling key/IV reuse vulnerabilities.
  • Documentation examples (e.g., pyaes README) omit IV parameters, encouraging insecure usage patterns.
  • Reusing a key/IV pair in CTR or GCM lets attackers recover the XOR of plaintexts, critically weakening confidentiality.
  • Adoption is broad: ~850 aes-js dependents on npm; GitHub estimates >700,000 repos use aes-js and ~23,000 use pyaes.
  • Trail of Bits notes strongSwan’s constructive response to a report, while the aes-js/pyaes maintainer responded less constructively; the libraries also lack AES-GCM and AES-GCM-SIV support.

Hottest takes

"pick a random IV and prepend it to the cipher text" — jopsen
"You get what you paid for" — phoronixrly
"not obliged to make changes to their (insecure) code" — phoronixrly
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.