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,

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.

You'd need to implement SIV in the browser yourself, not sure if that's a good idea either. Subtle crypto has support for AES-based key wrapping, but AES-GCM seems to be good enough for most cases, even AWS uses that to protect master keys in AWS KMS [1]. Using augmented PAKE for authentication would be nice of course, but that needs to implemented manually in the browser as well. In my understanding it also requires providing the server with a separate user ID, which you would either need to derive from the password or store with the download link.

I think if you have a download link of the form https://foo.bar/#abcdef... you can simply put a large random value there (e.g. 128 bit), use HKDF to derive an ID and an encryption key, use the ID (shared with the server) to store/fetch encrypted data on/from the server and the key (not shared with the server) to encrypt/decrypt it on the client side. This would assume that the ID transmitted to the server over a secure channel and that brute-forcing of IDs to download encrypted data is not practical. Such a scheme would not be secure though if you derived the ID and key from a user-provided password, as the server could then brute-force the password from the ID the client provides.

1: https://rwc.iacr.org/2018/Slides/Gueron.pdf