TL;DR
A developer experiment called PassSeeds shows how WebAuthn passkeys (P-256 credentials) can be used as deterministic seed material for other cryptographic uses by recovering the passkey public key via ECDSA key recovery. The approach keeps private keys inside the authenticator while producing reproducible public-byte seeds that can be converted to BIP-39 mnemonics and used to derive keys for Bitcoin, ZKP curves, and other protocols.
What happened
The author, previously on Microsoft's Passkeys standardization team, describes PassSeeds: a technique that treats a passkey’s P-256 public key as seed material for other cryptographic functions. PassSeeds relies on two core behaviors of passkeys: the platform-secured storage and end-to-end sync of credential bundles, and the fact that a passkey’s public key can be deterministically reconstructed by performing two ECDSA signatures over the same message and running public-key recovery on the resulting signatures. In practice the flow uses navigator.credentials.create() to create a P-256 passkey (the only time the platform returns the public key at generation), then later requests two assertions via navigator.credentials.get() signing the same challenge twice. The client recovers the public key bytes from the two signatures, hashes them to a 32-byte seed, and optionally encodes that entropy as a BIP-39 mnemonic. The recovered bytes stay public-only; no private key material leaves the authenticator.
Why it matters
- Passkeys already provide hardware-protected, platform-synced credential bundles; PassSeeds leverages that to provide a reproducible, user-gated seed without exporting private keys.
- The method offers a UX alternative to users copying long key material or buying specialized hardware for non-login cryptographic tasks.
- It enables deriving keys for curves and protocols not natively supported by WebAuthn (for example, secp256k1 or BLS12-381) while preserving authenticator-based user verification.
- Converting the seed to a BIP-39 mnemonic provides a familiar recovery option for users, integrating with existing backup practices.
Key facts
- Passkeys are asymmetric WebAuthn credentials typically generated as P-256 key pairs and scoped to the origin that created them.
- Platforms store and sync passkey credential bundles (private + public key and metadata) across a user’s devices via end-to-end encrypted sync.
- The platform returns the public key only during the initial navigator.credentials.create() call; the post recommends not exporting that public key at creation time.
- PassSeeds reconstructs the passkey public key by obtaining two ECDSA signatures over the same message and performing public-key recovery on the pair of signatures.
- The recovered public-key bytes are hashed (SHA-256) to produce a 32-byte PassSeed; that entropy can be encoded as a BIP-39 mnemonic.
- No private material leaves the authenticator during the double-sign recovery flow; the app receives only public-key bytes.
- From the PassSeed, deterministic keys can be derived for other curves or applications (e.g., HKDF+clamping to produce a secp256k1 signing key, or deriving BLS12-381 scalars).
- If other devices with the backing passkey remain, platform sync will replicate the PassSeed-backed passkey to newly enrolled devices; exporting a mnemonic is recommended as a backup if all devices are lost.
- A TypeScript implementation and code examples for the core methods (create and get) are provided in the project’s GitHub repository.
What to watch next
- Whether browser and platform vendors will respond to or restrict patterns that reconstruct public keys in this way — not confirmed in the source.
- Independent security analyses and audits of the PassSeed double-sign recovery flow and its threat model — not confirmed in the source.
- Adoption by apps and services that need non-WebAuthn curves or deterministic keys (for example, cryptocurrency wallets or ZKP tooling) — not confirmed in the source.
- Any changes to WebAuthn or platform APIs that would affect the ability to perform the described navigator.credentials.create()/get() flows — not confirmed in the source.
Quick glossary
- Passkey: A WebAuthn-formatted public/private credential, typically created on a user device and used to replace passwords for site or app login.
- WebAuthn: A web standard and API for public-key-based authentication that interoperates with authenticators like platform TPMs, secure enclaves, or external security keys.
- ECDSA public-key recovery: A cryptographic technique that can reconstruct a public key from one or more ECDSA signatures over the same message under certain conditions.
- P-256: An elliptic curve commonly used for ECDSA and supported by many WebAuthn implementations.
- BIP-39 mnemonic: A human-readable set of words encoding entropy used as a backup format for deterministic wallets and other key material.
Reader FAQ
Does the private key ever leave the authenticator during PassSeed generation or recovery?
No. The described flow keeps private material inside the authenticator; only public-key bytes reconstructed via signature recovery are used.
Can a PassSeed be regenerated if needed?
Yes. Repeating the double-sign ECDSA recovery flow with the same passkey deterministically yields the same public-key bytes and therefore the same seed.
What happens if I lose all devices with the backing passkey?
If no devices remain, the source recommends having exported the PassSeed as a BIP-39 mnemonic as a recovery method; otherwise, you would need to transfer assets to a new seed — further details are not confirmed in the source.
Is this approach officially supported by WebAuthn or platform vendors?
Not confirmed in the source.
In my time at Microsoft, I worked on the team responsible for the development and standardization of Passkeys. Passkeys have made standard, secure, cryptographic authentication accessible to all users, but…
Sources
Related posts
- Are we done with social networks? Signs of social media fatigue worldwide
- Brave refactors Rust-based adblock engine to cut browser memory use
- Pluribus nearly had 100 alternate titles — Vince Gilligan names the worst