DEV Community: MARUCIE

The Password Manager That Talks to AI: Building an MCP Credential Gateway

MARUCIE — Mon, 23 Mar 2026 11:37:58 +0000

Your AI agent needs 50 API keys. You have 50 .env files. Something has to give.

The Problem Nobody Talks About

Every developer building with AI agents hits the same wall. Your agent needs to call the OpenAI API. Then Stripe. Then AWS. Then GitHub. Before you know it, you are managing 50+ API keys across a dozen projects, scattered in plaintext .env files, pasted into chat windows, or hardcoded into config objects you swear you will clean up later.

This is not a minor inconvenience. It is an architectural failure mode:

Plaintext secrets in .env files get committed to git, leaked in screenshots, and copied across machines without audit trails.
No revocation granularity. When an agent misbehaves, you revoke the key manually -- which breaks every other agent using the same key.
No policy enforcement. Nothing prevents your coding assistant from making a $500 API call at 3 AM because it decided to "try something."
No audit trail. When something goes wrong, you have no idea which agent accessed which credential, when, or why.

We built Auth Box to solve this. It is a zero-knowledge password manager -- like 1Password, but with a seed phrase instead of a master account, and a built-in MCP server that gives AI agents controlled, auditable access to credentials.

What is MCP?

Model Context Protocol (MCP) is Anthropic's open standard for connecting AI models to external tools and data sources. Think of it as USB-C for AI integrations: a single protocol that any AI assistant can use to interact with any external system.

An MCP server exposes tools -- structured function calls that an AI model can invoke. The model sees a tool's name, description, and input schema, then decides when and how to call it. The key insight is that the model never sees the implementation details. It just knows "I can call get_credential to get an API key."

Auth Box implements an MCP server that exposes three tools:

Tool	Purpose
`get_credential`	Retrieve a credential from the vault, filtered by policy
`proxy_authenticated_request`	Make an HTTP request with credentials injected server-side
`list_available_services`	Discover what credentials are available

The critical one is proxy_authenticated_request. Instead of handing raw API keys to the agent, Auth Box injects the credential into the HTTP request on the server side. The agent says "call the OpenAI API with this prompt" -- it never sees the key itself.

Architecture: How the Gateway Works

The MCP gateway lives in the @authbox/mcp-protocol package and runs as a WebSocket server. Here is the full flow:

AI Agent (Claude, GPT, etc.)
    |
    | WebSocket + delegation key
    v
┌─────────────────────────────────────┐
│  AuthBoxMCPServer (ws://port:19876) │
│                                     │
│  1. Authenticate (verify API key)   │
│  2. Load agent policies             │
│  3. Evaluate PolicyEngine           │
│  4. Execute tool (or deny)          │
│  5. Log audit event (hash-chain)    │
└─────────────────┬───────────────────┘
                  |
                  v
┌─────────────────────────────────────┐
│  VaultBridge (client-side decrypt)  │
│  - getCredential()                  │
│  - proxyRequest()                   │
│  - logAudit()                       │
└─────────────────────────────────────┘

The server speaks JSON-RPC 2.0 over WebSocket, implementing the MCP initialize, tools/list, and tools/call methods. Let me walk through each layer.

1. Per-Agent Delegation Keys (HD Derivation)

Auth Box uses a BIP-39 seed phrase (24 words) as the sole recovery mechanism. From this seed, all keys are derived deterministically using HD (Hierarchical Deterministic) derivation -- the same proven model Bitcoin wallets use:

seed phrase (24 words)
  -> master key (PBKDF2-HMAC-SHA512)
    -> m/auth_box'/vault'/0'    -> vault encryption key
    -> m/auth_box'/sync'/0'     -> sync encryption key
    -> m/auth_box'/agent'/0'    -> agent delegation root
    -> m/auth_box'/agent'/<n>'  -> per-agent sub-key (revocable)

Each AI agent gets its own derived key at index <n>. Revoking one agent's access does not affect any other agent -- you just invalidate that specific derivation index. No shared secrets, no blast radius.

2. The Policy Engine

Every tool call passes through the PolicyEngine before execution. Policies are stacked by priority and evaluated in order. All policies must pass for the request to succeed.

Five policy types are supported:

// Policy types evaluated on every credential access
enum PolicyType {
  ItemScope       = 'item_scope',    // WHICH credentials the agent can access
  ActionPermission = 'action_perm',  // WHAT it can do (read, use, proxy)
  RateLimit       = 'rate_limit',    // HOW OFTEN (e.g., 100 requests per 300s)
  TimeWindow      = 'time_window',   // WHEN (e.g., weekdays 9AM-6PM only)
  StepUp          = 'step_up',       // REQUIRE human approval for sensitive ops
}

A real-world policy configuration might look like this:

// Allow the coding assistant to read LLM keys, but not payment credentials.
// Rate limit to 100 requests per 5 minutes. Require approval for proxy requests.
const policies: AgentPolicy[] = [
  {
    id: 'scope-llm-only',
    agentId: 'claude-coding-agent',
    policyType: 'item_scope',
    rules: { allowedItemTypes: ['api_key'] },
    priority: 100,
    enabled: true,
  },
  {
    id: 'action-read-only',
    agentId: 'claude-coding-agent',
    policyType: 'action_perm',
    rules: { allowedActions: ['read', 'proxy'] },
    priority: 90,
    enabled: true,
  },
  {
    id: 'rate-limit-100',
    agentId: 'claude-coding-agent',
    policyType: 'rate_limit',
    rules: { maxRequests: 100, windowSeconds: 300 },
    priority: 80,
    enabled: true,
  },
  {
    id: 'business-hours',
    agentId: 'claude-coding-agent',
    policyType: 'time_window',
    rules: {
      allowedHours: { start: 9, end: 18 },
      allowedDays: [1, 2, 3, 4, 5],  // Mon-Fri
    },
    priority: 70,
    enabled: true,
  },
];

3. Step-Up Approval

For sensitive operations, the step_up policy type pauses execution and sends a notification to the user (via the browser extension or desktop app). The agent's request blocks until the human approves or denies it, with a configurable timeout (default: 60 seconds).

This is the "are you sure?" dialog for AI agents -- except it is enforced at the protocol level, not the UI level. The agent cannot bypass it.

4. Audit Trail with Hash-Chain Integrity

Every credential access -- allowed or denied -- generates a structured audit event:

interface AuditEvent {
  actorType: 'agent';
  actorId: string;        // which agent
  userId: string;         // which user's vault
  action: string;         // get_credential, proxy_request, list_services
  resourceType: string;   // credential
  resourceId: string;     // service name
  decision: 'allowed' | 'denied' | 'error';
  metadata: {
    reason: string;       // why the decision was made
    policies: string[];   // which policies were evaluated
  };
}

Events are chained with hash-chain integrity -- each event includes the hash of the previous event, making retroactive tampering detectable. If someone modifies an old audit record, every subsequent hash breaks.

The AI Infrastructure Hub

Managing credentials for AI agents is not just about security -- it is also about operational sanity. Auth Box includes a dedicated AI Infrastructure Hub that handles the lifecycle of API keys for 70+ providers:

Drag-and-drop .env import. Drop a .env file into the hub and Auth Box auto-classifies each key by provider (OpenAI, Anthropic, AWS, Stripe, etc.) using pattern matching on key prefixes and known formats.

One-click health checks. For supported providers, Auth Box can verify that a key is still valid by making a minimal API call (e.g., listing models for OpenAI, describing regions for AWS). No more deploying to production only to discover your key expired last Tuesday.

Categorized view. Keys are organized by category -- LLM, Cloud, Payment, Analytics, Communication -- so you can see your entire AI infrastructure at a glance instead of grepping through 30 .env files.

Code Example: Connecting an Agent

Here is how an AI agent connects to Auth Box and retrieves a credential:

import WebSocket from 'ws';

const ws = new WebSocket('ws://localhost:19876?api_key=YOUR_DELEGATION_KEY');

ws.on('open', () => {
  // 1. Initialize the MCP session
  ws.send(JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'initialize',
    params: {
      protocolVersion: '2024-11-05',
      clientInfo: { name: 'my-agent', version: '1.0.0' },
    },
  }));

  // 2. List available tools
  ws.send(JSON.stringify({
    jsonrpc: '2.0',
    id: 2,
    method: 'tools/list',
  }));

  // 3. Retrieve a credential (policy-gated)
  ws.send(JSON.stringify({
    jsonrpc: '2.0',
    id: 3,
    method: 'tools/call',
    params: {
      name: 'get_credential',
      arguments: { service_name: 'OpenAI', fields: ['api_key'] },
    },
  }));

  // 4. Or better: proxy a request (agent never sees the key)
  ws.send(JSON.stringify({
    jsonrpc: '2.0',
    id: 4,
    method: 'tools/call',
    params: {
      name: 'proxy_authenticated_request',
      arguments: {
        service_name: 'OpenAI',
        method: 'POST',
        url: 'https://api.openai.com/v1/chat/completions',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
          model: 'gpt-4o',
          messages: [{ role: 'user', content: 'Hello' }],
        }),
      },
    },
  }));
});

ws.on('message', (data) => {
  const response = JSON.parse(data.toString());
  console.log('Response:', JSON.stringify(response, null, 2));
});

The proxy_authenticated_request tool is the preferred pattern. The agent describes what it wants to do ("POST to the OpenAI completions endpoint with this payload"), and Auth Box handles authentication. The API key never appears in the agent's context window, which eliminates an entire class of prompt injection attacks where a malicious prompt tricks the agent into leaking its credentials.

Why This Matters

The current state of agent credential management is where web authentication was in 2005 -- passwords in plaintext databases, no OAuth, no token rotation, no audit trails. We are building increasingly autonomous systems and handing them the keys to our infrastructure with zero access control.

Auth Box takes a different position: agent credentials, not agent chaos.

Zero-knowledge. The server stores only encrypted blobs. It cannot decrypt your vault, your credentials, or your agent keys.
Survivable. Auth Box uses a 24-word seed phrase. If we disappear tomorrow, your credentials still work. No vendor lock-in.
Granular delegation. Each agent gets its own derived key with its own policy set. Revoke one without touching the others.
Auditable. Every access decision is logged with hash-chain integrity. When your agent does something unexpected at 3 AM, you can trace exactly what happened.
MCP-native. Any AI assistant that speaks MCP can connect. Claude, GPT, Gemini, or your custom agent -- one protocol, one gateway.

Try It Yourself

Auth Box is open source (MIT).

git clone https://github.com/MARUCIE/authbox.git
cd authbox
pnpm install
make dev-full    # Starts Postgres + Redis + API + Web

Web app: http://localhost:3010
MCP server: ws://localhost:19876
API: http://localhost:4010

The MCP gateway package is at packages/mcp-protocol/. The policy engine, tool definitions, and WebSocket server are each under 300 lines. Read the source -- there is no magic, just careful engineering.

GitHub: github.com/MARUCIE/authbox

Maurice | maurice_wen@proton.me

You Trust Your Crypto to 24 Words. Why Not Your Passwords?

MARUCIE — Mon, 23 Mar 2026 11:34:06 +0000

Your Bitcoin wallet can survive the apocalypse. Your 1Password vault cannot. Here is how to fix that.

The Vendor Lock-In Nobody Talks About

You have a 1Password vault with 400 entries. Or maybe a Bitwarden export sitting in a JSON file somewhere. Either way, you are one corporate bankruptcy away from losing access to your entire digital life.

This is not hypothetical. LastPass was breached in 2022, and millions of encrypted vaults were exfiltrated. The company still exists, but the trust is gone. Now consider: what if they had shut down instead? Those vaults are encrypted with keys derived from your master password -- but the derivation parameters, the encryption format, the vault structure? All proprietary. All dependent on LastPass code existing somewhere.

The password manager industry has a dirty secret: your vault is only as durable as the company that made it. The encryption is solid, but the format is a single point of failure.

Meanwhile, Bitcoin holders sleep soundly knowing that their entire fortune lives in 24 words, and any BIP-39-compatible wallet -- from any vendor, written in any language, on any device -- can restore it.

Why don't password managers work the same way?

How Bitcoin Solved This Problem in 2013

BIP-39 (Bitcoin Improvement Proposal 39) introduced mnemonic seed phrases. The entire system is elegant in its simplicity:

Generate 256 bits of entropy
Map it to 24 human-readable words from a standardized 2048-word list
Convert words back to a seed using PBKDF2-HMAC-SHA512
Derive all keys deterministically from that seed

The critical insight: the derivation is a pure function. Same input, same output, every time, on every device, with every implementation. No server. No account. No vendor.

abandon ability able about above absent absorb abstract absurd abuse access accident
  |
  v
PBKDF2-HMAC-SHA512 (2048 iterations, salt = "mnemonic" + passphrase)
  |
  v
512-bit master seed
  |
  v
HMAC-SHA512 with domain-specific keys
  |
  v
m/44'/0'/0'/0/0  -> Bitcoin address #1
m/44'/0'/0'/0/1  -> Bitcoin address #2
m/44'/60'/0'/0/0 -> Ethereum address #1
... infinite deterministic derivation

Twelve years later, every hardware wallet, software wallet, and exchange supports this standard. You can write your seed phrase on a steel plate, bury it, and recover your funds twenty years later with software that does not exist yet. That is the power of a deterministic, vendor-neutral standard.

Applying HD Key Derivation to Password Management

Auth Box takes this exact model and applies it to passwords and credentials. The derivation tree looks like this:

seed phrase (24 words, BIP-39)
  |
  v
PBKDF2-HMAC-SHA512 (2048 rounds)
  |
  v
master seed (512 bits)
  |
  v
HMAC-SHA512("authbox seed", master_seed)
  |
  +-- m/ABX'/vault'/0'   -> vault encryption key (AES-256-GCM)
  +-- m/ABX'/sync'/0'    -> sync encryption key
  +-- m/ABX'/auth'/0'    -> authentication signing key (Ed25519)
  +-- m/ABX'/agent'/0'   -> agent delegation root key
  +-- m/ABX'/agent'/1'   -> per-agent sub-key (revocable)
  +-- m/ABX'/derive'/n'  -> deterministic password for site n

Each branch serves a distinct purpose, and the hardened derivation (note the ' apostrophes) ensures that compromising one branch cannot reveal any other. This is the same security property that prevents someone who knows your Bitcoin address from deriving your Ethereum keys.

The Implementation

The core is roughly 60 lines of TypeScript built on @noble/hashes (a well-audited, pure-JS crypto library):

// BIP-39 mnemonic -> 512-bit seed
function mnemonicToSeed(mnemonic: string, passphrase: string = ''): Uint8Array {
  const mnemonicBytes = encode(mnemonic.normalize('NFKD'));
  const salt = encode('mnemonic' + passphrase.normalize('NFKD'));
  return pbkdf2(sha512, mnemonicBytes, salt, { c: 2048, dkLen: 64 });
}

// HD key derivation with Auth Box custom purpose
function deriveKey(seed: Uint8Array, purpose: KeyPurpose, index: number = 0): Uint8Array {
  const master = masterKeyFromSeed(seed);         // HMAC-SHA512("authbox seed", seed)
  const purposeNode = deriveHardenedChild(master, AUTH_BOX_PURPOSE); // "ABX\0"
  const typeNode = deriveHardenedChild(purposeNode, purpose);
  const leaf = deriveHardenedChild(typeNode, index);
  return leaf.key; // 32-byte derived key
}

The AUTH_BOX_PURPOSE constant (0x41425800, which is "ABX\0" as a uint32) acts as a namespace separator, ensuring Auth Box derivation paths never collide with Bitcoin (purpose 44') or Ethereum (purpose 60') even if derived from the same seed phrase.

Deterministic Passwords: The Radical Part

Here is where it gets interesting. Traditional password managers store your passwords. Auth Box can derive them:

function derivePassword(seed: Uint8Array, site: string, options = {}): string {
  // 1. Hash the site name to get a deterministic index
  const siteHash = sha256(site.toLowerCase() + '\0' + counter);
  const siteIndex = uint32(siteHash);

  // 2. Derive site-specific key material via HD path
  const siteKey = deriveKey(seed, KeyPurpose.DERIVE, siteIndex);

  // 3. Expand to password characters
  const expanded = hmac(sha512, siteKey, 'password:' + site + ':' + counter);

  // 4. Map bytes to character set (a-z, A-Z, 0-9, symbols)
  return mapToCharset(expanded, charset, length);
}

The result: derivePassword(seed, "github.com") always produces the same 20-character password. No vault needed. No sync needed. No server needed. If you have your 24 words and you know the site name, you have the password.

The counter parameter handles the inevitable "please change your password" scenario -- increment it from 0 to 1, and you get a completely different password for the same site.

The Unstoppable Promise

Auth Box makes a guarantee that no traditional password manager can:

Even if Auth Box ceases to exist -- the company, the servers, the code, the domain -- your 24 words will still recover every password.

This works across five degradation levels:

Level	Scenario	What Still Works
0	Everything online	Full app: web UI, sync, AI gateway, audit
1	Servers go down	Local vault + Chrome extension + deterministic passwords
2	Company disappears	Arweave recovery: fetch encrypted blob, decrypt with seed
3	Device lost	Seed phrase + Arweave = full restore on a new device
4	Everything gone	Seed phrase alone = derive passwords with any HMAC calculator

Level 4 is the nuclear option. No internet, no vault, no software. Just 24 words and the publicly documented derivation algorithm. A developer could reimplement the password derivation function in an afternoon using any language with HMAC-SHA512 support.

Arweave: Your Vault Outlives Your Vendor

For the full vault (not just derived passwords, but stored credentials, notes, API keys), Auth Box archives encrypted snapshots to Arweave -- a permanent, decentralized storage network. One-time payment of roughly $0.005/KB. No subscriptions. No renewals. The data persists for 200+ years by design.

The encrypted blob on Arweave is useless without your seed phrase. Arweave nodes see only ciphertext. But with your 24 words, you derive the vault key, fetch the blob, decrypt locally, and recover everything.

Recovery flow:
  24 words -> derive vault_key (m/ABX'/vault'/0')
            -> fetch encrypted blob from Arweave
            -> AES-256-GCM decrypt locally
            -> full vault restored

Auth Box vs. LessPass: Stateless Password Derivation Compared

LessPass pioneered stateless password derivation in 2016. Auth Box builds on that idea but extends it significantly:

Feature	LessPass	Auth Box
Stateless password derivation	Yes (master password + site + username)	Yes (seed phrase + site + counter)
Recovery mechanism	Remember master password	24-word seed phrase (BIP-39 standard)
Full vault storage	No (stateless only)	Yes (AES-256-GCM encrypted vault)
Permanent backup	No	Arweave on-chain archive
AI agent delegation	No	Per-agent derived keys with policy engine
Key hierarchy	Flat (single master password)	HD tree (vault/sync/auth/agent/derive branches)
Key revocation	Change master password (changes everything)	Revoke individual agent keys by index
Import from other managers	No	13 sources (1Password, Chrome, Bitwarden, etc.)
Open standard for derivation	Custom (PBKDF2 + site params)	BIP-39 + BIP-32-style HD derivation

The key difference: LessPass is only stateless derivation. If a site requires you to store a note, an API key, or a TOTP secret, LessPass cannot help. Auth Box gives you both modes -- deterministic derivation for passwords, plus a full encrypted vault for everything else -- and both are recoverable from the same 24 words.

Try It Yourself

Auth Box is open source under the MIT license.

git clone https://github.com/MARUCIE/authbox.git
cd authbox
pnpm install
make dev

The web app starts at http://localhost:3010. Create a vault, write down your 24 words, and try the deterministic password derivation. Then delete the vault and restore it from the seed phrase. The passwords come back identical.

The cryptographic core lives in packages/crypto/src/seed.ts -- about 340 lines of TypeScript with no dependencies beyond @noble/hashes. Read it. Audit it. Reimplement it in Rust or Go or Python. That is the whole point: the derivation algorithm is simple enough to verify, standard enough to reimplement, and deterministic enough to trust with your passwords.

Your crypto lives in 24 words. Your passwords should too.

GitHub: https://github.com/MARUCIE/authbox

Maurice | maurice_wen@proton.me

Your Password Never Leaves Your Device: Implementing SRP-6a in a Zero-Knowledge Password Manager

MARUCIE — Mon, 23 Mar 2026 11:32:47 +0000

Every major password breach follows the same script: attackers compromise a server, dump the password database, and crack hashes offline. LinkedIn (2012, 117M SHA-1 hashes). LastPass (2022, encrypted vaults exfiltrated). The root cause is always the same -- the server had something worth stealing.

What if the server never received the password at all?

That is the premise behind Auth Box, an open-source zero-knowledge password manager. Its authentication layer uses SRP-6a (Secure Remote Password, revision 6a), a protocol where the client proves it knows the password without ever transmitting it. The server stores only a mathematical derivative called a verifier -- useless without the original password.

This post walks through the actual implementation: TypeScript on the client, Go on the server, and the security decisions that matter.

Why Traditional Password Auth Is Broken

The standard model looks like this:

User types password
Client sends password (or its hash) to server over TLS
Server hashes and compares against stored hash (bcrypt, argon2, etc.)
Server returns a session token

The problem is structural. The password -- or enough information to reconstruct it -- crosses the wire and exists in server memory, even if only for milliseconds. This creates attack surfaces at every layer:

TLS termination: corporate proxies, CDN edge nodes, or compromised load balancers can intercept plaintext.
Server-side logging: an accidental console.log(req.body) or a verbose WAF leaks credentials into log stores.
Database breaches: even with argon2id, offline attackers can crack weak passwords given enough GPU time.
Credential stuffing: once a password hash leaks from one service, it can be tested against every other service the user has an account with.

SRP eliminates the first two entirely. The password never leaves the client. The server never sees it, not even transiently. For the third attack surface, even if the verifier database is stolen, an attacker cannot reverse it into the original password or use it to impersonate the client -- the verifier alone is not sufficient to complete authentication.

How SRP-6a Works

SRP (Secure Remote Password) was designed by Tom Wu at Stanford in 1998. Version 6a, specified in RFC 5054, fixes subtle vulnerabilities in earlier revisions. The key properties:

Zero-knowledge: The server never learns the password. Not during registration, not during login, not ever.
Mutual authentication: The client proves it knows the password, AND the server proves it has the correct verifier. A MITM server cannot fake the handshake.
No password-equivalent stored on the server: The verifier v is a one-way derivation. Stealing it does not let an attacker log in.
Resistance to offline dictionary attacks: An eavesdropper who captures the full handshake transcript cannot mount an offline attack without the verifier.

The protocol works in two phases: registration and login.

Registration

The client computes a verifier from the password and sends it to the server. The password itself never crosses the wire.

x = H(salt || H(email || ":" || password))
v = g^x mod N
Client sends: (salt, v) to server
Server stores: (salt, v) per user

Here, N is a large safe prime and g is a generator of the multiplicative group modulo N. Auth Box uses the 2048-bit group from RFC 5054 (Group 14).

Login (the handshake)

This is a four-message exchange where both sides independently derive the same session key without revealing the password:

Step 1: Client generates ephemeral keypair
        a = random, A = g^a mod N
        Client sends: (email, A) to server

Step 2: Server looks up (salt, v) for email
        b = random, B = k*v + g^b mod N
        Server sends: (salt, B) to client

Step 3: Both sides compute the shared secret S
        Client: S = (B - k * g^x) ^ (a + u*x) mod N
        Server: S = (A * v^u) ^ b mod N
        Both derive: K = H(S)

Step 4: Mutual proof
        Client sends: M1 = H(A || B || K)
        Server verifies M1, responds: M2 = H(A || M1 || K)
        Client verifies M2

The multiplier k = H(N || PAD(g)) and scrambling parameter u = H(PAD(A) || PAD(B)) are the "6a" additions that prevent two-for-one guessing attacks and other weaknesses in earlier SRP versions.

The Implementation

Shared Constants: RFC 5054 Group Parameters

Both client and server must use identical group parameters. We use the 2048-bit prime from RFC 5054 Appendix A:

TypeScript (client):

// RFC 5054, 2048-bit group 14
const N_HEX =
  'AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56050' +
  'A37329CBB4A099ED8193E0757767A13DD52312AB4B03310DCD7F48A9DA04FD50' +
  // ... (256 bytes total)
  '94B5C803D89F7AE435DE236D525F54759B65E372FCD68EF20FA7111F9E4AFF73';

const N = BigInt('0x' + N_HEX);
const g = 2n;

Go (server):

srpN, _ = new(big.Int).SetString(
    "AC6BDB41324A9A9BF166DE5E1389582FAF72B6651987EE07FC3192943DB56050"+
    // ... same 2048-bit prime
    "94B5C803D89F7AE435DE236D525F54759B65E372FCD68EF20FA7111F9E4AFF73", 16)

srpG = big.NewInt(2)
srpK = computeK(srpN, srpG)  // k = H(N || PAD(g))

The k multiplier is precomputed at init time since N and g are fixed.

Client Side: TypeScript with Native BigInt

The client implementation lives in @authbox/crypto and uses @noble/hashes for SHA-256. No WebAssembly, no heavy dependencies -- just native BigInt arithmetic.

Modular exponentiation (the workhorse of SRP):

function modPow(base: bigint, exp: bigint, mod: bigint): bigint {
  let result = 1n;
  base = ((base % mod) + mod) % mod;
  while (exp > 0n) {
    if (exp & 1n) {
      result = (result * base) % mod;
    }
    exp >>= 1n;
    base = (base * base) % mod;
  }
  return result;
}

Registration -- generate the verifier:

export async function srpGenerateVerifier(
  email: string, password: string, salt: Uint8Array,
): Promise<{ salt: Uint8Array; verifier: Uint8Array }> {
  const x = computeX(email, password, salt);
  const verifier = modPow(g, x, N);
  return {
    salt: new Uint8Array(salt),
    verifier: bigintToBytes(verifier, 256), // pad to N's byte length
  };
}

Login step 1 -- generate ephemeral keypair with safety check:

export async function srpClientInit(): Promise<SRPClientState> {
  let a: bigint;
  let A: bigint;
  do {
    const aBytes = crypto.getRandomValues(new Uint8Array(32));
    a = bytesToBigint(aBytes);
    A = modPow(g, a, N);
  } while (A === 0n); // SRP safety: A mod N must not be 0
  return {
    ephemeralSecret: bigintToBytes(a, 32),
    ephemeralPublic: bigintToBytes(A, 256),
  };
}

Login step 2 -- compute the proof:

export async function srpClientVerify(
  state: SRPClientState, email: string, password: string,
  salt: Uint8Array, serverPublicB: Uint8Array,
): Promise<{ clientProof: Uint8Array; sessionKey: Uint8Array }> {
  const a = bytesToBigint(state.ephemeralSecret);
  const A = bytesToBigint(state.ephemeralPublic);
  const B = bytesToBigint(serverPublicB);

  if (B % N === 0n) throw new Error('SRP: invalid server public key');

  const u = computeU(A, B);
  if (u === 0n) throw new Error('SRP: scrambling parameter u is zero');

  const x = computeX(email, password, salt);
  const k = computeK();

  // S = (B - k * g^x) ^ (a + u*x) mod N
  const gx = modPow(g, x, N);
  const kgx = (k * gx) % N;
  const base = ((B - kgx) % N + N) % N;  // ensure non-negative
  const S = modPow(base, a + u * x, N);

  const sessionKey = hashSHA256(bigintToBytes(S, 256));
  const clientProof = hashSHA256(
    bigintToBytes(A, 256), bigintToBytes(B, 256), sessionKey,
  );
  return { clientProof, sessionKey };
}

Server Side: Go with crypto/rand

The server creates a session from the stored verifier and verifies the client's proof.

Session init -- compute B:

func NewSRPServer(verifier []byte) (*SRPServer, error) {
    v := new(big.Int).SetBytes(verifier)
    if v.Sign() == 0 {
        return nil, errors.New("srp: zero verifier")
    }

    b, err := randBigInt(256) // 256 bits of entropy from crypto/rand
    if err != nil {
        return nil, err
    }

    // B = k*v + g^b mod N
    kv := new(big.Int).Mul(srpK, v)
    gb := new(big.Int).Exp(srpG, b, srpN)
    B := new(big.Int).Add(kv, gb)
    B.Mod(B, srpN)

    if B.Sign() == 0 {
        return nil, errors.New("srp: B is zero")
    }
    return &SRPServer{verifier: v, b: b, B: B}, nil
}

Proof verification -- the critical code path:

func (s *SRPServer) VerifyProof(clientA, clientM1 []byte) ([]byte, error) {
    A := new(big.Int).SetBytes(clientA)

    // Safety: A mod N != 0
    if new(big.Int).Mod(A, srpN).Sign() == 0 {
        return nil, errors.New("srp: A mod N is zero")
    }

    u := computeU(A, s.B)
    if u.Sign() == 0 {
        return nil, errors.New("srp: u is zero")
    }

    // S = (A * v^u)^b mod N
    vu := new(big.Int).Exp(s.verifier, u, srpN)
    avu := new(big.Int).Mul(A, vu)
    avu.Mod(avu, srpN)
    S := new(big.Int).Exp(avu, s.b, srpN)

    nLen := len(srpN.Bytes())
    K := hashBytes(padTo(S, nLen))

    expectedM1 := hashBytes(padTo(A, nLen), padTo(s.B, nLen), K)

    if !constantTimeEqual(expectedM1, clientM1) {
        return nil, errors.New("srp: client proof invalid")
    }

    // Mutual auth: M2 = H(A | M1 | K)
    M2 := hashBytes(padTo(A, nLen), clientM1, K)
    return M2, nil
}

The Full Login Flow (HTTP level)

The login is a two-round-trip exchange:

POST /api/auth/login/init     { email, clientPublicA }
                           --> { srpSalt, serverPublicB }

POST /api/auth/login/verify   { email, clientPublicA, clientProofM1 }
                           --> { sessionToken, serverProofM2, encryptedVaultKey }

The client verifies M2 locally. If the server is an impersonator, M2 will not match and the client aborts. Mutual authentication complete.

Security Considerations

Getting the math right is necessary but not sufficient. Here are the implementation details that prevent real-world attacks:

1. Constant-Time Comparison

Comparing M1 proof bytes must be constant-time to prevent timing side-channels:

func constantTimeEqual(a, b []byte) bool {
    if len(a) != len(b) {
        return false
    }
    var v byte
    for i := range a {
        v |= a[i] ^ b[i]
    }
    return v == 0
}

An early-return comparison leaks how many bytes matched, which can be exploited byte-by-byte to forge a valid proof.

2. Validating A mod N != 0 and B mod N != 0

If A mod N == 0, the server's computation degenerates: the shared secret becomes 0 regardless of the password. An attacker could send A = 0 or A = N or A = 2N to bypass authentication. The same applies to B on the client side.

Both sides must reject these values before proceeding.

3. Padding to Fixed Length

All BigInt-to-bytes conversions are padded to the full byte length of N (256 bytes for a 2048-bit group). Without padding, H(A || B) could collide with H(A' || B') when leading zero bytes are dropped.

func padTo(n *big.Int, length int) []byte {
    b := n.Bytes()
    if len(b) >= length {
        return b
    }
    padded := make([]byte, length)
    copy(padded[length-len(b):], b)
    return padded
}

4. Verifier == Asymmetric Secret

The verifier v = g^x mod N acts like a public key: the server can verify proofs with it, but cannot derive the password from it. Even if the verifier database is exfiltrated, the attacker must solve the discrete logarithm problem (in a 2048-bit group) to recover the password -- computationally infeasible.

5. Rate Limiting and Anti-Enumeration

SRP does not protect against online brute-force. Auth Box adds per-email rate limiting (5 attempts per 5-minute window) and returns identical error messages for "user not found" and "wrong password" to prevent email enumeration.

What We Learned

Building SRP-6a from scratch (rather than using a library) forced decisions that would otherwise be invisible:

BigInt is production-ready in browsers: Native BigInt arithmetic in TypeScript is fast enough for 2048-bit modular exponentiation. No WASM needed.
Padding is the silent killer: The most insidious bug was not padding g to N's byte length when computing k = H(N || PAD(g)). Client and server computed different k values and the handshake silently failed. Both sides must use identical padding.
Session key derivation matters: We derive K = H(S) rather than using S directly. The raw shared secret has algebraic structure; hashing it produces a uniformly distributed key suitable for symmetric crypto.
Test the full round-trip in a single language first: Our Go test file includes a computeClientSide function that mirrors the TypeScript client. This catches cross-language mismatches (endianness, padding, hash input ordering) before they hit the network.

Try It Yourself

Auth Box is open source under the MIT license:

Repository: github.com/MARUCIE/authbox

Key files for the SRP implementation:

File	Language	Role
`packages/crypto/src/srp.ts`	TypeScript	Client-side SRP-6a (BigInt + @noble/hashes)
`services/api/internal/auth/srp.go`	Go	Server-side SRP-6a (crypto/rand + math/big)
`services/api/internal/auth/srp_test.go`	Go	Round-trip tests (6 test cases)
`apps/web/lib/auth.ts`	TypeScript	Full registration and login flows

To run the SRP tests:

cd services/api && go test ./internal/auth/ -v -run SRP

The crypto layer beyond SRP includes Argon2id key derivation, AES-256-GCM vault encryption, BIP-39 seed phrases for recovery, and Arweave-based vault archival. All zero-knowledge, all client-side.

Maurice | maurice_wen@proton.me