🔐

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 to stay small.

ATLOCK v5 is still under development. It has NOT been publicly released yet.

The current public release is ATLOCK v4.

But v5 is where ATLOCK stops being just another file-locking application and starts becoming a much more serious Windows security architecture.

⚠️ First: v5 is NOT released yet

Let's make that crystal clear.

ATLOCK v5 → Building

ATLOCK v4 → Current public release

If you want to test ATLOCK today, use v4.

Download ATLOCK v4: 👇

https://github.com/Akhouri-Anmol-Kumar/ATLOCK/releases/download/v4.0/ATLOCK.zip

If you are interested in what is coming next, keep reading.

🧠 The story behind ATLOCK v5

I'm 13 years old.

I don't have a security company with hundreds of engineers behind it.

I don't have a hardware security laboratory.

I don't have a huge development machine.

My primary development machine(But for me it is not a machine it is my bro) is an:

HP 240 G9

And ATLOCK v5 is being built on it.

The goal wasn't:

"Let's make another password-protected folder."

The goal became:

What happens if a small, Windows-first security application is designed around multiple layers instead of one big encryption button?

That question pushed ATLOCK from v4 into v5.

And that's where things got interesting.

🛡️ ATLOCK v4 → ATLOCK v5

ATLOCK v4 already had a serious feature set.

The v4 architecture includes:

• 🔒 System Lockdown
• 📁 Windows NTFS ACL-level File Guard
• 🔐 Password Vault
• 🎥 Intruder Operations
• 🚨 Alarm/sound responses
• ⚙️ Security settings
• 🔑 Fernet-based vault encryption
• 🔐 PBKDF2-HMAC-SHA256 password derivation
• 🪟 Windows-specific security hardening

The v4 source explicitly describes its File Guard as using Windows NTFS ACLs and its vault as Fernet-based encryption with PBKDF2-HMAC-SHA256.

But v5 isn't simply:

v4 + more buttons

It's a redesign of the underlying security core.

⚙️ What actually changed in v5?

Here's the architectural jump.

That is the difference I'm most proud of.

🔐 The cryptographic core got rebuilt

This is probably the biggest technical change in ATLOCK v5.

The v5 source defines:

Argon2id
   ↓
HKDF-SHA256
   ↓
Domain-separated keys
   ↓
AES-256-GCM

The v5 file container is built around chunked AES-256-GCM.

That means the encrypted container isn't simply:

FILE → ENCRYPT → DONE

The architecture instead processes data in authenticated chunks.

Each chunk gets independent authentication, while the container header is also authenticated.

The design includes:

• AES-256-GCM
• key commitment
• authenticated header data
• per-chunk authentication
• chunk indexes as authenticated data
• final-chunk state
• streaming encryption
• integrity verification before plaintext release

The source specifically defines Container v3 around chunked AES-256-GCM, independent per-chunk authentication, key commitment and authenticated header/AAD handling.

That's a fundamentally different design direction from the v4 vault architecture.

🧠 Argon2id + HKDF

Another major change:

ATLOCK v5 uses Argon2id as a memory-hard password-derived-key foundation.

The architecture then uses HKDF-SHA256 for domain separation.

In simple terms:

                    PASSWORD
                        │
                        ▼
                    Argon2id
                        │
                        ▼
                   Master Secret
                        │
                        ▼
                   HKDF-SHA256
             ┌──────────┼──────────┐
             ▼          ▼          ▼
          File Key   Vault Key   Audit Key

Instead of treating one derived key as the answer to everything, v5 separates cryptographic purposes.

The source defines separate domains for functions including encryption, verification, vault, recovery wrapping, state MACs, audit, media and session protection.

That's the kind of architectural detail I wanted ATLOCK to have.

🧱 Container v3

ATLOCK v5 introduces a new container generation.

The container contains authenticated metadata including:

• magic/version information
• salt
• KDF parameters
• chunk size
• nonce information
• key commitment
• plaintext length
• authenticated header hash

Then the encrypted body is processed chunk-by-chunk.

The important idea:

Integrity isn't an afterthought.

A modified encrypted container should not simply become "some corrupted data."

ATLOCK v5's self-test suite specifically checks:

• encryption/decryption round trips
• wrong-key rejection
• tamper detection
• recovery-key operation
• sealed local state
• audit-chain verification
• self-integrity hashing

The source's built-in self-test explicitly includes Argon2id + AES-256-GCM container tests, wrong-key rejection and tamper detection.

🧬 The state layer was rebuilt too

This is one of the parts that doesn't look exciting in a screenshot.

But security engineering isn't only about what the user sees.

ATLOCK v5 stores sensitive application state in a protected data layer.

The source describes:

.atlock_data/
│
├── *.atl
├── *.atl.bak
├── store.key
├── anchor.bin
├── recovery/
├── work/
└── media/

The state is protected using authenticated encryption, while the root state key is protected with Windows DPAPI.

The architecture also uses rollback anchors and monotonically increasing counters to make old state harder to replay.

In other words:

The database itself became part of the security model.

That's a major philosophical difference between a simple security utility and a security architecture.

🧩 TPM-backed protection

And then I went one layer deeper.

ATLOCK v5 can optionally use a TPM-backed Windows CNG key.

The design keeps DPAPI protection but can additionally wrap the ATLOCK root key using a TPM-backed RSA key.

If hardware-backed protection becomes unavailable, the code is designed to fail closed rather than silently pretending the protection still exists.

This is optional because hardware availability varies between machines.

The source explicitly implements Microsoft's Platform Crypto Provider path and verifies the hardware-key round trip before enabling the protection.
That's a pretty different level of thinking from:

"Let's encrypt the password."

👤 Windows Hello + FIDO2 + TOTP

ATLOCK v5 also moves authentication beyond a single password.

The source supports authentication policies including:

password
password + Windows Hello
password + TOTP
password + Windows Hello or TOTP
password + FIDO2
password + Windows Hello or FIDO2

Windows Hello can use Windows' own verification mechanisms such as:

• fingerprint
• face
• PIN

And FIDO2/WebAuthn hardware keys can optionally be integrated.

The CLI even exposes dedicated FIDO2 setup, listing, removal and self-test operations.

So the direction is:

PASSWORD
    +
OPTIONAL SECOND FACTOR
    +
OPTIONAL HARDWARE

rather than assuming one password must do everything.

🚨 Recovery without pretending recovery is magic

Security products have an uncomfortable problem:

What happens when the legitimate user loses access?

ATLOCK v5 introduces a controlled Vault Recovery Key system.

The recovery flow is designed around:

1. explicit recovery setup
2. protected recovery material
3. verification
4. vault key recovery
5. re-encryption under a new master password
6. revocation of the old recovery key
7. audit events

The source specifically describes the recovery operation as auditable and designed to revoke the old recovery key after successful use.

That's important because a recovery feature should not quietly become a permanent backdoor.

👁️ Watchdog + Canary + Background Protection

ATLOCK v5 is also moving toward active protection.

Optional mechanisms include:

Startup Watchdog

Checks security-related conditions at startup.

Ransomware Canary

Uses decoy mechanisms to detect suspicious modification activity.

Background Protection

Can run a user-level background agent that periodically checks enabled protection mechanisms.

The source explicitly keeps background protection OFF by default and allows it to monitor canary, watchdog and sealed-state health when enabled.

That's a very different concept from a passive encrypted folder.

📈 v4 vs v5: the architecture benchmark

Now let's talk benchmarks.

I'm deliberately not going to invent numbers.

I don't have a controlled lab dataset proving:

"v5 is exactly 37.4% faster."

And I'm not going to manufacture one just because it looks good in a marketing post.

Instead, here's the benchmark that can already be demonstrated from the source architecture.

Security architecture benchmark

That's the architecture benchmark.

The actual performance benchmark is still something I want to publish properly.

And when I do it, I want reproducible measurements:

Same laptop
Same Windows build
Same test files
Same file sizes
Same configuration
Multiple runs
Median + percentile results
CPU usage
RAM usage
Encryption throughput
Decryption throughput
Vault operations
Startup time

No fake benchmark graphics.

No cherry-picked result.

Just measurements.

📊 One measurable v4 → v5 change already visible in the source

ATLOCK v4 defines:

MAX_GUARDED = 10

ATLOCK v5 defines:

MAX_GUARDED = 31

That's a straightforward capacity change.

But I don't want to pretend that a higher number automatically means "better security."

It means:

v5 was engineered to manage a larger protected-file set.

That's the kind of distinction I want to keep throughout this project.

🆚 ATLOCK v5 vs major products in the space

There are already excellent security products in this field.

I'm not going to claim that a 13-year-old's unfinished project has somehow defeated decades of security engineering.

That would be ridiculous.

Instead, the interesting question is:

What is ATLOCK trying to do differently?

1. ATLOCK v5 vs VeraCrypt

VeraCrypt official website

VeraCrypt is heavily focused on encrypted volumes, partitions, drives and system encryption. It supports on-the-fly encryption and Windows system encryption with pre-boot authentication.

ATLOCK approaches the problem differently.

VeraCrypt's core strength

Encrypted Volume
       ↓
Mounted Storage
       ↓
Encrypted Data

ATLOCK's direction

File Guard
    +
Vault
    +
System Lockdown
    +
Intruder Response
    +
Authentication
    +
Recovery
    +
Audit
    +
Watchdog
    +
Hardware Protection

VeraCrypt is therefore not something ATLOCK needs to "replace."

It is an example of a highly specialized encryption architecture.

ATLOCK's goal is broader:

A Windows-first security suite rather than primarily an encrypted-volume platform.

2. ATLOCK v5 vs Cryptomator

Cryptomator official website

Cryptomator is specifically designed around client-side encryption, particularly for cloud storage. It encrypts file contents and filenames and supports Windows, macOS, Linux, Android and iOS.

Its architecture is fundamentally cloud-friendly.

ATLOCK is much more Windows-local in its design philosophy.

Cryptomator:

YOUR FILES
    ↓
CLIENT-SIDE ENCRYPTION
    ↓
CLOUD STORAGE

ATLOCK:

YOUR WINDOWS PC
      │
      ├── File Guard
      ├── Vault
      ├── Lockdown
      ├── Intruder Ops
      ├── Authentication
      ├── Watchdog
      ├── Recovery
      └── Local security state

So these aren't identical products solving exactly the same problem.

That's precisely why I don't want to market ATLOCK as "Cryptomator killer."

That's lazy marketing.

3. ATLOCK v5 vs Folder Lock-style security suites

Commercial security suites in this category commonly combine encrypted storage, file protection and privacy-oriented utilities.

ATLOCK is attempting a similar suite-level direction, but with an emphasis on:

• Windows-native controls
• application-layer security
• authenticated encrypted containers
• optional hardware-backed key protection
• authentication policies
• auditability
• watchdog/canary concepts
• developer-visible security architecture

The important differentiator isn't:

"ATLOCK has encryption and they don't."

That's obviously not true.

The differentiator is:

How many security layers are being integrated into one Windows-first application architecture?

🧠 So why am I building ATLOCK v5?

Because I don't want ATLOCK to be:

"A password box around a folder."

I want it to become a layered security platform.

Something closer to:

                 ┌─────────────────────┐
                 │     ATLOCK v5       │
                 └──────────┬──────────┘
                            │
          ┌─────────────────┼─────────────────┐
          │                 │                 │
          ▼                 ▼                 ▼
     FILE SECURITY      VAULT SECURITY   SYSTEM SECURITY
          │                 │                 │
          ▼                 ▼                 ▼
      AES-GCM          Argon2id          Lockdown
      ACLs             Recovery          Session lock
      Integrity        2FA               Watchdog
      Recovery         FIDO2             Canary
          │                 │                 │
          └─────────────────┼─────────────────┘
                            ▼
                    HARDWARE / OS LAYER
                            │
                            ▼
                    DPAPI + OPTIONAL TPM

That's the direction.

💻 And yes — this was built on an HP 240 G9(my bro)

This part matters to me.

Because the project started without the environment people normally associate with security engineering.

No massive server.

No enterprise security lab.

No giant development team.

Just:

One laptop.

And a lot of engineering work.

The machine doesn't magically make the software good.

The architecture does.

The testing does.

The mistakes do.

The debugging does.

The redesigns do.

And the willingness to keep rebuilding the parts that aren't good enough does.

🔥 ATLOCK v5 isn't finished

This is important.

I'm showing you the architecture.

I'm showing you the direction.

I'm showing you what has already been built.

But I'm not pretending the project is production-perfect.

ATLOCK v5 is still under development.

It hasn't received the level of independent security auditing that established security products can have.

It is also a pure-Python, application-layer project.

That means there are real limitations.

For example, the source itself acknowledges that a sufficiently privileged/same-user attacker who can execute code in the user's context can potentially inspect or modify the process. It also explicitly notes that Python memory handling makes guaranteed secret erasure impossible.

That's why I don't use phrases like:

"Unhackable."

or

"Military-grade."

Those are marketing words.

Security engineering needs evidence.

🧪 I want you to break ATLOCK v4

And here's where you can actually help.

ATLOCK v5 isn't public yet.

But ATLOCK v4 is public.

Instead of simply downloading it and saying:

"Looks cool."

I want testers to try to find problems.

Test:

• File Guard
• Vault
• Lockdown
• Intruder Operations
• authentication
• recovery behavior
• unexpected application exits
• unusual file operations
• large files
• repeated lock/unlock cycles
• edge cases
• UI failures
• Windows-specific behavior

Find something I missed.

Report it.

Because every real bug found in v4 gives me information I can use while building v5.

🚀 This is what ATLOCK v5 means to me

Not:

"I'm 13 and therefore my software is automatically amazing."

No.

Age isn't a security property.

Being 13 doesn't make AES stronger.

Being 30 doesn't make a program weaker.

The interesting part is that I'm building and learning this architecture unusually early.

The real statement is:

I had one laptop, so I started.

And then:

I found limitations, so I rebuilt things.

And then:

I found more limitations, so I rebuilt more things.

That's how ATLOCK v5 happened.

🔐 ATLOCK v4 is available. v5 is coming.

If you need a security tool today, ATLOCK v4 is the publicly available version.

If you're interested in where ATLOCK is going, v5 is the build to watch.

I'm not asking you to blindly trust it.

I'm asking you to watch the architecture evolve.

Test it.

Question it.

Find weaknesses.

And if you see something wrong, tell me.

Because that's how this gets better.

⚡ ATLOCK v5 — still building.

13 years old.

One HP 240 G9.

One security project.

Zero shortcuts on the engineering side.

And the next version is still being built.

ATLOCK v4 is available.

ATLOCK v5 is coming.

The interesting part is what happens between the two.

📌 Current status

ATLOCK v4: Publicly available: (https://github.com/Akhouri-Anmol-Kumar/ATLOCK/releases/download/v4.0/ATLOCK.zip)
ATLOCK v5: In development
Platform: Windows-first
Developer: Akhouri Anmol Kumar
Company: Akhouri Systems

"I build what others forgot to fix"