PassSeeds – hijacking Passkeys to unlock new cryptographic use cases

Ultimately what he is suggesting to do is to bind a string of entropy to a website through facilitation of the browser and a Passkey.

A cryptographic seed is one of the most sensitive things. And here you choose to expose it to a website (even though it was specifically generated for that website). This is not something you do for authentication. The only reason to do this is to have javascript/wasm on a website perform sensitive cryptographic operations for you. You should never be doing this.

Applications such as password managers can already integrate entropy from a passkey to encrypt their databases using the Challenge-Response protocol: https://docs.yubico.com/yesdk/users-manual/application-otp/c...

Passkeys can be hijacked to serve as cryptographic seed material that is securely synced across all of a user’s devices, enabling the generation of a wide range of cryptographic keys. This allows Passkeys to power use cases far beyond what they have traditionally been constrained to. I’ve been calling this mechanism PassSeeds.

I’ll leave the details to the blog post, but here’s a short list of what PassSeeds enable:

- Need a user-custodied BLS12-381 key to engage in more advanced ZKP Verifiable Credential / proofing flows? Say less, you're covered.

- Want to create a petty cash Web wallet for Bitcoin transactions that relies on a secp256k1 key? Ask and ye shall receive.

- How about keys for decentralized social media identifiers and post signing that are of a type other than P-256? No problem, I got you!

it seems foolish to build a system that relies on the token to essentially be a secure way to store a public key

when the entire point of the token is to guard the private key, and make the public key accessible

Interesting, but the PRF / LargeBlob extensions already enable just such functionality (and more) without relying on the secrecy of a public key.

Why not just use those?

Edit: that's what I get for not reading far enough -- the article addresses this, though I would quibble with the confident assertion that the extensions are not available in major browsers, given I worked for a startup literal years ago which built major functionality on top of these extensions, which were available in (at least) all relevant mobile browsers.

If a compromised browser extension intercepts the public key, there's an attack vector.

How is this any better than just storing the value in a password manager, or in YubiKey's "Static Password" mode?

Also, the "ECDSA Public Key Recovery" picture makes me suspect this is AI slop.