Closed WildCryptoFox closed 5 years ago
Thanks for your suggestion, @james-darkfox . I think this issues had been discussed since beginning, see #4.
PIR and OT protocols are great, but that's not the purpose of Zbox implementation. Its purpose is not trying to hide and be anonymous to server, like Tor. Instead, its goal is to remove the details of data as much as possible. As you said, server knows where you come from, what blocks reads or writes, and when are you doing that, server even knows your email address (if you signed up). It knows you have secret data, we're not hiding that truth, but it just doesn't know what the content is.
'Zero-details' doesn't mean zero knowledge or no knowledge, it definitely has some knowledge but just don't know what's the details, as the name suggested. In a cryptographer's eyes, 'zero-knowledge' has strict claim and that's why I changed the naming to avoid misleading.
Anyway, I will improve words in the doc to give it more accurate description. Thanks again.
Perhaps "near-zero", with a footnote or link to an enumeration of what the server does know.
Sure, I've now updated the wording on https://zbox.io/about, hope it to be more clear and less misleading.
@burmecia I wouldn't quote the near-zero nor mention the things you're not doing. The list of what is leaked is sufficient.
SpiderOak made the same mistake with its misuse of the term "zero knowledge" and since migrated to "no knowledge", which hasn't fixed the semantic issue but it has avoided the overlap of terms - by coining another inaccurate term, which you've adopted.
An extract from https://zbox.io/about/ , emphasis mine.
"Same-sized blocks" may reduce some leakage but this does not imply that nothing remains leaked.
To prevent (1) the users must identify to the service using a credential that demonstrates their authority without revealing their identity.
To prevent (2) a Private Information Retrieval (PIR) or Oblivious Transfer (OT) protocol must be used; to prevent the server from learning which blocks the client asks for and to prevent the server from learning which value it responds with. PIR may reveal other blocks, potentially owned by other users. Even if encrypted, this is probably not desired. Limiting (2) to OT.
To prevent (3) the dual to PIR whose name I've forgotten may be used to enable a client to upload a block without revealing to the server the block they've pushed into the set.
In so far that I've read, there have been no mentions for PIR or OT or any form of anonymous credentials in ZBox' documentation. When a user reads your claims, they may be led into a false sense of security by correctly interpreting what you've written and not as intended.
Please consider rewording these claims or invest into the cryptographic protocols that make them true. Obviously there are costs in the latter and the choices of which to use depends on how many "cloud" replicas there exist and who controls them. I.e. If there are several replicas owned by distinct parties then you can use some of the cheaper PIR protocols that rely on a ratio of the servers not colluding. If you've only one server, you'll need CPIR (computationally bound) which builds on Diffie-Hellman, or a computationally bound OT.
BTW: The /about/ page says "ZBos" instead of "ZBox" in the 5th paragraph.