Responding here, as you sent an email asking for feedback. Took a look at your readme, looks like a neat concept so do share teh code! But there there's some innaccuracies here that jumped out at me:
|
- **Quantum-resistant** - Current quantum computers cannot break AES-256 encryption |
AES-256 is quantum-tolerant, NOT quantum-resistant. Grover's algorithm halves effective key strength, reducing AES-256 to ~128-bit security. So, you should probably just say that AES-256 remains secure against known quantum attacks, though it is NOT post-quantum cryptography.
|
- **Forward Secrecy** - Each file uses unique cryptographic materials |
This doesn't sound like forward secrecy. Since forward secrecy requires ephemeral key exchange and your PBKDF2(password, salt) does not provide that. SO if the password is compromised, all files are compromised.
Just say something like "Key separation per file" or "per-file key derivation" instead.
|
7. **OWASP 2024 Compliant** - Meets latest security guidelines for key derivation |
WDYM? OWASP does NOT certify or formally "approve" encryption tools. They're just guidelines, and are for application security guidance, not cryptographic standards.
Likewise, there's a lot of other HIPAA / GDPR / PCI-DSS compliance claims which are just plain legal misrepresentation.
Compliance is organizational + procedural, not a property of a binary. Encryption alone ≠ HIPAA / GDPR / PCI compliance, and not to mention that executable password notebooks are explicitly risky under PCI rules.
The NIST-compliant RNG claim is also defo wrong, since NIST never certifies CryptGenRandom per application, compliance depends on mode, provider, and configuration
|
## 🛡️ Unbreakable Security Architecture |
You can't ever claim anything like this is unbreakable. Password-based encryption is only as strong as the password. Also malware, memory scraping, keyloggers, debugging, or side-channels are out of scope. No serious crypto system claims "unbreakable".
|
- **CBC Mode** - Industry-proven cipher block chaining for maximum compatibility |
AES-CBC is legacy, not misuse-resistant and requires flawless MAC-before-decrypt discipline. Something like GCM, ChaCha20-Poly1305, or AES-SIV are objectively safer nowadays. And yeah, CBC+HMAC is acceptable, but calling it superior or best practice in 2026 is misleading.
|
- **600,000 iterations** - Meets OWASP 2024 guidelines, making brute-force attacks computationally infeasible |
I could be wrong here, but isn't PBKDF2 very GPU-friendly. And 600k iterations is very feasible, esp for weak passwords. Why not use Argon2id instead. Maybe just say that it raises the cost of brute-force attacks, not makes them infeasible.
|
- 8 characters = **95^8 = 6.6 quadrillion possible combinations** |
This is a classic crypto fallacy. Policy requirements don't mean uniform entropy, and humans almost never choose passwords randomly. Entropy is not keyspace maths.
|
**ZeroShadow** is not just another encrypted notepad—it's a revolution in personal data security. Every file you create is a completely standalone, self-executing encrypted application that requires no installation, no external software, and leaves zero traces on any system. |
fr??? Currently you're only supporting Windows. And deliverying via a Win .exe
Windows executable loading leaves LOADS of traces. Think prefetch entries, memory artifacts, pagefile risk (VirtualLock is not guaranteed) and course all the AV telemetry, crash dumps and anything else running at a low level.
Responding here, as you sent an email asking for feedback. Took a look at your readme, looks like a neat concept so do share teh code! But there there's some innaccuracies here that jumped out at me:
ZeroShadow/README.md
Line 38 in 042cc51
AES-256 is quantum-tolerant, NOT quantum-resistant. Grover's algorithm halves effective key strength, reducing AES-256 to ~128-bit security. So, you should probably just say that AES-256 remains secure against known quantum attacks, though it is NOT post-quantum cryptography.
ZeroShadow/README.md
Line 203 in 042cc51
This doesn't sound like forward secrecy. Since forward secrecy requires ephemeral key exchange and your PBKDF2(password, salt) does not provide that. SO if the password is compromised, all files are compromised.
Just say something like "Key separation per file" or "per-file key derivation" instead.
ZeroShadow/README.md
Line 169 in 042cc51
WDYM? OWASP does NOT certify or formally "approve" encryption tools. They're just guidelines, and are for application security guidance, not cryptographic standards.
Likewise, there's a lot of other HIPAA / GDPR / PCI-DSS compliance claims which are just plain legal misrepresentation.
Compliance is organizational + procedural, not a property of a binary. Encryption alone ≠ HIPAA / GDPR / PCI compliance, and not to mention that executable password notebooks are explicitly risky under PCI rules.
The NIST-compliant RNG claim is also defo wrong, since NIST never certifies CryptGenRandom per application, compliance depends on mode, provider, and configuration
ZeroShadow/README.md
Line 28 in 042cc51
You can't ever claim anything like this is unbreakable. Password-based encryption is only as strong as the password. Also malware, memory scraping, keyloggers, debugging, or side-channels are out of scope. No serious crypto system claims "unbreakable".
ZeroShadow/README.md
Line 36 in 042cc51
AES-CBC is legacy, not misuse-resistant and requires flawless MAC-before-decrypt discipline. Something like GCM, ChaCha20-Poly1305, or AES-SIV are objectively safer nowadays. And yeah, CBC+HMAC is acceptable, but calling it superior or best practice in 2026 is misleading.
ZeroShadow/README.md
Line 48 in 042cc51
I could be wrong here, but isn't PBKDF2 very GPU-friendly. And 600k iterations is very feasible, esp for weak passwords. Why not use Argon2id instead. Maybe just say that it raises the cost of brute-force attacks, not makes them infeasible.
ZeroShadow/README.md
Line 105 in 042cc51
This is a classic crypto fallacy. Policy requirements don't mean uniform entropy, and humans almost never choose passwords randomly. Entropy is not keyspace maths.
ZeroShadow/README.md
Line 9 in 042cc51
fr??? Currently you're only supporting Windows. And deliverying via a Win .exe
Windows executable loading leaves LOADS of traces. Think prefetch entries, memory artifacts, pagefile risk (VirtualLock is not guaranteed) and course all the AV telemetry, crash dumps and anything else running at a low level.