Media
2 items
Description
Decentralized credential manager — your keys, your vault, no central server. NodeZero encrypts Gmail end-to-end and keeps your passwords in a vault that no NodeZero server ever sees — all inside a single lightweight browser extension. No account to create. No master password sent to a server. Your identity is a cryptographic key generated on your own device, which only you can unlock. WHY THIS DOES NOT SAY "ZERO-KNOWLEDGE" That phrase describes a company that stores your encrypted data and cannot read it. NodeZero does not store your data at all — there is no NodeZero server in the picture. Encryption happens on your device; the only copy that leaves it is a sealed file in your own Google Drive, which Google cannot open. NodeZero sees nothing because it never receives anything. That is a stronger claim, and an accurate one. BETA NOTICE NodeZero is under active development. While all cryptographic operations use audited libraries and follow established standards, the extension has not yet undergone a formal third-party security audit. Exercise caution: avoid storing credentials you cannot afford to lose without a backup, and always keep your 12-word recovery phrase in a safe place. Report issues at https://nodezero.top/contact. HOW IT WORKS Your vault is encrypted locally before it ever leaves your browser. Each field (username, password, notes) is encrypted individually with AES-256-GCM using a unique nonce — not as a single blob. Your vault has one encryption key, generated at random. Each way you unlock — a hardware authenticator via WebAuthn PRF, a passphrase, or your recovery phrase — holds its own separately encrypted copy of it. Adding or changing an unlock method therefore never re-encrypts your vault, and no copy of the key is stored on any server. Google Drive backup saves your encrypted vault to your own Google Drive appdata folder — a private storage area that only NodeZero can access. The vault is encrypted on your device before upload, so Google stores only ciphertext. No NodeZero server is involved in backup or restore. WHAT MAKES NODEZERO DIFFERENT No email, no phone number, no name. Your identity is a decentralised identifier (DID) derived from your cryptographic keys. There is no "forgot password" flow because there is no account. Recovery uses a 12-word mnemonic phrase — the same proven approach used by cryptocurrency wallets. No NodeZero server ever sees your encryption keys, your plaintext credentials, or your usage patterns. Backups go to your own Google Drive. All cryptographic operations happen locally in your browser. NodeZero is proprietary software. The full licence terms ship inside the extension as LICENSE.txt, alongside the notices for the open-source components it is built with. CREDENTIAL MANAGEMENT - Your Keys Stay On Your Device — Your vault has one encryption key, generated at random on your machine. Each unlock method you add holds its own separately encrypted copy of it: a hardware authenticator via WebAuthn PRF (YubiKey, SoloKeys, Titan, Feitian), a passphrase, or your recovery phrase. No copy of the key is stored on any server. There is deliberately no face or fingerprint unlock: Windows Hello and Touch ID give a browser extension no way to bind a stored key to the scan, so any key it kept would be readable from a copy of the browser profile. Authenticators without PRF use a passphrase instead. - DID-Based Identity — Your vault is owned by a decentralised identifier (did:key) that you control. No email, no phone number, no account required. - Field-Level Encryption — Every sensitive credential field is individually encrypted with AES-256-GCM and a unique IV. Not single-blob encryption. - Google Drive Backup — Back up your encrypted vault to your own Google Drive. The vault is encrypted on your device before upload, so what Google stores is ciphertext, a filename and a size. That holds by design and in normal operation; it is not a guarantee against malware on your own machine, which can read the vault while it is unlocked. Restore on any device by signing in with your Google account and entering your recovery phrase. - One-Click Import — Migrate from Chrome, LastPass, Bitwarden, or 1Password in under 60 seconds with CSV drag-and-drop. Round-trip export is also supported, and two-factor codes travel in both directions wherever the format has a column for them. - Two-Factor (TOTP) Codes — NodeZero holds your 2FA codes beside the passwords they belong to. Enrol by scanning the QR a site shows during its two-factor setup, by pasting a setup key, or by importing them with the rest of your vault. Codes are generated on your device with a live countdown; the seed is encrypted like a password and is never shown outside the editor. Non-standard issuers work too — 8-digit codes, SHA-256, and 60-second periods are read from the setup link rather than assumed. Enrolment finishes only when a code NodeZero generates matches the one the site accepted, so a mis-scan cannot leave you locked out of an account. Worth knowing before you use it: keeping a password and its second factor in one vault is a convenience with a real cost — anyone who opens the vault has both. NodeZero narrows that (the vault is local, and unlock can require a hardware key) but does not remove it. - 12-Word Recovery — A BIP-39 mnemonic phrase restores your logins and any passkeys NodeZero holds, on any device. Shown once during setup, never stored. One limit, stated plainly: in vaults created before NodeZero moved to its current key model, your saved contacts are encrypted under the primary key only and the phrase alone cannot open them — you need the original passkey or passphrase for those. Logins are restored either way, and NodeZero tells you which case you are in during recovery. You can recover a different vault on the same device with a clear warning before overwriting. - Context Menu Fill — Right-click to fill credentials with a domain-matched picker, generate passwords, or save logins. No auto-fill surprises — you choose when and where to fill. - Save Vault to File — Export your encrypted vault to a local backup file at any time. AES-256-GCM encrypted CBOR. The file is unreadable without the passphrase, security key or recovery phrase that opens that vault — and it restores completely: put it on a fresh install and your usual unlock works, no 12-word phrase required. - Passkeys — NodeZero handles passkeys in two clearly separated ways, and the difference matters. RECORDED: when you create a passkey with Windows Hello, Touch ID or a security key, NodeZero notes the public metadata (relying party, credential ID, public key, algorithm, transports) so you have an inventory of where your passkeys live. It holds no private key for these and cannot sign in with them. HELD: NodeZero can also create passkeys itself and store the private key in your vault — these do sign you in, sync with your encrypted backup, and are recoverable with your 12-word phrase. The vault list marks every passkey as one or the other. Held passkeys are syncable software credentials, not the equivalent of a hardware security key: phishing resistance is preserved because NodeZero enforces the protocol's origin and relying-party checks, but you give up non-exportability, resistance to extraction by malware on your machine, and clone detection. Every registration and every sign-in requires a click in NodeZero's own window; there is no path that signs without one. On registration it offers the choice between itself and your device's own authenticator, and dismissing the window falls through to your device rather than to NodeZero. Acting as an authenticator is OFF by default. - Dashboard — After unlock, a landing page shows your security score and vault statistics at a glance. - Security Report — Password health analysis flags weak, reused, and old passwords with a composite 0–100 security score. - Contacts — See everyone you can write to encrypted, the keys you hold for them, and whether you have verified each one. Compare safety numbers to verify, retire a key the contact has stopped using, or remove a contact entirely. Removals are recorded so another device does not restore them on the next sync. - Side Panel — Open NodeZero as a persistent side panel (Chrome 114+) for a full-height view alongside your browsing. Toggle between popup and side panel in settings. ENCRYPTED EMAIL FOR GMAIL NodeZero encrypts the message BODY. Both sender and recipients must have NodeZero installed. Exactly what is and is not protected, because "encrypted email" is often claimed more broadly than it is true: - The message body is encrypted before it reaches Google, and Google stores only the ciphertext. It cannot read what you wrote. - Recipients (To, CC, BCC) are NOT protected. Gmail routes on them, so Google necessarily sees who you write to, and when, and how often. - The subject line is NOT sent. NodeZero replaces it with a fixed marker, "🔒 Encrypted message (NodeZero)", so no subject text reaches Google — and the recipient does not see one either. - The approximate SIZE of your message is visible, which reveals roughly how long it was. - The fact that you use NodeZero is visible to anyone who can see the message. - Attachments are NOT encrypted. NodeZero encrypts the message body only. Important, and easy to miss: you compose in Gmail's own window, and Gmail saves drafts to Google while you type. Those drafts are NOT encrypted. Encryption happens at the moment you send — so Google sees the text you are writing before that, and deleting the draft afterwards does not undo it. If a message must stay private from Google as you write it, do not compose it in Gmail. Writing without giving Gmail the draft: open NodeZero and choose "Write a private message". What this does, step by step: 1. You type in the extension's own panel. The text is held in the extension, never in a Gmail field, and is not written to disk. 2. When you press Send, NodeZero encrypts the body FIRST, inside the extension. 3. Only then does it go near Gmail: it opens a compose window, fills in the recipients and the placeholder subject, and pastes the ciphertext. 4. It reads the compose window back and compares it against what it encrypted. If they differ, it refuses to send and clears what it wrote. 5. It presses Send. Because the plaintext is never entered into a Gmail field, there is no unencrypted draft for Google to autosave. That is the difference from composing in Gmail's own window, where Google receives the text as you type it. What Google sees either way is the same list above — the recipients, the timing, the size, and the ciphertext. How to encrypt an email: right-click anywhere inside a Gmail compose window → NodeZero → Encrypt for recipients. NodeZero looks up every address in the To, CC, and BCC fields, encrypts the message body, and replaces it with ciphertext — all before the email leaves your browser. How to decrypt: right-click on a received encrypted message → NodeZero → Decrypt email. If you grant the optional Gmail host permission (prompted on first use), NodeZero will automatically decrypt incoming encrypted emails as you read them — no right-click needed. A "Decrypted by NodeZero" banner appears above each decrypted message. How you exchange keys: NodeZero has no directory and no server. To write to someone encrypted, you need their public key, and they need yours — so you swap "key cards". A key card is a short block of text carrying your public key. Send yours from a compose window (NodeZero → Share my key card), or let NodeZero open a pre-filled one for you when you write to someone it has no key for. When a card arrives in your inbox, NodeZero offers to add it to your contacts. You confirm before anything is stored. Verify who you are talking to: every contact has a safety number derived from both public keys. Compare it with them over any channel you already trust — in person, by phone — and mark the contact verified. Until you do, the key is marked unverified, and NodeZero says so rather than implying a check it has not made. If a contact's key later changes, NodeZero tells you and refuses to swap silently. POST-QUANTUM PROTECTION FOR THE MESSAGE BODY A copy of an encrypted email can be kept indefinitely, and confidentiality that is lost later cannot be restored by changing a key afterwards. That is the "harvest now, decrypt later" problem: someone stores the ciphertext today and opens it if a machine capable of breaking today's key exchange arrives. So the message BODY is wrapped under a hybrid of two key exchanges: ML-KEM-768 — the NIST post-quantum standard, FIPS 203, via the @noble/post-quantum library — and X25519. The design intent is that recovering the body requires breaking both, and there is no classical-only path in the product: the older classical-only message formats were removed, and decryption refuses any message that is not in the current hybrid format. Being exact, because "post-quantum" is claimed loosely and this claim is narrower than the phrase suggests: - It covers the message BODY. It does not cover ATTACHMENTS, which cannot be encrypted at all — so NodeZero blocks an encrypted send that carries one, rather than letting a file go out looking protected. - The SUBJECT is not encrypted either; it is replaced with a fixed marker, so nothing you typed is sent. - Recipients and the timing of your messages remain visible to Google. - Your identity and signatures are Ed25519 and are NOT post-quantum. A future quantum attacker could not read a body you sent today, but the identity layer is conventional. - FIPS 203 specifies ML-KEM. It does not specify the way NodeZero combines ML-KEM with X25519 — that combination is our own construction (HKDF-SHA256 over both shared secrets, bound to the ephemeral and recipient public keys and the ML-KEM ciphertext). It has not been reviewed by anyone outside this project, and neither has the rest of the extension. Under the hood: - A random content encryption key (CEK) encrypts the email body once with AES-256-GCM. - A fresh ephemeral X25519 keypair is generated per message. - For each recipient (To, CC, BCC), an ML-KEM-768 encapsulation and an X25519 key agreement are combined into one wrapping key that encrypts the CEK. The combination binds both shared secrets, both public keys and the post-quantum ciphertext, so neither half can be stripped or swapped. - No NodeZero server is contacted at any point. Recipient keys come from the contact book on your own device. Recipients with no key on file: encryption needs the recipient's public key, so NodeZero cannot encrypt to someone it has no key for. Before sending, it names those recipients and offers to encrypt for everyone it can while adding a one-line note telling the others why the message is unreadable to them, to drop them from the message, or to send in plaintext. Every recipient always receives the same body — NodeZero never sends one copy encrypted and another in the clear. If nobody on the message has a key, encryption is not offered at all, and NodeZero suggests sending them your key card instead. PAGE ACCESS — OFF BY DEFAULT NodeZero cannot read or change the websites you visit unless you switch it on. Three independent controls in Settings, all off to begin with: save the logins you type, record passkeys you create elsewhere, and act as a passkey. Until you enable one, NodeZero holds no host permission for other sites and injects no code into them — Chrome's own extension page will confirm this. (The extension itself still runs, as any extension does; what it lacks is access to your pages.) Turning them all off hands that access back. When NodeZero notices a login worth saving it marks the toolbar icon rather than covering the page, so it does not compete with your browser's own save prompt. The icon also changes colour while the vault is locked. SECURITY BY DESIGN - Your vault is never written to disk in the clear: what is stored is en