4

When you are using services like chat, file sending, exchanging etc., you always have to trust server providing these services. The only way to use services without having to trust third party is to not have third party (server) at all and to perform all actions directly (peer-to-peer).

The company providing services can actually encrypt client side so server wouldn't have access to client's data, but any software update can contain changes that would send decryption info along with encrypted data, so server has access to it. Is it possible to make users sure that all their data is completely safe from server itself?

So the main question is: Is it possible to keep user data safe without using complete decentralization (p2p)?

  • End-to-End encryption does this: I use GPG for emails and OTR for chats. I meet up with the other partner or call him on the phone and verify the key fingerprints. After that, we know that there is no eavesdropping anywhere on the way. The server does have plain text data. – Martin Ueding Aug 31 '14 at 13:39
  • @queueoverflow Assuming that the phone call wasn't being monitored. – Shadur Aug 31 '14 at 15:23
  • @Shadur the phone call may be monitored, it only may not be intercepted. – user10008 Aug 31 '14 at 15:53
  • related: all the questions tagged "host-proof" over on the crypto stackexchange. – David Cary Sep 1 '14 at 4:09
5

The problem you are describing is not solved yet completely. It largely condenses to Software auditability its distribution method, and protocol design.

Protocol design

You've already mentioned that the encryption needs to be done client-side. This is offered by lots of today's software already. Companies selling a client-side encryption protocol can't easily build their revenue model of selling the customer's data without this becoming public.

Software auditability

Even with a well designed protocol, it's possible the client doesn't follow it. In order to verify that the client does what the protocol says, the software needs to be audited by the public. This works most easily when the software is accessible in a format humans can undestand best: in source code. A verifiable software doesn't have to be open source, or at have its source code publicly available like truecrypt, but its a very strong point.

When the source code has been audited, the trusting trust problem arises: somebody needs to verify that the binary matches the source code. This can be solved by Deterministic builds, which is a new and currently very unstable method. It has been used to ensure integrity for software considered important like the Tor Browser Bundle, or various Bitcoin clients. Debian has started an effort to make its whole application repository built deterministically (last link).

The amount of software that needs to be verified can be reduced by following a model similar to DRM: one part of the software is closed-source and not trusted, and another part doing the encryption is open source, and audited. End-to-End (repository, blog article) in combination with the gmail js client, or the addon published by Mega are a good examples for this.

Those approaches make it hard to hide that everybody's encryption is bypassed, but its still easy to hide that one's encryption is bypassed.

Distribution method

There are several ways to distribute software today. App stores like Google Play store or apt, the usual HTTP download, and, on the web, the HTTP/javascript solution.

The worst method is HTTP/js: every time you visit the page, you basically download the software a new time. The server can give you a malicious content, and the next time you visit the page all traces are deleted. The best way to secure a web page is the DRM-like method I've described above.

HTTP downloads also have lots of problems. You are trusting every download provider that they don't serve you malicious software. Android has an "untrusted sources" checkbox which is disabled by default to save you from installing such software. I'm also including PPAs into this, however I don't know of any malicious content served over PPAs. Better is you only trust one entity, through package repositories.

Even package repositories give you an entity you have to trust: the repo maintainer, be it google, debian, or someone else. The software may be auditable, and use a good protocol, but the particular version your maintainer gave you has a backdoor.

The problem is similar to the certificate distribution problem — ensuring that all people see the same­ — so similar solutions apply. I could think of a gossip protocol like the one outlined in the End-to-End wiki, or even more decentralized ones like Namecoin, however you can argue how decentralized Namecoin is, when hashing gets centralized.

To protect you from the usual bad guy, trusting a trustworthy repo maintainer is currently enough today, as most people still fall for the HTTP download trap, and they can make business there.

  • Thank you. I did get a starting point to go on with researches. – user3081123 Aug 31 '14 at 14:56
  • @ user10008 - Do you think it is possible to design Virtual Machines that can simulate this above mentioned concept(i.e.,designing a system where the client doesn't have to trust the server)? IIRC the existing Virtual Machines that we have in the market cannot simulate such a Scenario.Many Thanx. – user52380 Aug 31 '14 at 16:19
  • seems like the Mega add-on no longer exists – myrdd May 20 '18 at 10:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.