> The most interesting extension of this idea comes from the creator of Signal, Moxie Marlinspike’s recent work with Confer. In Passkey Encryption, he describes using the WebAuthn PRF extension to derive durable encryption key material from a passkey.
I do respect Moxie Marlinspike, but I'm not sure he "came up with this idea". I read about it first from the author of Age [1]. And to me it seems like whoever worked on adding a PRF extension to WebAuthn probably knew that PRFs are cool and could be used for cool stuff.
All that to say, I don't feel a need to attribute that to someone in particular, but if I did, I would want to be sure I am right.
> In practical terms, this replaces a lot of the awkward machinery behind encrypted systems. End-to-end messaging usually requires long-lived identity keys, recovery phrases, or some form of server-assisted key escrow. Encrypted SaaS products often rely on password-derived keys or server-stored wrapped keys for recovery. Using passkeys and the WebAuthn PRF shifts that root of trust into hardware-backed credentials that already exist on user devices, reducing both system complexity and the number of high-value secrets stored on servers.
I hope that makes the reason for my post clearer? Thank you for your comment, I'm pretty new to writing blog posts and your comment identified that I clearly hadn't properly communicated why I though the approach was novel or exciting. It might have been obvious to some, but having Moxie do it in a product makes it much easier to justify by coping his approach.
Agree that the idea of using passkeys for encryption isn’t Moxies or novel, since it’s explicitly in the spec. MaybeI failed to get at what Moxie’s implementation replaces and how that’s novel, and moving the ecosystem forward. I could see a similar system being used for E2EE messaging too.
> The most interesting extension of this idea comes from the creator of Signal, Moxie Marlinspike’s recent work with Confer. In Passkey Encryption, he describes using the WebAuthn PRF extension to derive durable encryption key material from a passkey.
I do respect Moxie Marlinspike, but I'm not sure he "came up with this idea". I read about it first from the author of Age [1]. And to me it seems like whoever worked on adding a PRF extension to WebAuthn probably knew that PRFs are cool and could be used for cool stuff.
All that to say, I don't feel a need to attribute that to someone in particular, but if I did, I would want to be sure I am right.
[1]: https://words.filippo.io/passkey-encryption/
I edited the post and added this:
> In practical terms, this replaces a lot of the awkward machinery behind encrypted systems. End-to-end messaging usually requires long-lived identity keys, recovery phrases, or some form of server-assisted key escrow. Encrypted SaaS products often rely on password-derived keys or server-stored wrapped keys for recovery. Using passkeys and the WebAuthn PRF shifts that root of trust into hardware-backed credentials that already exist on user devices, reducing both system complexity and the number of high-value secrets stored on servers.
I hope that makes the reason for my post clearer? Thank you for your comment, I'm pretty new to writing blog posts and your comment identified that I clearly hadn't properly communicated why I though the approach was novel or exciting. It might have been obvious to some, but having Moxie do it in a product makes it much easier to justify by coping his approach.
Agree that the idea of using passkeys for encryption isn’t Moxies or novel, since it’s explicitly in the spec. MaybeI failed to get at what Moxie’s implementation replaces and how that’s novel, and moving the ecosystem forward. I could see a similar system being used for E2EE messaging too.