Decrypting the jargon behind end-to-end encryption

Decrypting the jargon behind end-to-end encryption

2020 was the year when encryption (and end-to-end encrypted services) became a crucial part of any company’s contingency plan. Businesses went remote, Friday work drinks migrated to Zoom conference calls and many business leaders discovered a new-found passion for sending their email attachments securely.

Naturally, this all sounded like great news to Tresorit – until we started to observe businesses discuss end-to-end encryption more regularly and realised (to put it diplomatically) that there were big gaps in the market’s knowledge around this topic.

This also made us realise that the technical language Tresorit uses to discuss encryption in our office made it difficult to understand certain concepts, which in turn made us part of the problem J

To rectify this, we did what any software company should do in times of jargon: call a meeting of technical experts, take a detailed look at our own offering (and what passes for end-to-end encryption in 2020) and report back with an overview of its terminology and concepts any budding cryptographer should be aware of.

Read below for an overview of the terminology we use to talk about end-to-end encryption, and some fun facts you may or may not already know.

What is the definition of end-to-end encryption?

The US federal standard of end-to-end encryption is as follows:

“The encryption of information at its origin and decryption at its intended destination without any intermediate decryption”

Why is this definition problematic?

The US definition has now become problematic because it is:

- Outdated

- Open to interpretation

Given the various personal interpretations of encryption floating around the market, we always stick with ‘end-to-end encryption’ as our universal go-to definition for what Tresorit delivers to its customers.

What are the different types of encryption available on the market?

To answer this question, we’re going to get a little creative (and reference an article written by Tresorit co-founder Istvan Lam back in 2016)…

At-rest encryption

Imagine that you are checking into a hotel. You’re on a business trip to deliver important documents to a client. You want to find a safe place in your room to put your documents before meeting your client for a meal. Where should you leave them?

Leaving the documents in your room is an option, but that puts a lot of weight on your trust in the hotel’s staff. It also leaves the documents vulnerable to a breach in the hotel’s own security – like a thief who makes off with a master key, or a hotel cleaner gone rogue.

The set-up we’ve described is called at-rest encryption. It is intended to prevent access to the physical infrastructure (in this case, your hotel room). With this set-up, your documents are encrypted, but the keys to unlock them are stored in the same environment, so…. easy work to decrypt should they fall into the wrong hands.

Session encryption

Session encryption provides a higher level of protection than at-rest encryption - the files are encrypted by the server, and the encryption key is stored in an encrypted format on this server for a short time.

In the unfortunate event a system using session encryption is breached, only the users online during this period are compromised (the equivalent of only having your documents stolen from your person if you happen to be in the hotel at the time of theft). So… mixed reviews from us on this one.

(Fun fact: Zoom actually sold this type of session encryption - which allowed their server to access and decrypt content - as end-to-end encryption to their customers. Lesson learnt the hard way.

In-transit encryption

One way of reducing the risk of your precious documents being stolen in transit is to find a secure channel to deliver them to your client from the hotel, like a taxi or (if you’re not looking to travel discretely) a convoy of armoured vehicles. This approach is called in-transit encryption, and functions well up until a point your vehicle gets apprehended or a weak link in your convoy is exposed.

Client-side encryption

To keep our hotel metaphor just a little bit longer, an example of client-side encryption would be a hotel room safe housed within your hotel room. Safes allow us to safeguard important documents with a code that is only accessible to the owner and the people he or she shares the code details with.

Sounds like client-side encryption is where I want to be, how do I get started?

Not so fast. There are a couple of issues with client-side encryption. First up, if you’re using a mainstream cloud solution, you have to encrypt your files before uploading them which, much like bringing a safe to your hotel room you’re staying in, is pretty inconvenient.

Another problem is the terminology of client-side encryption – which is mostly used for storage systems, not transactions. This means that the safe combination may not match up with the information that client is able to access, creating a whole new set of problems in the process.

What’s the solution then?

At Tresorit, we believe that end-to-end encryption (which you’ll see us refer to as E2EE across our site) is encryption in its purest form – and, semantically speaking, the easiest way to articulate what we provide our customers as a ultra-secure service.

What are the defining characteristics of E2EE?

We believe that a system can be called ‘end to end encrypted’ if it fulfils the following 6 criteria as much as practically possible (Tresorit disclaimer: it’s pretty much impossible to apply all of these criteria at once in a business setting, but all 6 can and should be taken into account).

1. Architecture criteria. The encryption happens between two (or more) parties, whereby the intended origin encrypts the message, and the intended destination(s) decrypt the message without being disturbed. In this case, a ‘party’ could be an organization (not just a private individual) and applies to any system which is under full control of the organization? Make sense? Great, let’s move on…

2. Key exchange criteria. If the key exchanges for your encryption are done in a way that only allows the parties (that we described above) access, then you’ve got yourself some end-to-end encryption!

3. Key generation & management criteria. Same approach, but applied to the management and generation of keys this time around. If a third party (even a trusted one) has access to these even temporarily, then your system is not end-to-end encrypted!

4. Key back-up criteria. The parties private keys need to be backed up in a format that no one else has access to. Pretty straightforward.

5. Binary authenticity criteria. The parties need to ensure that the software they are using is infection free, backdoor free and purchased from the original trusted vendor.

6. End-point authentication criteria. Both parties need to be 100% certain that the public keys belong to their respective counterparts.

How can we execute E2EE?

One of the most popular ways to execute E2EE involves with an application server in the middle. This is a set up popularized by both messaging apps such as WhatsApp and VoIP systems.

Pro tip: from the provider side, it’s crucial to ensure that there is no available access to the application server when building this type of system. Failure to secure your central routing element = bad news.

How does E2EE work for businesses?

Making E2EE work within a business environment depends on being able to control or ‘trust’ the server being used to transfer information. And… the good news is that this doesn’t necessarily mean investing in your own cloud infrastructure – 3rd party cloud storage options can be brought into play provided that the gateways to this storage are controlled by the company doing the encryption/key exchange.

One Last Thing…

We realise that not every aspect of cryptography (and what makes E2EE secure) can be distilled or described simply, and that even end-to-end encryption is still subject to very high-level definition. Nevertheless, we believe it’s important for everyone who handles confidential information (as an individual, or as part of a business) to have an overview on how to share securely.

We believe that E2EE is the best possible way to achieve this – whether you’re a legal firm or a non-profit – and we hope that this insight into our world inspires you to dig a little deeper yourself.

Kick-off your journey of discovery through our podcast archive, and stay connected to breaking news around encryption, privacy and cybersecurity through our Twitter and LinkedIn pages.