some ideas do not start from whiteboards or diagrams. they start from habits. for years, i have carried a usb drive on my keychain. not because i always needed it, but because “just in case” felt safer than “i hope i won’t”. at hackudc 2026, that small object became the seed of a larger question: if i trust a physical key to protect my house, why do i trust a memorized password to protect my digital life?
HouseKey Vault was born from that thought. what if authentication was not something you remember, but something you physically hold? not a master password. not a shared secret. but a cryptographic identity stored in a file you control.
modern password managers promise zero-knowledge architectures, yet most still require you to derive a master secret from something you type. if that secret is weak, reused, phished, or brute-forced offline, your vault is exposed. if you forget it, you are locked out forever. the paradox is simple: we want convenience, but we inherit fragility.
the deeper issue is not encryption strength. it is where trust resides. who holds the key material? who can potentially reconstruct it? what assumptions are we making about the server?
during the hackathon, i looked at my keychain and realized something obvious. i never forget my house key. i never reuse it across houses. i never send a copy of it to a remote server and hope they protect it well. i simply carry it.
so we inverted the model. instead of authenticating with a password, HouseKey Vault authenticates with a cryptographic key pair generated directly in the browser using the Web Crypto API. the private key is written to a .hkv file , ideally on a usb drive. the public key is stored on the server. the private key never leaves the client.
login becomes a challenge-response flow using ECDSA P-256. the server issues a nonce. the browser signs it with the private key. the server verifies the signature against the stored public key. if valid, access is granted. if not, a lockout mechanism is triggered. no master password. no shared secret. no fallback that compromises the model.
authentication alone is not enough. the vault itself must remain unreadable to the server. every credential, folder, note, and metadata field is serialized and encrypted client-side using AES-256-GCM. the encryption key is not random; it is derived from the private key using HKDF-SHA256 with domain separation and a salt bound to the public key hash. this ensures the vault key is cryptographically scoped to this specific identity and cannot be reused elsewhere.
each save operation generates a fresh IV. integrity is guaranteed by GCM authentication tags. tampering results in explicit decryption failure. a database breach yields ciphertext and initialization vectors , nothing more.
physical keys can be lost. so can usb drives. the question was how to design recovery without introducing a hidden backdoor.
at registration, a 12-word seed phrase is generated using secure randomness. a secondary encrypted copy of the vault is created using a key derived from that phrase via PBKDF2 with 200,000 iterations. only the hash of the seed is stored server-side for verification. the server cannot derive the recovery key.
if the key file disappears, the seed phrase allows the client to decrypt the recovery vault, generate a brand-new key pair, and rebind the account in a single flow. the previous key is cryptographically invalidated. recovery restores access , not trust in the server.
in 48 hours we implemented more than a minimal proof of concept. secure credential sharing via ephemeral ECDH key exchange, where the decryption key lives only in the URL fragment and never reaches the server. a duress mode that opens a decoy vault indistinguishable from the real one at database level. second-device protection for high-sensitivity entries, requiring either a separate key file or an emergency passphrase derived via PBKDF2 with shared salt.
breach detection uses the Have I Been Pwned k-anonymity model, sending only the first five characters of a SHA-1 hash prefix through a rate-limited proxy. TOTP codes are generated entirely in-browser using HMAC-SHA1 via Web Crypto. every exported file carries an invisible zero-width watermark encoding an account fingerprint and timestamp for forensic traceability.
everything runs on native cryptographic primitives. no external crypto libraries. no opaque black boxes. explicit algorithms. explicit threat model. explicit tradeoffs.
this project was not about novelty. it was about alignment. if we say we believe in user autonomy, we must design systems that reflect that belief. if we say we value privacy, we must architect it structurally , not rhetorically.
carrying a usb on my keychain was always a small act of preparedness. HouseKey Vault extends that instinct into the digital realm. your identity is not something you memorize. it is something you hold. something that does not exist on someone else’s infrastructure.
hackathons compress time. they force decisions. they remove comfort. in that pressure, ideas reveal their essence. HouseKey Vault is not just a password manager; it is a reflection on trust boundaries and personal responsibility in cryptographic design. if the server is compromised, your vault remains sealed. if you lose both your key file and your seed phrase, no one can save you , and that is intentional.
true security is not about convenience. it is about clarity of ownership.
you can explore the code here and try the live demo here
the virtuous life is
- a. r. brea written 03/03/26