Encryption in-transit, encryption at-rest, end-to-end encryption and zero-knowledge encryption: different types of encryption in a nutshell.
Internet service providers offers various privacy-oriented features meant to secure your data and if you're not tech-savvy, it's easy to get confused. Here's a brief introduction to various types of encryption in internet services.
The first type is encryption in-transit. It means that an internet service protects your data when it's on the move, from local storage to cloud storage or from one network to another. It is widely believed that data is the most vulnerable on the move, that’s why this kind of encryption was introduced in the early days of internet - you use it every day, it works in all web browsers and mail client applications. You can imagine an armoured bank van - your money is being secured for transport… but after reaching the place of destination, it’s unloaded and becomes unprotected again - and this is when another type of protection can be used.
To secure your money in a bank, you simply need there a safe with a lock. When it comes to securing your data, an equivalent would be encryption at-rest. In this scenario, your data is encrypted when it’s stored on the internet service’s server hard drives (or any other kind of permanent data storage devices they use). When somebody detaches a hard drive from a server, you can be quite sure your data wouldn’t be readable do them.
On the other hand, these days almost all internet services need to access your data to analyse and process it, so they need to have a proper encryption key. Using our bank metaphor - imagine that you put your money in a locked safe inside a bank, leaving the only key somewhere in the building, at hand of the bank employees. Sounds strange?
Of course that’s strange, at least for all users who care about the privacy of their data. The only solution to this dilemma is end-to-end encryption, a third kind of encryption we’d like to mention here. In this case, encryption is applied on your device (your end) even before your data is sent. Then it is protected all the way to the second device (the other end) used by your colleague, who has a decryption key. Before getting to the other end, your encrypted content can fly in the network between any number of intermediate devices, and can be stored on them, but it always remains encrypted, so nobody can read it.
Sticking to the bank example, it's like you put your money in your own safe even before taking it to the bank. Imagine leaving your own locked safe inside the bank safe. Your own key stays with you all the time, and the bank cannot access your safe's content and does not even know what's inside. It's yours and yours alone.
However - be aware that some banks may not be looking the other way when you’re setting a password to your safe. It’s probably rare, but some institutions may want to know what you are storing in their vaults anyway. The same goes with internet services - some of them (claiming to use end-to-end encryption) can know and store your password - let’s say - “just in case”. Such behaviour violates the principles of end-to-end encryption, and that’s why one can talk about yet another kind of encryption.
Zero-knowledge encryption implements end-to-end encryption along with strict password policy in which internet service providers guarantee they don’t know users’ passwords, thus have no physical possibility to access users’ content. There is still one more interesting question here - how can you be sure if they obey the policy rules? Of course, you can trust people who created the service, which is nice of you, but it may be not enough. The only solution here is looking into the application’s source code and being able to build applications by yourself.
In other words: internet service’s client application should have open source code. This is the only way you can be sure what is happening under the hood, and this is the only way zero-knowledge encryption should be implemented.
PrivMX Fusion features zero-knowledge encryption and has open source code to reassure users that everything works as it should.
When it comes to sharing data with other users within PrivMX Fusion, you choose which users have access to it on every step of the way: with the use of thematic Sections or choosing a recipient of your message/file/conversation each time. Our solution has been created along the lines of privacy-by-design approach, and we’ve been doing our best to make encryption completely transparent for end users. Only you and your colleagues are able to access your own data, nobody else. Not even us, when you are using PrivMX Cloud service. That’s why it’s impossible for us to reset or recover your password, in case you forget it.
That's how we define privacy.
Please refer to the Total privacy by design article for more details.
PrivMX Team
Lignende blogginnlegg:
What are the key ingedients in our recipe for a digital collaboration workspace? It’s been a real achievement to describe it in a single blog post, so don’t miss it. :)
This blogpost contains a recap of all PrivMX feature and system updates so far. Scroll to see digests of all historical changelogs with links to separate, detailed articles.