4 ms·

There's a secure channel here (TLS) and then the blob encryption all happens clientside, so i don't think a PAKE-type solution is less mechanism, but i do recog

by mappu 4y ago

There's a secure channel here (TLS) and then the blob encryption all happens clientside, so i don't think a PAKE-type solution is less mechanism, but i do recognize your expertise on that. Where do you think it would fit in? Backup and sync-type software has the interesting engineering requirement that it is expected for the user's device to get completely lost/stolen/wiped, so any key material must be reproducible from the user's password. Password -> KDF(1) gives you a password-alike: used for logins, server treats this kdf output as a password and stores a bcrypt/argon hash of it, as you would normally expect from a run-of-the-mill webapp. The client generates a random data encryption key; seals it with the password; and then submits the sealed version to be stored in the user's profile on the web server. The web server can't unseal the original data encryption key without the original password, and it never sees that, only the KDF(1) version of it. That's all they've really done here. There is one more level of key indirection for the blobs themselves that i think is irrelevant but maybe useful for key rotation. Totally agree that unpadded RSA and ECB suck as primitives - they were bad choices then, they are bad choices now, and AEAD is a no-brainer upgrade (EDIT: and would close the post-back oracle) - but aside from picking better primitives the mechanism really does seem okay to me. I'd love to hear more from you though,

tptacek 4y ago
I'm a little lost, because what they came up with is a complicated and naive key proof that allowed attackers to recover the RSA key. There was no code that already implemented this weird ECB key-wrap and RSA key-proof scheme they came up with; they had to write it all themselves, rather than just grabbing a PAKE and an AEAD from a library. And the consequence of them doing that was that they had key recovery attacks like three levels deep.

by mappu 4y ago

tptacek 4y ago

I'm a little lost, because what they came up with is a complicated and naive key proof that allowed attackers to recover the RSA key. There was no code that already implemented this weird ECB key-wrap and RSA key-proof scheme they came up with; they had to write it all themselves, rather than just grabbing a PAKE and an AEAD from a library. And the consequence of them doing that was that they had key recovery attacks like three levels deep.