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

Description and use

The author tested ATLOCK v5 with self‑tests, bit‑flip attacks, fuzzing, and public‑key scenarios, finding that sender‑pinning only warns instead of hard‑failing, raising a usability/security concern.

Problem

The author wanted to validate the security of ATLOCK v5 by performing a comprehensive attack in a clean environment, but discovered a design choice that may weaken trust when a sender key is pinned.

Outcome

ATLOCK v5 passed all self‑tests, bit‑flip and fuzzing attacks, and public‑key scenarios without silent corruption or crashes. Performance measurements show Argon2id provides strong GPU resistance. However, the sender‑pinning feature only warns instead of hard‑failing, which may be a usability or security concern.

Workflow

• Create a fresh venv and install dependencies
• Run ATLOCK_v5.py --selftest to verify built‑in checks
• Perform 200 random bit‑flips on a 5 MB encrypted file and verify rejection
• Run the built‑in fuzzer with 300 mutations and confirm no crashes
• Measure performance of sealing, opening, and Argon2id hashing
• Test public‑key encryption/decryption and signature verification
• Attempt to decrypt a file with a mismatched expected sender key and observe warning behavior

Evidence

I built a single-file security suite in pure Python. Before release, I locked it in a clean virtual environment and tried to wreck it.

Source

200 out of 200 rejected. Zero silent corruption. Zero crashes.

Source

$ python ATLOCK_v5.py --fuzz 300 fuzzed 300 container mutations, 100 garbage shares, 60 junk imports: no crashes, no silent corruption.

Source

I tested sender pinning: Bob says "I only trust files from this key," then I hand him a file signed by someone else.

Source

It decrypted anyway. The app shows WARNING: this is NOT the sender key you pasted! but it does not stop.

Source