Hacker News Reader

Comment by mkw5053 | Hacker News Reader

Very cool! Clever use of WebAuthn’s PRF to reuse synced passkeys for file encryption without the hassle of managing private keys directly. The catch is credential revocation: leaked passkeys mean full rotation and bulk re-encryption of files. That works fine for casual backups, but production usage will need tooling to handle automated rotation cleanly.

View on HN

> Clever use of WebAuthn’s PRF to reuse synced passkeys for file encryption

Agreed on the clever part, but arguably that's exactly what PRF was designed for :)

> The catch is credential revocation: leaked passkeys mean full rotation and bulk re-encryption of files.

That's where the PRF input of key derivation comes in. The idea is to have that input be rotate-able.

That's also why there is two of them: So you can "atomically" (or at least using only one WebAuthN interaction) rotate the derived keys.

I feel like only one extra layer of indirection (encrypt a symmetric key with the age key) would enable rotation.

Yeah, envelope encryption is the only sane solution. That also allows decryption with multiple passkeys, for example.

could you please elaborate on envelope encryption in this case. I encrypt one key with another, how does it enable rotation?

The first key is now safer, but now I have to manage 2 keys, master key and a the one I use per files group X.

Basically it works like this: You encrypt the data with a long, symmetric key. This data key can be used to decrypt the data itself, which may be large, and thus expensive to re-crypt. Now you encrypt this data key with the user key, and store that encrypted decryption key in addition to the encrypted data. You can also create multiple copies the data key encrypted with different user keys to enable shared access to the encrypted document. This way, you can decommission individual user's access by dropping their copy of the key, and efficiently re-crypt the data key because you don't have to encrypt the full data, but only the key.

In scenarios where you don't have multiple users, you can also just prepend the encrypted data key to the payload (as in, `<encrypted data key>.<encrypted payload>`), so effectively you'll only have to store an encrypted blob and the user key.

Edit: The AWS docs explain this way better than I do: https://docs.aws.amazon.com/encryption-sdk/latest/developer-...

oh this is so cool, thank you for explaining!

I was thinking that master key is a wrapping key but that's the other way around, plus I can have many users who have access to the data. Neat

Reply on news.ycombinator.com