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 every company’s contingency plan. Businesses went remote, Friday after-work drinks migrated to Zoom conference calls, and many business leaders discovered a newfound 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 realized (to put it diplomatically) that there were big gaps in the market’s knowledge about the technology.

This also made us realize 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.

To rectify this, we did what any software company should do when confusing terminology starts spreading: call a meeting of technical experts, take a detailed look at our own offers, 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 know already.

What is 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”

While undoubtedly its creators are driven by the best intentions, the traditional definition of end-to-end encryption just makes things more complicated. Why? It conveniently avoids the questions of data storage security and the encryption of files stored on hard drives and servers before or after the file transfer itself. The aspects of data at rest – as your security analyst would call it. But ask yourself: would you consider a supply chain end-to-end secure if only the cargo trucks were locked (the transmission of goods/data) and not the warehouses (storage)? That's why we clarify things first when we want to define end-to-end encryption.

Why is this definition of end-to-end encryption problematic?

The US definition has now become obsolete because it is both outdated and 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.

Main encryption types: symmetric vs. asymmetric encryption

At its core, digital encryption is a set of tools or algorithms and protocols your company uses and follows to protect its digital valuables while communicating with clients or colleagues. For this reason, you have to choose a cipher that turns your data into an encrypted message that can only be read by the parties with the decipher key – the partners you want to share your information with. Nowadays, for data encryption, the two primary forms in use are symmetric and asymmetric encryption. The first one is a single-key technique, while the other operates with private- and public-key pairs to increase security measures.

Sounds unfamiliar? If you’ve ever opened an Adobe PDF with a password or used a form on a website with HTTPS protocol, then – even though you were unaware of this – you actually enjoyed the benefits of these two encryption methods. Fun fact: probably simultaneously and a few hundred times back and forth in just a few seconds!

To fully understand how state-of-the-art end-to-end encryption solutions – like Tresorit – keep your most valuable data safe in practice, we’ve collected the differences between symmetric and asymmetric encryption processes. You will see how they work, what their capabilities are, which one is better for securing your sensitive data. And we’ll also let you know why you don’t have to choose between them anymore at trustworthy providers.

What is symmetric encryption, and how does it work?

Symmetric key encryption is one of the oldest encryption techniques in the world. Julius Caesar used it to send messages to his troops in ancient times, but it is also how Enigma coding machines worked in WW2. Its working principle is simple: the sender encrypts the intended data with a cryptographic key on their side before transfer. The receiver then uses an identical key to decrypt the data/information they received. In the past, this was done by changing the letters of the alphabet or replacing them with numerical references pointing towards a letter on a specific page of a book, for example. Nowadays, for symmetric encryption, we use complex mathematical equations or algorithms to make data unreadable. The sender and the receiver will use the same key to make the data readable.

Just like real keys, their digital encryption counterparts can come in various forms and shapes. The more complicated the key, the more secure the lock is. The same happens when we encrypt data with a symmetrical key. To turn plain text into ciphertext, we can choose from keys with different lengths – 128, 192, or 256 bits.

Symmetric encryption is still widely used on a daily basis in different industries: IT, military, aerospace, healthcare, or banking.

The most widely used example for symmetric key encryption is Advanced Encryption Standard (AES), while the most outdated is Data Encryption Standard (DES).

While its simplicity gives strength to symmetric key encryption, its greatest weakness is the fact that you have to send the secret key to your partner to establish the communication.

What are the advantages of symmetric encryption?

The advantages of symmetric key encryption come from its relative simplicity, but mostly it is praised for its security and speed benefits.

● It is faster to execute – the keys are shorter as opposed to asymmetric encryption, so it does not require substantial computing capacity.
● For the same reason, it has lower resource requirements.
● It's widely known and has been used for decades.

What are the disadvantages of symmetric encryption?

Using one secret key to encrypt your sensitive data may make things convenient, but it might also jeopardize the trust of your customer indefinitely at the snap of a finger. How? If your secret key is stored in an insecure location – a computer without an adequate firewall, cloud storage with vulnerabilities – then it's an easy target for hackers. And if someone accesses your key, they can read, alter, or hijack every single bit of your sensitive information.

Furthermore, a hacker can intercept your transmission if you send data to two geographically separate parts of the wold via the internet. If the single key you use for encryption is also transmitted, the communication can easily be compromised. It’s a loophole that creators of ransomware software love to exploit. It is also easier to decrypt symmetric encryption by another hacking method called “brute force”.

That's why encryption keys should be secured both when data is at rest and also when it is in transit. So, it’s time to introduce a new concept: authorization, which takes us to our next encryption method – asymmetric key encryption.

What is asymmetric encryption, and how does it work?

Asymmetric encryption's greatest virtue is in understanding that one shared key for the encryption-decryption process of information is a significant threat to security. So instead of using one key, asymmetric encryption uses multiple keys in the process of encrypted data transfer. These are what we call public- and private key pairs, which are mathematically related to each other. By using these, information can be encrypted and decrypted back and forth in a way that the sender and receiver can both keep their own private keys. The receiver of the message sends their public key to the sender so that they can encrypt the intended message/data, and once the message is received, the receiver will use their private key to decrypt it. Compared to symmetric encryption, only the public key is sent through a communication channel. Even if a hacker intercepted the transmission, no data would be compromised, as they would still need the private key to turn the ciphertext into plain text.

Sounds complicated? Here's a simplified scenario of how it works.

‘Company A’ wants to send private data back and forth with ‘Company B’ using asymmetric key encryption. The first step, ‘Company B’ – the receiver – will send their public key, which ‘Company A’ will use to encrypt the message/data. After receiving the encrypted data package, ‘Company B’ – and ‘Company B’ only – will be able to decrypt the information with their own private key. The private key cannot be derived from the public key even though they are mathematically related. With asymmetric key encryption, the calculations behind the encryption are so complex that it makes the data inaccessible to a hacker due to the time and resource requirements to obtain and decode both key pairs.

The most commonly used examples for asymmetric key encryption are Rivest Shamir Adleman (RSA) and the Diffie-Hellman exchange method.

The complexity provided by using private and public keys makes asymmetric encryption an ultimate asset for authentication, a cornerstone for creating a secure communication channel between various parties. After all, if a hacker can intercept the communication between two separate parties, they can not only obtain the information in transit, but they can easily take over the receiver's identity in the dialogue without anyone noticing it. We can use asymmetric encryption methods for authentication to prove without a doubt that the parties involved in the data exchange are who they say they are.

What are the advantages of asymmetric encryption?

● It is a good asset for authentication and digital signature – with the use of a private key, the sender and receiver can verify that they are who the communication is intended for. Any kind of message or data can also be encased with a digital signature to prove that the received message has not been tampered with. It can be used to authenticate the sender, the receiver, and the message as well.
● With asymmetric encryption, there's no reason to share private keys – they can be securely stored on our own computer or even in key vaults.
● It adds an extra layer of security. Even if a public key is exposed, no one can derive the private key from it and cannot decrypt the message.

What are the disadvantages of asymmetric encryption?

The main disadvantages of asymmetrical encryption are related to speed – more precisely, the lack of it. While more complex encrypting calculations mean extra security, they also mean more significant computing resources, longer ciphertexts, and more time to complete the process.

Another disadvantage is the matter of storing your private keys safely and maintaining digital certificates. If you entrust a third party to store your keys, you cannot be entirely sure if this is done securely or not.

A third disadvantage is the fact that public keys are indeed public. Without properly designed countermeasures, anyone can claim that a public key belongs to them, impersonating the original recipient. This is what happens in man-in-the-middle attacks.

That's why neither the less secure symmetric encryption nor the more resource-demanding asymmetric encryption is used on its own in most cases. Instead, cybersecurity experts have found a way to combine their best features. Asymmetric encryption is used mainly for authentication and digital signatures to establish secure communication sessions and to create authentic messages, and symmetric encryption for fast and secure mass transmission of information.

What encryption types are available on the market for business purposes?

To answer this question, let’s take a closer look at the primary forms of encryption — encryption at-rest, session encryption, in-transit encryption, client-side encryption, and their capabilities and industry adaptations. With the purpose of making the topic even more understandable, we opted to use an article written by Tresorit co-founder Istvan Lam back in 2016 as a reference.

At-rest encryption

From a traditional data security standpoint, it is tempting to only focus on security measures when your sensitive digital valuables are in motion. But how secure is your data at your company’s servers after dispatch? That's where data encryption at rest will be essential. It's a collective concept for the encryption process made by the server after they get the information. So, for example, when you write a message on Messenger, the text will be forwarded to Facebook, where they store it in some format for the purpose of archiving, in case you later want to reread something.

Not a big deal, right? Unfortunately, hackers think otherwise. Their logic is simple: if something is worth storing, it must have value. And business-critical information has a lot of value. That is what makes at rest encryption critical for sensitive business or personal data. As a proactive solution, you can encrypt your data before transmission, but we still need to make sure that the receiver is completely transparent about how they encrypt the data when storing it and how they treat data in use.

Takeaway: if you want to share files securely inside and outside your organization, choose a transparent partner who discloses the security measures in place throughout the whole lifecycle of data processing.

Here's a simplified example to understand 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 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 to decrypt should they fall into the wrong hands.

Session encryption

Session key encryption provides high-level protection to a communication session between two servers that share data.

A session essentially works just like a conversation with someone on the phone by saying, “Hello, my name is John Doe; am I speaking to Jane Doe?” Once we have made sure we are talking to the right person, we start sharing information. The server and the client will start a process similar to the above by exchanging digitally signed identity information, pre-master secrets and then agree on a symmetric session key through asymmetric encryption to ensure the identities of both parties during the transmission, thus establishing a secure channel. A session might last until the intended transfer is completed or until the communication is interrupted for a while. Finally, the server and the client can close the dialogue formally. This is basically how an SSL/TLS handshake works.

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 learned the hard way.

In-transit encryption

In-transit encryption's task is to secure your data in motion while your company is on the network (internet or dedicated network). Since the easiest way to compromise data in transfer is via the internet, proactive protective measures in this field are crucial for business safety. To increase security, enterprises need to make an educated choice whether to use a private network or a public one. In addition, they should be aware of the kind of encryption that is being used on the internet – SSL, HTTPS, TLS, FTPS, etc.

A little clarification with the previous hotel example

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 armored 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

One of the most effective – yet unjustly overlooked – data protection methods you can choose on the market is client-side encryption. With this technology, your sensitive digital assets will be encrypted on your computer prior to data exchange. That means your valuable data is fully encrypted from the start, and other encryption processes (encryption in transit, encryption at rest) add an extra layer of security on top. While from a security point of view this is undoubtedly the best option, there are also some downsides you should consider.

Firstly, the human factor. If your company wants to use client-side encryption properly, your employees will need specialized IT knowledge. Human error is the most common source of data breaches in the world of IT security – therefore, an issue you should pay attention to.

Secondly, human and usability factors. Although client-side encryption is great for data security, when applying it to your emails or documents intended for sharing, things get complicated. Most business documents and files are shared either within the company or with external partners. A team might use a shared drive (e.g., Box, Google Drive, Dropbox) to enable collaboration. So, the following question is inevitable: how do you maintain security measures when sharing files with specific individuals while enabling editing and downloads and still ensure effective workflow and usability? Assuming you don’t want to use complicated methods such as learning how to encrypt your own emails via PGP, you can try specialized solutions that combine usability with maximum data security, just like we do at Tresorit.

Turning back to our hotel example once more

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 we should clarify. 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 the 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 an ultra-secure service.

What are the defining characteristics of E2EE?

We believe that a system can be called ‘end-to-end encrypted’ if it fulfills 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. The 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 backup 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 an application server in the middle. This is a setup 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 end-to-end encryption 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.

This makes end-to-end encryption an ultimate tool and an invaluable asset for your company. When you use a transparent 3rd party solution with end-to-end encryption, your files will be safe whether you choose to store them or share them with your team and your partners. With Tresorit’s most advanced capabilities, you can share or revoke documents with a few clicks, set expiry dates for shared files, and more – thus establishing the best security for files intended for sharing from the very beginning.

One Last Thing…

We realize 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.