Skip to content

feat(auth): derive backend auth keypair from seed (#2769)#2876

Draft
piyalbasu wants to merge 10 commits into
masterfrom
feat/2769-derive-auth-keypair
Draft

feat(auth): derive backend auth keypair from seed (#2769)#2876
piyalbasu wants to merge 10 commits into
masterfrom
feat/2769-derive-auth-keypair

Conversation

@piyalbasu

@piyalbasu piyalbasu commented Jun 26, 2026

Copy link
Copy Markdown
Contributor

TL;DR

Adds the extension-side primitive that turns a wallet's recovery phrase into the user's anonymous backend identity — the first piece of Cross-Platform Contact Sync (#2769). It derives a dedicated auth key from the seed that is cryptographically independent from the user's Stellar wallet key, so the backend can recognize a returning user without ever learning their wallet address and without triggering any signing prompt.

This PR is derivation only — it deliberately does not generate request tokens, call any backend, or touch the contacts UI. Those are follow-up tickets. Nothing in the product changes yet; this is a self-contained, fully-tested building block.

The same recovery phrase must produce the exact same identity on the extension and on mobile, so this ships committed cross-platform test vectors that the mobile app will be held to as well.

Design doc lives in wallet-eng-monorepo (design-docs/contact-lists/Freighter Auth Keypair Derivation Design Doc.md), alongside the Contact Sync design doc — not in this repo.

Draft: opening for early review of the crypto contract and test vectors before the dependent token-generation work builds on it.

Implementation details (for agents/reviewers)

What changed (all new, under @shared/api/helpers/):

  • deriveAuthKeypair.ts — the primitive:
    • deriveAuthSeed(mnemonic): HMAC-SHA256 (via crypto.subtle) with key = the 64-byte BIP39 seed (bip39.mnemonicToSeedSync(mnemonic)) and message = utf8("freighter-auth-v1"), returning 32 bytes. Marked @internal (returns private-key material; exported only for test assertions).
    • deriveAuthKeypair(mnemonic): feeds that 32-byte seed to Keypair.fromRawEd25519Seed; userId = keypair.rawPublicKey().toString("hex") (lowercase hex — matches the backend's canonical sub). Pure: no logging, no keyManager, no messaging, no persistence.
  • authKeypairVectors.ts — committed cross-platform vectors (mnemonic → authSeedHex → userId). Kept outside __tests__/ on purpose: Jest's default testMatch collects every file under __tests__/ as a suite and fails a fixture with "must contain at least one test." The intermediate authSeedHex is included so a failing mobile test localizes the divergence (HMAC step vs Ed25519 step). freighter-mobile must mirror these.
  • __tests__/deriveAuthKeypair.test.ts — 10 tests mapped to acceptance criteria: vector parity (Run eslint during build, minor adjustments #1), determinism, lowercase-64-hex format, independence from the wallet key (router fix #2), no messaging side-effects (Piyal dev #3), invalid-mnemonic rejection.
  • @shared/api/package.json / yarn.lock — declares bip39@3.1.0 (exact pin; promoted from a transitive dep). No new library is introduced to the project.

Notable decision — bip39 directly instead of stellar-hd-wallet: stellar-hd-wallet cannot run under jest/jsdom (its compiled bip39 import throws Cannot read properties of undefined (reading 'wordlists'); verified that adding it to the transform allowlist does not fix it). bip39.mnemonicToSeedSync is byte-identical to what stellar-hd-wallet wraps, so cross-platform parity is unaffected.

Acceptance #2 wording correction: the ticket says "auth pubkey is not a valid Stellar G address," which is technically false (any 32 bytes StrKey-encode to a format-valid G…). The true, tested property is cryptographic independence from the wallet keypair. Ticket text should be updated.

Verification: yarn jest @shared/api (full collection) → 8 suites / 63 tests pass under jest-fixed-jsdom (real WebCrypto); tsc -p @shared/api/tsconfig.json clean. Test vectors were independently regenerated from the algorithm and matched.

Known minor follow-ups (non-blocking, not yet applied):

  • Clarify the authKeypairVectors.ts header comment to state HMAC arg order explicitly (key = seedBytes, message = salt) for mobile implementers.
  • Strengthen the independence test to also assert the expected userId (today it only asserts inequality with the wallet key; correctness is already covered by the vector test).
  • Drop the redundant Buffer.from(...) wraps and hoist AUTH_SALT bytes to a module constant (micro-cleanups).
  • Sibling ticket: freighter-mobile mirrors the algorithm + vectors.
  • Update ticket [Extension] Derive auth keypair from seed for backend authentication #2769 acceptance router fix #2 wording.

The two translation.json keys in the diff ("Auto-lock timer" en/pt) are auto-generated by the repo's husky i18next-scanner pre-commit hook filling a pre-existing gap on master; unrelated to this feature.

piyalbasu and others added 7 commits June 25, 2026 17:06
Design doc for the extension-side derivation primitive:
HMAC-SHA256(seedBytes, "freighter-auth-v1") -> Ed25519 keypair, hex
pubkey = anonymous backend user ID. Covers scope, threat model, crypto
choices (crypto.subtle + stellar-sdk, zero new deps), exact algorithm,
session-timeout lifecycle, verified cross-platform test vectors, and a
reworded acceptance #2 (cryptographic independence, not "invalid G addr").

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…d/api (#2769)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
#2769)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Jun 26, 2026

Copy link
Copy Markdown
Contributor

PR Preview build is ready: https://github.com/stellar/freighter/releases/tag/untagged-480becda1ade92fa47a9 (SDF collaborators only — install instructions in the release description)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant