Saving encrypted stuff on a server is more properly known as client side encryption[1]. Any instance of cryptography used to protect the contents of anything in any way is commonly referred to as end to end encryption these days. Fortunately, the misuse of the term can serve to identify an entity with poor understanding of the technology they are try to sell you.

[1] https://en.wikipedia.org/wiki/Client-side_encryption

I don't agree, if you were to define end-to-end encrypted backup this is what it would be.

End-to-end encryption is when to entities communicate and establish an encrypted connection between them.

In this case one device makes a backup while another might not be even made yet.

(Edit: Rephrased for better clarity)

I'm not sure what you mean by "while another is not yet even made"

I mean it literally. It might be not yet even assembled at a factory, not delivered to its destination country and not sold to a user.

Ah, well that doesn't really matter, you can still see them as two separate participants in an asynchronous protocol.

End to wnd encryption is when on one end you encrypt data for every remote end that is supposed to decrypt this data. That's why it is called end-to-end, because all ends are known and nobody can tamper the correctly established communication with correctly verified recipient. That's how all e2ee protocols work, otr, omemo/signal, etc.

If you do not know what end is going to decrypt it, is is just an encryption with a key/password. Anybody who has the credentials can access the data.

These WhatsApp backups could be restored by 50 different 'ends', so using e2e in this context is incorrect.

Yeah sure, you're saying that the model for full disk encryption would be more relevant here. But at the same time, there is a third-party server in the middle of the protocol, and so I'm not sure if that model would be more relevant.

End to end encryption should be as secure as the underlying encryption technology, this is only as secure as a users password which 99% of the time is trivially crackable.

It’s like equating Fort Knox and a locked car. Fort Knox might not be impenetrable, but they really don’t provide similar levels of protection.

>this is only as secure as a users password which 99% of the time is trivially crackable

Are you talking about the WhatsApp backup scheme? I think the HSM should theoretically make even a weak password mostly uncrackable.

>up front sniffing of the passwords provided to the server

I haven't read either pdfs fully, but it seems to me no password is provided to the server (though I'm actually not sure what you mean by password or server). The OPAQUE protocol means the HSM can verify the user has the password without ever seeing the password. So the password is never provided to the HSM or any other server. It's asymmetric. And for the encryption key, it's stored in the HSM yes, but when sending it to the HSM, it's unsniffable because it's encrypted with the HSM's public key.

>doing an offline check of every possible

The HSM should prevent that by limiting the number of attempts. From the WhatsApp pdf:

>The HSM Backup Key Vault is responsible for enforcing password verification attempts

Of course, if there's a hardware vuln in the HSM, then the verification attempts can be bypassed, and the backup is only secure if the password is quite high entropy. It comes down to how likely there is to be a hardware vuln in the HSM. I think in practice HSMs tend to have hardware vulns somewhat frequently, which is why I said "theoretically" in my previous comment. If we theorize the HSM has no hardware vuln, then it's safe with a weak password. We also have to assume there's no backdoor built into the HSM, or the HSM keypair computation or distribution process.