[noam_k]

I think the issue here is that the server would have to store a copy of the register per peer, as it can't calculate which one is the most recent. Using FHE allows the server to hold a single copy.

In other words the server could forward and not store if all parties are always online (at the same time).

[neon_me]

Server will store encrypted blob and its hash/etag.

Client before upload of data, check for hash/etag of blob he originally fetched. If blob on server has different one, it will download it, decrypt, patch new data on existing one, encrypt and reupload.

Whats the catch?

AES is hardware accelerated on the most devices - so with all the ops it will be significantly faster than any homomorphic enc nowadays.

[nixpulvis]

I too was wondering the same thing. FHE is cool tech, but this seems to me to be a bad application of it since it will undoubtedly be less efficient.

FHE is useful when trying to compute on data from various sources who all mutually want to keep some information secret. For example, Apple's use of FHE to categorize photos [1]. In this case all the server is really doing is "compressing" for lack of a better word, the change sets, so each offline client doesn't need to sync every message since they are already merged by the server.

If all you want is to keep a synchronizing server in the dark, but all clients can be trusted with the unencrypted data, traditional key exchange and symmetric encryption should suffice.

[1]: https://machinelearning.apple.com/research/homomorphic-encry...

[yusina]

So it's "just" a storage optimization?