š
No funding. No team. No mentor. No enterprise lab.
Just a 13-year-old developer, an HP 240 G9, and a security project that refused t...
For further actions, you may consider blocking this person and/or reporting abuse
Genuinely impressive amount of ground covered here. Argon2id plus HKDF domain separation plus chunked AEAD with key commitment is architecture a lot of professional teams get wrong on the first try. One honest note since you're inviting people to test v4: until v5 has been through independent review, I'd keep the "shake the security market" talk out of the pitch. The engineering speaks for itself without it, and toning the claims down will make security reviewers take the audit request more seriously.
Thanks a lot for the kind words and the honest feedback, I really appreciate it. You're right, "shake the security market" was excitement(my fire in heart & brain) talking. I'll tone that down until it's been independently reviewed..
Since you looked at the design, what would you test first if you were poking at it? I'm still unsure about how I bind the header and chunk index into the AAD, so I'd love to hear where you think the weak spots are. Also curious what made you notice the key commitment part, since most people skip it.
Good questions. To be upfront, this comes from the categories in your post, not a code review of the source, so treat it as things worth checking rather than a diagnosis.
What I'd test first: nonce reuse across chunks after things like migration or re-encryption during recovery. That's usually where chunked AEAD designs quietly break. A nonce that's unique in the normal path isn't always unique across every code path that writes a chunk. Second thing: truncation. If someone drops the final chunk from the ciphertext, does decryption catch that, or does it just stop early and look like it worked? The final-chunk marker you mentioned should make that impossible to get away with, so it's worth a dedicated test for exactly that case.
On binding the header and chunk index into the AAD: the property you want is that swapping two chunks between positions, or splicing in a chunk from a different file, fails to decrypt. If the chunk index and container ID (or the key-commitment value) are both in the AAD, that should already hold. A good test is to take a valid encrypted container, swap two chunks, and check that it fails instead of quietly decrypting garbage.
Key commitment stood out because AES-256-GCM doesn't have it by default. There's known research (the "invisible salamanders" attack) showing you can build ciphertext that decrypts to different plaintext under different keys, which matters a lot for anything password-derived. Most small encryption tools never mention it, so seeing it named explicitly told me you'd actually looked into that class of problem instead of just reaching for a library.
Okay, I finally made it here. š
First: I wasnāt ignoring you. Iāve just been buried under my own projects, infrastructure and security work lately.
Now, ATLOCK.
Iām deliberately not going to say āthis is amazing because youāre 13.ā
Age is interesting context, but as you correctly said yourself: age isnāt a security property.
What interests me much more is that youāre already thinking about things like domain-separated keys, authenticated metadata, rollback protection, recovery boundaries, hardware-backed key wrapping and migration paths.
Those are exactly the places where security software stops being āI encrypted a fileā and starts becoming architecture.
But since you invited people to challenge it, Iāll be the annoying guy. š
Before I trusted v5 with anything important, Iād want to attack the assumptions around it rather than just test whether encryption/decryption works.
Iād look very closely at:
And then Iād test something even more important:
What happens when the attacker is not attacking AES?
Cryptography is often the strongest part of a security product.
The ugly bugs tend to appear around the crypto: state transitions, recovery, authorization, filesystem semantics, key lifecycle, error handling and privilege boundaries.
One other thing: be careful with statements like:
āYour files, credentials all will be safe. Itās ATLOCK guarantee.ā
I know what you mean, and I know it comes from confidence in what you built. But security engineering punishes absolute guarantees. š
Iād rather see ATLOCK say:
āHere is our threat model. Here are the properties we claim. Here are the attacks we tested. Here are the limitations we know about. Now try to break those claims.ā
That is much stronger than āunbreakableā or āguaranteed safe.ā
And I actually respect that the article already acknowledges Python memory limitations and same-user/privileged attacker boundaries. Keep doing that. Documenting what a security product cannot protect against builds more credibility, not less.
So no, Iām not going to give v5 a security score from an architecture description. š
Show me the implementation when itās ready.
Then we can make your HP 240 G9 regret ever meeting you. šš
thanks... :) bro for taking time to read and write such detailed comment. Honestly, seeing this level of professional feedback on my post means a lot to me. ššš„
You are 100% right about the "guarantee" word. I know it sounds like marketing, and security engineering punishes absolute word.
I am happy you noticed the architecture. Actually, in ATLOCK V5, I already tried to cover some of your attack vectors:
Chunk reordering/duplication is blocked because I bind chunk index and final flag directly into the per-chunk GCM AAD.
KDF downgrade/DoS is prevented by enforcing strict KDF_MAX ceilings on untrusted headers.....
State rollback uses dual independent Anchors (file + registry) that take the max() counter on load.
Hardware protection is strictly fail-closed. If TPM-backed key is unavailable, it refuses to silently fallback to DPAPI-only....
But your point on Recovery Key rotation is a very true catch. If the old recovery wrap was already exfiltrated from disk, just rotating the recovery key doesn't cryptographically revoke it unless I fully re-encrypt the underlying file secret. I would either implement.. full re-keying or explicitly document this exfiltration boundary. Also, the 2-second polling for File Guard TOCTOU is indeed just best-effort, I will make this limitation very clear in docs....
When v5 implementation is ready for wider audit, I will definitely ping you to break it.
My HP 240 G9 is ready for the stress test šš.(because it's not my machine it's my bro always ready for me and akhouri systems)
Thanks again for taking this seriously.
ATLOCK V5 is too close to be released publicly just waiting to cross 1000downloads
currently 905downloads.
divyanshi Didi kindly mention that your are informing me DEV SUPPORT is scam
people are thinking you are telling my ATLOCK scam.
Ok BTW congratulations ššš»
Thanks, by the way may I know why mustafa ERBAY is ignoring me?
I don't know why?!š¤
Thanks for telling me. I was worried about it.
I'm ready for any discussion you want regarding ATLOCK
comment below š
start discussion
One thing that I'm sure about ATLOCK v5 is that it will never disappoint you
Your Files, credentials all will be safe.
It's ATLOCK guarantee..
I'm not hyping it, I'm just telling what my 7100lines of code can do.
A power demonstration.
I don't know ATLOCK v5 will be the best of it's kind or not but one this I'm damn sure
is that if VeraCrypt or any big security giant seen ATLOCK v5 then they are gonna be frustrated not because ATLOCK v5 is better than VeraCrypt but because they will think how a 13yr kid in HP 240 G9 cooked this level security suite.
I'm not over confident I'm just informing or better word DECLARING that ATLOCK V5 will shake the security market.
ATLOCK V4 protected your files, V5 will protect you š«µ