Dave Howorth schreef op 24-04-2016 20:40:
On Sun, 2016-04-24 at 18:07 +0000, Xen wrote:
Interesting point. A zero-knowledge backup provider should only be allowed to call itself zero-knowledge if its access platform (client) is made or verified (ideally made really) by a third party. Otherwise you have a conflict of interests. You cannot depend on some other party always being able to make the moral high choice. What if law enforcement forces them to change their client without notifying you
warrant canary
? If you have an independent client that is really fully independent and cannot be retracted by any party, meaning it would have to be open source, only then can you say you have a zero-knowledge encryption storage platform.
even if it's independently encrypted by a third party, why would you trust the third party?
In Linux we solve it by encrypting thing ourselves I guess :-/.
In the real world we solve it by encrypting it ourselves, with our own private parameters, but using some open encryption software designed by third parties we trust, since we don't have the expertise to implement encryption software ourselves without introducing bugs.
Cheers, Dave
I don't know what you're arguing against. What you say is completely in line with what I say. About warrant canary, I didn't know about that, thanks. Yet that doesn't feel like any real safeguard, it would either have to be specific to your person, and/or it would need to be visible to you at all times. Further more although it seems legal, that really seems like a breach of the law. The message would need to be posted anew every day. Removal of the message would in theory need active participation, theoretically becoming a problem if law enforcement was really strong there. Furthermore if they really took over they could post the message themselves. Wikipedia tends to agree. "In September 2014,[21] US security researcher Moxie Marlinspike wrote that "every lawyer I've spoken to has indicated that having a 'canary' you remove or choose not to update would likely have the same legal consequences as simply posting something that explicitly says you've received something."" "In March 2015, after Australia outlawed warrant canaries, computer security and privacy specialist Bruce Schneier wrote in a blog post that "[p]ersonally, I have never believed [warrant canaries] would work. It relies on the fact that a prohibition against speaking doesn't prevent someone from not speaking. But courts generally aren't impressed by this sort of thing, and I can easily imagine a secret warrant that includes a prohibition against triggering the warrant canary. And for all I know, there are right now secret legal proceedings on this very issue."" I don't mean independent encryption by a third party and I never said any such thing. I was talking about a third party app, the ones you mention as well. That real world you mention also contains SpiderOak, which cannot be verified to be truly zero-knowledge because its client is (still) closed source. What I mean is that any platform that provides a method or tool to explicity access the data, should not also be the one that enables or designs, introduces or manages, the encryption component to said client. What I mean is that the user interface for the program that is the client to the network, should not be capable of learning about the encryption key to begin with. In the real world, people use services such as this. What you say is correct, but you forget that there are also people using such services with such clients that cannot really be fully trusted. If the client does not actually access the encryption keys, for instance because it uses an encryption plugin that has its own user interface or way of interacting with the user or its filesystem where possible keys are stored, and it if it is theoretically not possible for the client to interface or listen in to that, then you have a zero knowledge solution, but otherwise you don't really have it. Of course if you use your own tools to encrypt, this thing is going to be true. However these clients typically have access to the unencrypted data. That is something that should not be allowed. It is the encryption engine that you control that should access the data and nothing else. This is the modular design you need if you are going to design such a tool for a commercial deployment, and still consider yourself zero-knowledge. Unlikely we will see this but in principle it is not hard or impossible. Yes, the thing you would use is those 3rd party trusted encryption solutions you mention. I was not talking about what Linux hackers do. I was talking about people using commercial solutions on e.g. Windows or any other platform (including Linux). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org