Hardcoded Key and Custom Insecure Cipher Mode in Blowfish Utility

[EhsanFir]

We are security researchers at Digit Institute in Germany. While reviewing your code [chat2db-server/chat2db-server-web/chat2db-server-web-api/src/main/java/ai/chat2db/server/web/api/controller/ncx/cipher/Navicat11Cipher.java], we identified two security concerns:

1. Key Derivation (Lines 26–33)

MessageDigest sha1 = MessageDigest.getInstance("SHA1");
byte[] userKey_data = Navicat11Cipher.DefaultUserKey.getBytes(StandardCharsets.UTF_8);
sha1.update(userKey_data, 0, userKey_data.length);
key = new SecretKeySpec(sha1.digest(), "Blowfish"); // "3DC5CA39"

Key Source: Hardcoded string ("3DC5CA39").
Derivation: SHA-1 hash of the above; no salt, no stretching/iteration.
Risks:
Anyone with code access can recover the key.
No key derivation best practices: no salt or iterations.
Low entropy and easily brute-forced.
SHA-1 is not a proper KDF.
Recommendation: Only use this approach for legacy compatibility. For anything else, use a secure KDF (e.g., PBKDF2, scrypt or Argon2) with a salt and high iteration count.

2. Cipher Mode & IV Handling (Lines 38, 48+)

encryptor = Cipher.getInstance("Blowfish/ECB/NoPadding");
IV = encryptor.doFinal(parseHexBinary("FFFFFFFFFFFFFFFF"));

Mode: Blowfish in ECB mode, no padding.
IV: Always the same (derived from encrypting 8 bytes of 0xFF).
Custom chaining: Manual CBC-like logic, with no randomness or per-encryption uniqueness.
Risks:
Reused IV: Same plaintext always yields same ciphertext; vulnerable to replay and pattern analysis.
Manual block chaining is error-prone and dangerous.
No authenticity/integrity checking.
ECB mode is insecure, revealing plaintext patterns.