Request for review: Aeon Secure Suite v4.4 – offline WebCrypto toolkit (+ MicroVault v1.9 air-gapped file vault)
Hi all,
I’d like to share something I’ve been building and ask for honest feedback and critique on the \*\*cryptography and implementation details\*\*.
I’m \*\*not\*\* a professional developer or cryptographer. I’m a person who believes technology should serve humanity, not extract from it. With the help of AI assistants (ChatGPT / GPT-style models and Claude), I’ve built an offline, single-file encryption toolkit called \*\*Aeon Secure Suite\*\*, plus a lightweight companion tool called \*\*MicroVault\*\*.
This post is \*\*not\*\* about currency or tokens. I’m specifically looking for feedback on how I’m using standard cryptographic primitives (AES-GCM + PBKDF2) via Web Crypto, the data formats, and the documented threat model.
\---
\### Links (MIT-licensed, full source)
\*\*GitHub repo (single-file HTML source):\*\*
[https://github.com/Aeon-ProjectWormHole/Aeon\_Secure\_Suite](https://github.com/Aeon-ProjectWormHole/Aeon_Secure_Suite)
\*\*Latest release (v4.4 + MicroVault v1.9):\*\*
[https://github.com/Aeon-ProjectWormHole/Aeon\_Secure\_Suite/releases/tag/v4.4](https://github.com/Aeon-ProjectWormHole/Aeon_Secure_Suite/releases/tag/v4.4)
\- Both tools are shipped as \*\*standalone HTML files\*\* (viewable source).
\- No backend, no telemetry, everything runs via the browser’s \*\*Web Crypto API\*\*.
\- SHA-256 hashes are published in the README and in \`checksums.txt\` in the repo for verification.
\---
\### What Aeon Secure Suite does (scope)
Aeon v4.4 is an \*\*offline WebCrypto-based toolkit\*\* that:
\- Encrypts/decrypts \*\*messages\*\* (text), individual \*\*files\*\*, and simple \*\*vault entries\*\*.
\- Runs entirely in the browser from a local \`.html\` file (typically opened via \`file://\`).
\- Presents a \*\*plain-language threat model and safety notes\*\* targeted at non-experts.
The code is plain HTML + JavaScript; all cryptographic logic lives in \`<script>\` tags in that one file.
\---
\### What MicroVault v1.9 does (scope)
MicroVault is a small, “air-gapped friendly” \*\*file vault\*\*:
\- Takes multiple files and bundles them into a single encrypted JSON “vault” object.
\- Intended for workflows like:
\- Prepare on one machine (possibly online),
\- Move via USB or other offline means,
\- Decrypt on another machine (possibly air-gapped).
Its implementation is also a single \`.html\` file using Web Crypto with similar parameters.
\---
\### Cryptography & data formats (implementation summary)
All crypto is done via \*\*Web Crypto\*\* in the browser:
\- \*\*Key derivation:\*\*
\- \`PBKDF2\` with \`HMAC-SHA-256\`
\- Random 128-bit salt (generated via \`crypto.getRandomValues\`)
\- Iterations: \*\*300,000\*\* (default; tunable in the code/config)
\- Derived key length: \*\*256 bits\*\*
\- \*\*Cipher:\*\*
\- \`AES-GCM\` (via \`crypto.subtle.encrypt\` / \`decrypt\`)
\- IV: 96-bit random IV per encryption (also via \`crypto.getRandomValues\`)
\- Tag: GCM authentication tag handled by Web Crypto and stored alongside the ciphertext (encoded as part of the encrypted payload)
\- \*\*Envelope structure (high-level):\*\*
\- For messages / files / vaults, the encrypted output is encoded as a JSON object containing fields similar to:
\- \`version\` / format indicator
\- \`salt\` (base64 or hex-encoded)
\- \`iv\` (base64 or hex-encoded)
\- \`iterations\` (integer, usually 300000)
\- \`cipher\` / \`mode\` metadata
\- \`ciphertext\` (base64 or hex-encoded AES-GCM output, including tag)
\- The exact field names and formats can be seen directly in the HTML source in the repo (it’s all there in one place).
There are \*\*no custom ciphers\*\* or novel crypto constructions here—just AES-GCM + PBKDF2 wrapped in JSON with some UX logic around it. I’m explicitly \*not\* trying to invent a new cryptosystem, just to wire standard primitives in a transparent, auditable way.
\---
\### Threat model / non-goals (important)
Intended to help with:
\- Protecting local data at rest (e.g., lost laptop, USB stick, casual physical access).
\- Giving non-technical people a simple, \*\*offline\*\* way to encrypt:
\- important documents,
\- personal notes,
\- small file bundles.
\*\*Not\*\* intended to:
\- Protect against \*\*malware, keyloggers, or compromised OS/browser\*\*.
\- Defeat highly resourced, persistent \*\*state-level attackers\*\* with full device compromise.
\- Replace a robust operational security setup.
If you lose your \*\*passphrase\*\*, \*\*vault\*\*, or the \*\*HTML file\*\*, the data is gone.
There is no recovery, no server, no password reset.
\---
\### Why this exists (human context – very short)
I’m not a developer by trade. I built this because I believe privacy tools shouldn’t require a computer science degree. They should be as accessible as possible to people who actually need them: journalists, activists, domestic abuse survivors, small legal/medical teams, etc.
This is part of “Project Aeon” — my attempt to rebuild some trust between humans and technology through transparency, sovereignty, and honesty about limitations.
\---
\### What I’m asking from this community
If you have time and interest, I’d be grateful for feedback on:
1. \*\*Crypto correctness / misuse\*\*- Any obvious misuse of AES-GCM or PBKDF2 in the implementation.- IV and salt generation/handling practices.- Whether the JSON envelope structures and encoding choices have any pitfalls (e.g., issues around associated data, truncation, or encoding mistakes).
2. \*\*Threat model realism\*\*- Does the documented threat model match what this implementation actually provides?- Are there risks I’m understating or missing that should be called out more strongly in the README or UI?
3. \*\*UX / wording foot-guns\*\*- Anything in the UI or wording (in the HTML or README) that might give non-technical users a false sense of security.- Suggestions on clearer or more conservative phrasing.
If someone finds a \*\*serious issue\*\*, I’m prepared to:
\- Deprecate the current version.
\- Ship a fixed release with clear notes and version bump.
\- Update the README and in-app text to reflect any newly understood limitations.
\---
\### AI / LLM usage & prompts (per r/crypto rules)
I’ve used AI/LLMs heavily during this project and for this post, so I want to be explicit:
\*\*Models used:\*\*
\- ChatGPT (GPT-5.1-class model, branded as ChatGPT)
\- Claude (claude.ai)
\*\*How they were used:\*\*
\- To help design and refine the structure of the HTML/JS Web Crypto code.
\- To stress-test the threat model and help identify UX “foot-guns”.
\- To draft and refine documentation (README sections, security notes, this post text).
\*\*Representative prompt for this Reddit post (ChatGPT):\*\*
\> "Lets post this in reddit, I just got the green light to post in r/crypto. Let's be completely open about this, honest and transparent with this build for the post."
Earlier in the project, I also used prompts along the lines of:
\- "Give me an honest security-focused review of this offline WebCrypto tool (AES-GCM + PBKDF2). Focus on threat model, UX risks, and any obvious crypto mistakes."
\- "Help me stress-test this vault implementation: look for key/IV reuse, bad randomness, encoding mistakes, or GCM misuse."
\- "Help me write a clear, non-hype threat model for non-technical users, and call out limitations explicitly."
The final implementation is still entirely my responsibility, and the \*\*full source\*\* is available in the repo HTML file for manual review.
\---
Thanks in advance for any time, critique, or pointers you’re willing to share.
— Steve
