Rule Information
Tags
pythoncryptographyblowfishsweet32birthday-attack64-bit-blockCWE-327OWASP-A02
CWE References
Interactive Playground
Experiment with the vulnerable code and security rule below. Edit the code to see how the rule detects different vulnerability patterns.
pathfinder scan --ruleset python/PYTHON-CRYPTO-SEC-002 --project .1
2
3
4
5
6
rule.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
About This Rule
Understanding the vulnerability and how it is detected
This rule detects instantiation of the Blowfish algorithm via the `cryptography` library's `cryptography.hazmat.primitives.ciphers.algorithms.Blowfish` class. Blowfish uses a 64-bit block size, which makes it susceptible to the Sweet32 birthday attack once approximately 32GB of data is encrypted under the same key.
The Sweet32 attack (CVE-2016-2183) exploits the birthday paradox: with a 64-bit block cipher in CBC mode, after 2^32 blocks (roughly 32GB), the probability of a block collision exceeds 50%. An attacker who can observe enough ciphertext can exploit these collisions to recover plaintext, including session cookies in HTTPS traffic. All major browsers and TLS stacks have disabled 64-bit block cipher suites as a result.
The rule matches `CryptoCipherAlgorithms.method("Blowfish")`. Blowfish's key flexibility (32 to 448 bits) does not mitigate the block size problem. The companion rule PYTHON-CRYPTO-SEC-002a covers Blowfish in PyCryptodome.
Security Implications
Potential attack scenarios if this vulnerability is exploited
1
Sweet32 Birthday Attack After 32GB of Data
With a 64-bit block cipher, the birthday bound is 2^32 blocks (~32GB). Once this threshold is crossed under the same key, block collisions become likely. In CBC mode, an attacker who observes a collision can XOR the surrounding blocks to recover the repeated plaintext. For long-lived TLS sessions or bulk data encryption, this threshold is reachable in hours on a busy server.
2
No Authenticated Encryption -- Padding Oracle Risk
Blowfish as exposed through the cryptography hazmat API does not provide authenticated encryption. Using it in CBC mode without a separate MAC creates padding oracle vulnerability surfaces. An attacker can submit modified ciphertexts and observe error responses to decrypt content without the key.
3
Deprecated by All Major TLS Implementations
Following CVE-2016-2183 (Sweet32), all major TLS stacks -- OpenSSL, NSS, GnuTLS, and Java's JSSE -- disabled 64-bit block cipher suites by default. Blowfish usage in new code runs counter to the established security consensus and will be flagged in any TLS configuration audit.
4
Design-Era Limitations Relative to AES
Blowfish was designed in 1993 as a free alternative to DES. AES was standardized in 2001 after an open competition and has a 128-bit block size that eliminates the Sweet32 class of attacks entirely. There is no scenario where Blowfish is the right choice for new code.
How to Fix
Recommended remediation steps
- 1Replace Blowfish with AES-256-GCM (AESGCM from cryptography.hazmat.primitives.ciphers.aead) for authenticated encryption
- 2Use ChaCha20-Poly1305 as an alternative when hardware AES acceleration is not available
- 3If using a block cipher mode manually (CBC, CTR), always pair it with a separate HMAC-SHA256 to detect tampering
- 4Rotate keys and re-encrypt any data stored with Blowfish under AES-256-GCM
- 5Audit TLS configuration to confirm no 64-bit block cipher suites remain enabled alongside this code-level fix
Detection Scope
How Code Pathfinder analyzes your code for this vulnerability
This rule matches calls to the Blowfish constructor in the cryptography library's hazmat algorithms module via the QueryType pattern `CryptoCipherAlgorithms.method("Blowfish")`. It fires on any instantiation of a Blowfish cipher object, regardless of key size or block mode. The 64-bit block size vulnerability applies to all Blowfish configurations. The companion rule PYTHON-CRYPTO-SEC-002a covers Blowfish in PyCryptodome.
Compliance & Standards
Industry frameworks and regulations that require detection of this vulnerability
OWASP Top 10
A02:2021 - Cryptographic Failures
PCI DSS v4.0
Requirement 4.2.1 -- use strong cryptography for data protection
NIST SP 800-131A
Transitioning to approved algorithms -- RC4/DES/3DES disallowed
NIST SP 800-53
SC-13: Cryptographic Protection
References
External resources and documentation
Similar Rules
Explore related security rules for Python
HIGH
Blowfish Cipher Usage via PyCryptodome
Detects use of the Blowfish cipher through PyCryptodome, which has a 64-bit block size making it vulnerable to Sweet32 birthday attacks after approximately 32GB of data.
HIGH
IDEA Cipher Usage via cryptography Library
Detects use of the IDEA cipher through the cryptography library, which has a 64-bit block size making it vulnerable to Sweet32 birthday attacks and is deprecated in modern cryptographic standards.
HIGH
DES Cipher Usage via PyCryptodome
Detects use of single DES through PyCryptodome, which has only a 56-bit key that has been publicly brute-forceable since 1999 and is disallowed by FIPS 46-3 (withdrawn 2005).
Frequently Asked Questions
Common questions about Blowfish Cipher Usage via cryptography Library
Key length and block size are separate properties. Blowfish's key size is indeed
flexible and large, but the Sweet32 attack targets the 64-bit block size, not
the key. Once 2^32 blocks are encrypted under any Blowfish key of any length,
the birthday bound is reached and block collisions become exploitable. AES
eliminates this with its 128-bit block size.
For truly isolated, small, one-off files with key rotation between each file,
the practical risk is reduced. However, the 32GB limit is a per-key bound --
if the same key is reused across many small files, the total ciphertext volume
accumulates. The safer path is to use AES-GCM, which has a 128-bit block size
and eliminates the Sweet32 class of attacks entirely regardless of data volume.
In CBC mode, each plaintext block is XORed with the previous ciphertext block
before encryption. When two blocks encrypt to the same ciphertext (a birthday
collision), an attacker can XOR the two ciphertext blocks with each other and
with the preceding blocks to recover the plaintext of one block if the other
is known. In HTTPS sessions, an attacker can inject known content (e.g., CSRF
tokens in form data) and wait for the collision to reveal the session cookie.
If an immediate replacement is not feasible, limit each Blowfish key to
encrypting no more than 4GB (well below the 32GB birthday bound), rotate keys
frequently, and add a separate HMAC-SHA256 over each ciphertext to detect
tampering. Document this as a temporary measure with a hard cutoff date and
migrate to AES-256-GCM before that date.
No. The rule specifically matches the Blowfish symmetric cipher constructor via
cryptography.hazmat.primitives.ciphers.algorithms.Blowfish. The bcrypt password
hashing function uses the Blowfish key schedule in a different way and is not
flagged by this rule. Bcrypt is appropriate for password hashing; symmetric
Blowfish is not appropriate for data encryption.
New feature
Get these findings posted directly on your GitHub pull requests
The Blowfish Cipher Usage via cryptography Library rule runs in CI and posts inline review comments on the exact lines — no dashboard, no SARIF viewer.