I Tried to Break My Own Security Suite. It Fought Back (and I Found 1 Thing I'm Not Happy About)

Really nice write-up. I especially appreciate that you included what you did not test — that makes the security claims much more credible.

On sender pinning, I’d strongly prefer hard-fail.

If expected_sender_pub is explicitly provided, that is no longer just informational metadata; it is a security policy. Returning successfully with signer_matches=False means the cryptographic layer detected a policy violation but left enforcement to the caller/UI.

I’d probably make the semantics explicit:

• no pinned sender → decrypt normally and report signer identity
• pinned sender + match → decrypt successfully
• pinned sender + mismatch → fail closed with a dedicated exception
• if someone really wants “decrypt anyway”, require an explicit override rather than making that the default

That also makes the API safer for future integrations where there may be no human around to notice the warning.

One other thing I’d test before v5: make sure authentication happens before any plaintext becomes observable, especially with chunked AES-GCM. Corrupting random bits is a great test, but deliberately targeting chunk boundaries, lengths, nonces, tags, reordered/duplicated chunks, and the final truncated chunk would be interesting too.

Overall, publishing the failure cases alongside the successful tests is exactly the kind of security engineering write-up I like seeing. 👍

Really good write-up. What I like most is that you didn’t stop at “all tests passed.” You started attacking the assumptions behind the system.

That distinction is important in security. A function can behave correctly under normal tests while the overall flow still has a dangerous edge case.

The plaintext-release issue is a great example of that. Authentication can be correct at the chunk level, but if the system exposes part of the plaintext before the full verification flow finishes, the security property of the whole operation changes.

I’ve seen the same pattern outside file encryption too. For example, an API can successfully authenticate a request, but if it starts processing or exposing sensitive data before authorization is fully resolved, the individual checks may all be “working” while the system is still wrong.

That’s what makes this kind of adversarial testing valuable: you’re not only asking “does this function reject bad input?” You’re asking “at what point does the system actually trust the data?”

And honestly, publishing the failures and then showing how the design changed because of them makes this much more useful than a typical “my security tool passed 100% of its tests” post. 🔐

Appreciate you publishing the receipts, especially the sender-pinning result. Most "I tested my own tool" posts only show the wins.

Warn or hard-fail on a pinned key: hard-fail, and I don't think it's close. Pinning is an explicit statement of intent, and expected_sender_pub is the caller saying "reject anyone else." A warning only helps if a human reads it, and the return value {'signed': True, 'signer_matches': False} is exactly the shape that gets ignored by a script or a wrapper UI that checks signed and moves on. That's a classic fail-open pattern. I'd do three things:

1. Raise a dedicated exception (something like AtlockSenderMismatch) when a pin is supplied and doesn't match.
2. Don't write plaintext to out before the sender check passes. If the file has already been decrypted to disk, the warning is cosmetic.
3. Keep the "read it first, ask later" use case as an explicit opt-in, e.g. allow_unpinned_sender=True or a separate inspect mode, so the permissive path is a deliberate choice rather than the default.

The GUI can still offer an "I understand, open anyway" button on top of that. The API should be strict and the UI can be forgiving, not the other way around.

Pure-Python trust: the language matters less than what's underneath. If the primitives come from cryptography and argon2-cffi (both wrap audited C libraries), I'm not worried about timing or implementation bugs in AES-GCM or Argon2 themselves. My concerns are different:

• Memory hygiene. Python can't reliably zero secrets. Strings and bytes get copied, interned, and left for the GC, so keys and passwords may linger in RAM or swap. Worth stating in the docs next to your SSD caveat.
• Supply chain. A single-file tool that pulls requests, pillow, numpy and qrcode has a larger dependency surface than a vault needs. Consider splitting the crypto core from the optional features so the core can be audited on its own.
• Audit status. A thorough self-test is great, but it isn't a third-party review. Say so plainly, and a short threat model doc would help people judge fit.

Argon2id at 128 MiB: fine for most laptops from the last ~8 years, but I'd make it adaptive rather than fixed. Benchmark on first run, store m, t, p in the header, and target something like 0.3 to 0.5 s on that machine. A low-RAM device could then use a lower floor with a clear warning, and you could raise parameters over time with a rekey-on-open path. Your doctored-header KDF ceiling check is a good sign you've already thought about the flip side, a malicious file demanding absurd memory.

A few other notes from the post:

• 200 bit-flips is a good sanity check, but it's mostly testing GCM's tag. It would be worth adding targeted flips in the header, chunk boundaries and chunk counters. Chunked AEAD schemes usually fail at reordering, truncation at a chunk boundary, and chunk duplication, so make sure each chunk binds its index and a final-chunk flag. You mention 5 truncation points; confirm at least one lands exactly on a chunk boundary.
• Key-committing is a nice touch that many designs skip. Worth a short explanation in the README, since it's a real differentiator.
• For the three urlopen Mediums, pinning to https and rejecting other schemes is the right fix, and for the HIBP call, add a timeout and fail closed on errors rather than treating "couldn't check" as "not pwned."
• Since you tested only on Linux, I'd label the Windows-specific pieces (DPAPI, Windows Hello) as experimental until they've been run on real hardware.

What would make me switch: a documented threat model, a reproducible build or signed releases, an independent review (even informal), and a stable, documented container format so files stay readable years from now. Your frozen v1/v2/v3.0 compatibility test is the right instinct there.

Good luck on the way to 1,000. Looking forward to seeing the v5 changelog.

@akhourianmolkumar Bro, this is the spirit of true engineering.

"I tried to break it... it fought back." That is the best compliment a security tool can receive. If it doesn’t fight back, it’s useless.

Finding "1 thing you’re not happy about" is actually a win. Most people hide those flaws until they explode in production. You surfaced it now, while you can fix it.

KODA and ATLOCK are siblings in chaos. I’m shipping fast and fixing bugs in hours; you’re stress-testing boundaries and finding cracks. We are covering the full spectrum of HYNAWEB: Velocity + Resilience.

Drop the link when you patch that flaw. I’ll be first in line to test it against my Worker’s injection defenses. Let’s see if KODA’s 1µs regex filter can catch what ATLOCK misses. 😂️🐯

You may refer to Jev, which works like an access control system. If identity verification fails, it blocks the operation entirely rather than just showing a warning.

Mustafa ERBAY hehehe