alt Hacker NewsPasskeys 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!
Replies
Why use the word "hijacked" and not repurposing, extending or adapting? I'd even prefer leveraging.
What stops anyone else doing the ECDSA public key recovery hack by signing two identical messages and getting the public key, i.e. the thing you are using as a cryptographic seed?
In general, using a key for a purpose it was not designed for gets you into trouble. Treating a public key as private key seed material is almost certainly going to be a problem. Systems are just not designed to keep public keys secret, even if webauth does.
I don’t understand why you want to enforce only using the public key instead of private key - while I believe you that as of now browsers do not disclose the public key anywhere, I’d also suspect that this is far more likely to be violated and accidentally disclosed by a bug than the private key, which theoretically cannot ever leave the TPM.
Would KDF(deterministic_sign(“well-known message”)) not also provide valid entropy?
Is it just impossible to force a nonce for a deterministic signature?