Skip to content

Rushikesh-Yeole/Neokey

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

2 Commits
 
 
 
 
 
 

Repository files navigation

🔐 Neokey

The Vaultless Zero-Knowledge Password PlatformLive

The password manager that cannot be breached,
because there is nothing to breach.


1. The Core Insight

Traditional password managers are single-points-of-failure relying on static secure enclaves.

Neokey treats credential management as a distributed systems problem. It eliminates persistent storage entirely. Instead of retrieving data, the system utilizes a vaultless, split-key architecture to mathematically synthesize credentials at runtime, all while remaining cloud-native.

By pushing deterministic generation to the edge (client) and treating the server as an opaque metadata layer and blind indexing engine, Neokey achieves a true zero-knowledge position.


🛡️ Security Baseline

  • Encryption-in-Transit: 100% of API payloads are wrapped in an AES-256-GCM + RSA-2048-OAEP double-envelope.

  • Zero-Persistence Sessions: Authentication states are volatile. Sessions auto-lock on idle, requiring local re-derivation (hydration) from the Master Password.

  • Granular Rate Limiting: Server-side enforcement with operation-specific thresholds (stricter limits on specific ops) to prevent brute-force and resource exhaustion.

  • Work Factor: Argon2id parameters are tuned to enforce memory-hardness, rendering large-scale GPU/ASIC brute-force attempts computationally and economically prohibitive.


2. Cryptographic Data Flows

Neokey System Architecture

Neokey utilizes a split-key architecture. The final passwords are mathematically dependent on both client-side ephemeral secrets (strictly runtime, isolated in RAM) and server-side opaque metadata.


Phase I: Bootstrapping & RAM Isolation (Auth)

The system establishes a zero-trust session without ever transmitting the master password.

[Client RAM]                                              
1. Generate Ephemeral Salts through server handshake on login:
   csalt = Argon2id(email, Server_Env_Salts, cost_params) -> Client Localstorage with AES-GCM encryption (via per-user rotating *saltKey* from server) 

2. Derive cred & snKey:
   cred = Argon2id(password, csalt, cost_params)
   snKey = HMAC(cred, "snkey")
    -> Locked in CredStore (ephemeral RAM-only closure)

   cred_hash = HMAC(cred, "cred")

3. Secure Payload Transmissions (applicable to all ops):
   Payload = AES-256-GCM(payload) + RSA-2048-OAEP(AES key)

[Server DB]
4. Verify & Index: address = HMAC(Server_Env_Salts, index_version || cred_hash)
   Server validates OTP -> Provisions stateless JWT
   Stores ONLY: Anonymous & Opaque `address` hash.

* csalt: client salt, cred: credential, snKey: service encryption key

Phase II: Stateless Provisioning (Creation)

When a password is "created," the server learns nothing about the service or password.

[Client]                                                  
1. Bundle Request:
   sigKey = HMAC(cred, "sigkey")
   service_sign = HMAC(sigKey, service_name)
   Client AES-Encrypts `service_name` using RAM-bound `snKey`.

   metadata, service_entropy -> CSPRNG (32-byte Hex-encoded)   
   cred_hash = HMAC(cred, "cred")

   Payload = Encrypt(service_sign + encrypted_service + cred_hash + metadata + service_entropy)

[Server DB]
2. Opaque Indexing:
   address = HMAC(Server_Env_Salts, index_version || cred_hash)
   service_sign = HMAC(Server_Env_Salts, service_sign)
   
3. Store Metadata:
   DB.Update(address) -> 
   Store ONLY:
   - `service_sign` (Anonymous mapping)
   - `service_entropy` (random entropy)
   -  encrypted_service (For client autocomplete (UX). Server cannot decrypt)
   - `metadata` (updatable random entropy for password rotation)
   
   *Zero passwords. Zero PII (Personally Identifiable Information). Zero parsable identifiers.*

Phase III: Deterministic Synthesis (Retrieval)

To "reveal" a password, the client and server engage in a synchronized cryptographic handshake.

[Server]
1. Compute Seed (HMAC Stretching on 'service metadata' ):
   serverSeed = HMAC_Stretching(Server_Env_Salts, metadata)
   serverSeed, service_entropy -> Encrypts and sends to Client.

[Client RAM]
2. Runtime Context:
   cred = Argon2id(password, csalt, cost_params)
   cred_hash = HMAC(cred, "cred")
   ckey = HMAC(cred, service_entropy) 

[ KEYGEN ]
3. Entropy Generation (XOF):
   entropyStream = BLAKE3_XOF(ckey, serverSeed)

4. Synthesis:
   Service password = Fisher-Yates shuffle (entropyStream, character_sets)
   -> Copied to clipboard. Wiped from memory instantly.

Phase IV: The Bifrost Protocol (Rapid Session Bootstrapping)

Bifrost enables fluent session sync with secondary devices without repeating the 2FA, for quick ephemeral sessions lasting 45 minutes.

  • Primary Device: Encrypts its active partial RAM state (csalt) using an ephemeral RSA PubKey from secondary device.
  • The Tunnel: The Server holds this encrypted payload against a high-entropy 6-digit bridge code with a strict 60-second TTL.
  • Secondary Device: Submits the code -> Receives the payload on authorization from primary device -> Dynamically decrypts the session state using own PrivateKey.
  • Zero-Trust Enforcement: The session is transferred, but locked. The user must still provide their master key locally on the new device to synthesize credentials, ensuring the 'Soft lock' on active session is never bypassed.

Phase V: RAM Hydration & Local Attrition (Session Unlock)

Neokey treats browser localStorage as hostile territory to survive a closed tab without compromising zero-trust principles, using a 'Soft lock'.

[Data at Rest - localStorage]

Stores ONLY:

  • AES-Encrypted csalt (Wrapped via per-user rotating saltKey from server)
  • Stateless JWT No usable cryptographic material is persisted.

[Data in Use - Runtime Hydration]

  1. User inputs Master Password to unlock an active session.
  2. Client forces an intensive Argon2id derivation to compute the salts.
  3. Decrypts csalt -> Dynamically derives cred and snKey.
  4. State is re-hydrated directly into the CredStore (RAM-only closure).

Result: Stealing the browser's local storage yields a useless (csalt) encrypted blob, and downstream creds protected by an Argon2id wall & rate limits.


3. Threat Model & Attack Resistance

Attack Vector What the Attacker Gets Systemic Defense
Complete DB Dump Anonymous Opaque hashes (address, service_sign), metadata. Mathematically irreversible. Zero plaintexts stored.
Offline cracking yields nothing.
Server Root Compromise Server Environment Salts, HMAC stretching logic. Useless without client's csalt and 'cred' using raw master password in runtime.
Passwords cannot be synthesized.
Network Sniffing RSA-OAEP + AES-GCM payloads. Ephemeral stub keys are generated client-side per-request. Double-encrypted transit layer.
Malicious Insider Read access to backend infrastructure. Zero emails, zero passwords, zero identifiable service names in plaintext.

4. Competitive Landscape

Feature Neokey Traditional Vaults (Bitwarden/1Password) Stateless Alternatives (LessPass)
Architecture Vaultless Split-Key Client Derivation Encrypted Static Vault Client-Only Synthesis
Server Breach Impact Anonymous opaque hashes Vault exfiltration (Crackable offline) + PII No server sync
Cryptographic Core Argon2id + BLAKE3 XOF + HMAC PBKDF2 / Argon2id + AES-256 PBKDF2 (lower GPU resistance vs Argon2id)
Metadata Sync ✔︎ Opaque hashes ✔︎ Encrypted passwords ❌ Manual tracking required
Session Hydration ✔︎ Argon2id -> RAM closure ✔︎ Decrypted into memory ❌ None
Device Transfer ✔︎ Cloud sync ✔︎ Cloud sync ❌ Custom manual inputs required
Trust Model "I can't." "I promise I won't." "No one to trust."

⚠️ Disclosure

Limitations & Non-Negotiables

Master Password Strength: Use a high-entropy secret. It acts as the primary local anchor for your soft-locked sessions, fortified by server-side 2FA and memory-hardened salts.

Non-Recoverable Access: Loss of the Master Password and the Recovery Artifact (offline encrypted pdf downloaded at signup) results in permanent lockout. There is no "Reset Password" function. This is an intentional result of the vaultless architecture.


5. System Architecture & Tech Stack

Neokey is engineered as a high-throughput, zero-knowledge compute engine. The infrastructure handles cryptographic synthesis at the edge while maintaining an opaque, highly available backend.

Domain Technology Architectural Purpose
Edge Compute React.js + Web Crypto API Executes heavy deterministic synthesis (Argon2id, BLAKE3) natively in the browser.
Manages RAM-isolated closures for zero-persistence state.
No secrets or plaintext touch the server
Stateless API Node.js + Express High-concurrency event loop handling RSA/AES decryption, HMAC stretching, and opaque indexing without holding request state, alongside rigorous rate limiting.
Ephemeral State Redis Drives the Bifrost protocol & active sessions. Manages strict, high-speed TTLs for distributed session bootstrapping.
Persistent Store MongoDB Highly indexed document store handling anonymous hashes (address, service_sign). Enforces unique constraints without storing passwords or PII.
Primitives Argon2id, BLAKE3, AES-GCM ASIC-resistance (Argon2id), high-speed XOF entropy generation (BLAKE3), and authenticated encryption (AES-256-GCM).

Repository structure

/client : Client-side source (public for transparency)
server/ : Backend: Node.js + Express (closed, beta)

The client-side cryptographic implementation is fully auditable here.
Server-side behavior (HMAC stretching, opaque indexing, Bifrost relay) is described in this README.


Philosophy

"The best vault is the one that doesn't exist."

Live Beta: neokey.in

Reach out →
Security inquiries, reviews, and feedback are welcome.
XLinkedInEmail

Your passwords were never here.


About

Neokey is a vaultless zero-knowledge password platform that doesn't store your passwords or identity.

Topics

Resources

Stars

Watchers

Forks

Contributors