Chrome extension for ghostkey management

[sanity]

Summary

Create a Chrome extension to make ghostkeys more accessible to users. The extension enables secure storage, management, and use of ghostkeys for authentication to websites and Freenet contracts.

Background

Ghostkeys are anonymous, verifiable digital identities backed by donations. Currently users receive a PEM file after donating, but there's no convenient way to use it for authentication. A browser extension solves this by:

• Securely storing multiple ghostkeys with password/passkey encryption
• Providing a simple UI for key selection
• Exposing a website API for authentication requests
• Preventing signature replay attacks via structured auth requests

Implementation Progress

Phase 1: WASM Extensions (Complete)

Added signing/verification functions to gkwasm:

• Created gklib/src/signed_message.rs with SignedMessage struct
• Added wasm_sign_message() and wasm_verify_signed_message() to gkwasm
• Updated CLI to import from gklib (path dependency for local dev)

Phase 2: Extension Scaffolding (Complete)

Created extension/ directory with:

extension/
├── manifest.json              # Manifest V3
├── package.json               # TypeScript + webpack
├── src/
│   ├── background/
│   │   ├── index.ts           # Service worker
│   │   ├── storage-service.ts # Encrypted vault (AES-256-GCM)
│   │   └── crypto-service.ts  # WASM wrapper
│   ├── popup/popup.ts         # Key selector UI
│   ├── options/options.ts     # Key management
│   ├── content/content.ts     # Website bridge
│   └── shared/
│       ├── types.ts
│       ├── messages.ts
│       └── encryption.ts      # Web Crypto (PBKDF2 + AES-GCM)
└── wasm/                      # Copied from hugo-site build

Remaining Work

Icons

• Need 16/48/128px PNG icons for the extension
• Should match Freenet branding

Passkey Support

• Add WebAuthn PRF extension for vault unlock
• Alternative to password-based encryption

User Confirmation Flow

• Currently auto-approves auth requests if unlocked
• Need popup confirmation showing origin, purpose, contract address

Testing

• Load extension in Chrome and test full flow
• Test with River UI integration

Website Integration API

The extension injects window.freenetGhostkey with:

// For web apps (River UI, etc.)
freenetGhostkey.authenticate({
  challenge: crypto.randomUUID(),
  purpose: "Join room #general"
}) → Promise<{signedAuth: string, certificate: string}>

// For Freenet contracts  
freenetGhostkey.authenticateContract({
  contractAddress: "abc123...",
  challenge: crypto.randomUUID(),
  purpose: "Subscribe to updates"
}) → Promise<{signedAuth: string, certificate: string}>

Security Design

• Structured auth requests: Signatures are bound to origin + contract + timestamp, preventing replay attacks
• Origin validation: Content script validates page origin matches request
• Encrypted storage: Keys encrypted with AES-256-GCM using PBKDF2-derived key (600k iterations)
• No arbitrary signing: Websites cannot get signatures on arbitrary content

Build Instructions

cd extension
npm install
npm run build
# Load extension/dist/ in Chrome via chrome://extensions/

Related

• Ghostkey donation flow: https://freenet.org/ghostkey/create/
• Blind signature implementation: RFC 9474

[AI-assisted - Claude]

[sanity]

Issue Priority Assessment

Generated: 2026-02-18T22:11:51.146306577+00:00
Issue hash: b97ee43d

Value Assessment

The ghostkey extension directly bridges the donation-generated credentials to the browser, so shipping it greatly improves the experience for anyone who has given—even the low‑barrier $1 tier described on the “Get Your Ghost Key” page (hugo-site/content/ghostkey/create/_index.md:1)—by keeping private certificates encrypted with PBKDF2/AES-256-GCM and making signing available without copying PEM files manually (rust/browser-extension/src/background/storage-service.ts:1). Without a polished vault interface, many users simply stash their PEM blobs in unrelated tools and never get to use the verified identity, so finishing the extension is the only way to deliver the promised secure, multi-key management and structured auth flow described in the Chrome extension’s README (rust/browser-extension/README.md:1).

Strategically, the extension is a natural continuation of the existing Rust/WASM work: gkwasm already exposes wasm_sign_message/wasm_verify_signed_message for signing canonical auth payloads (rust/gkwasm/src/lib.rs:305), and the background crypto service wires those bindings into structured requests (rust/browser-extension/src/background/crypto-service.ts:1). Tying that into the River UI and other pages via the injected window.freenetGhostkey API (rust/browser-extension/src/content/content.ts:1) delivers the same “anonymous, verifiable digital identity” promise that the rest of the Hugo site advertises, so the issue advances the core mission of making ghostkeys practical beyond the CLI.

Finishing the extension is also a blocking concern: the content script already establishes the message bridge (content.ts:1), but the repository still lacks icons, a confirmation UI, passkey unlock, and a polished release build, so nothing can be shipped to users today (rust/browser-extension/README.md:1). There is no obvious time urgency, but because this feature is the critical path for River/Freenet contracts to authenticate with ghostkeys, prioritizing it now prevents further work—like River integration or contract testing—from depending on an unpublished solution.

Cost Assessment

Completing Issue #13 means modifying nearly every extension subsystem: the service worker already routes every UI action through handleMessage and would need new branches for encrypted vault unlock, confirmation prompts, and WebAuthn flows (rust/browser-extension/src/background/index.ts:23-121), while the vault itself must persist passkey metadata and new unlock pathways on top of the existing password logic (rust/browser-extension/src/background/storage-service.ts:45-253). The popup and options UIs only talk to the background via the password-based UNLOCK_VAULT message today, so both pages have to gain new controls (a passkey toggle/prompt, success state, and a request confirmation UI) plus surfaces for key import/export/selection that continue to rely on the message broker stack (rust/browser-extension/src/options/options.ts:1-235, rust/browser-extension/src/popup/popup.ts:1-145). The content script and injected window.freenetGhostkey API already funnel every origin request through PAGE_AUTH_REQUEST, and the manifest still points at missing static/icons/* assets for both the action and extension icons (rust/browser-extension/src/content/content.ts:17-135, rust/browser-extension/manifest.json:20-55), so shipping usable branding also requires adding those PNGs into the build.

Passkey support multiplies the complexity: there is already a UNLOCK_VAULT_PASSKEY message type and the stored vault schema can hold unlockMethod and passkeyCredentialId, but no code handles those paths yet (rust/browser-extension/src/shared/messages.ts:4-110, rust/browser-extension/src/shared/types.ts:4-74). Extending the storage service to derive the AES-GCM key from a WebAuthn PRF certificate instead of PBKDF2 (or supporting both) means plumbing navigator.credentials calls into the service worker, persisting the credential ID, and reacting to lock/unlock events without exposing raw secrets (rust/browser-extension/src/background/storage-service.ts:45-253, rust/browser-extension/src/shared/encryption.ts:1-82). The background will have to coordinate these messages with the popup/options UI and maybe a dedicated confirmation surface, so the work isn’t just about calling a WebAuthn helper but ensuring the new asynchronous flow updates UI state, caches derived keys safely, and stays compatible with the existing key import/export lifecycle.

Risk is concentrated around the auth flow: handlePageAuthRequest currently auto-approves every request if the vault is unlocked (rust/browser-extension/src/background/index.ts:103-121), so user confirmation needs a reliable prompt that cannot be bypassed, the origin validation in the content script must stay in sync with what the popup displays, and the injected API (window.freenetGhostkey) must continue to report errors clearly so River UI or other pages can detect denials (rust/browser-extension/src/content/content.ts:17-135). Any mistakes in the confirmation dialog, state machine, or message ordering could expose active keys to web pages, and extending the vault to multiple unlock methods raises the stakes for storing/restoring the derived key correctly.

Testing will primarily be manual because the extension bundles WebAssembly and Chrome APIs; the npm run build pipeline (with the copy-wasm hook that pulls artifacts from hugo-site/static/wasm) must keep running so the TLS signing functions remain available (rust/browser-extension/package.json:1-22). Verification therefore involves building the extension, loading dist/ in Chrome, and exercising unlock/passkey paths plus the injected freenetGhostkey.authenticate* calls to ensure they surface confirmation dialogs and return signed auth bundles (rust/browser-extension/src/content/content.ts:67-135). River UI integration and replay protections also need live validation in a browser session because the signature scheme and structured auth JSON all live inside the WebAssembly module, so regression testing is heavy on end-to-end (unlock → confirm → native page call) scenarios.

---

Generated by issue-prioritizer