paint-brush
Encryption Types Explained with Game of Thronesby@Rebecca_Z
968 reads
968 reads

Encryption Types Explained with Game of Thrones

by Rebecca SommerJuly 3rd, 2017
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

One question we hear regularly is: Why do I need your <a href="https://hackernoon.com/tagged/encryption" target="_blank">encryption</a> service? My cloud provider offers encryption, too. And so far, nothing happened to me or my data.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Encryption Types Explained with Game of Thrones
Rebecca Sommer HackerNoon profile picture

Is your data in the cloud as secure as you think? Understand different types of encryption to find out for yourself. And why not use Game of Thrones for that.

One question we hear regularly is: Why do I need your encryption service? My cloud provider offers encryption, too. And so far, nothing happened to me or my data.

Well, it might be true that your cloud offers some type of encryption to protect your data. But do you know what data is encrypted, at what time, and in which way? To put it in terms of Game of Thrones: When Daenerys, Tyrion or Arya Stark move through Westeros and Essos, you probably also would like to know whether they are secure, alive and well.

Is Your Wall High Enough?

One more question brings us to what’s at stake here: Why do you think your sensitive data, or your friends, or business partner’s data deserves less protection than a fictional character in your favorite TV show? Well, one answer could be, because data is abstract and because the threats to your data are more hidden and less obviously scary than everything that happens in Game of Thrones.



Samwell Tarly: “The White Walkers sleep beneath the ice for thousands of years. And when they wake up…”Pypar: “And when they wake up… what?”Samwell Tarly: “I hope the Wall is high enough.”

Encrypted does not mean secure per se. Chances are high that your cloud provider does offer encryption, but not at all times and not in a way that makes sure that in no scenario anyone could ever access your data. This article shows how to differentiate between different types of encryption with examples from Game of Thrones. Learn how to build a wall that is high enough to protect your data from most of the threats out there.

Spoiler alert: This article contains spoilers about Game of Thrones. Specifically, one about the death of a character at the end of Season 1 and one about the fact that a certain character surives all 6 seasons up until now. If you do not want to know, skip the end-to-end encryption and hashes chapters. 😉

Encryption Types — Knowledge is Power

When a service assures you that your data is encrypted, you should still have a look at the fine print. There is a big difference between encryption at rest and end-to-end encryption, for example. With this article we explain the most important terms that help you make an informed decision about the security of your data. Afterwards, you can decide for yourself which level of security you want to employ for your cloud. You will notice that even though encryption is a complex system, it is understandable for everyone, especially when explained with Game of Thrones.

The most important terms in cloud, messaging and online security are end-to-end encryption, encryption at rest and in transit, zero knowledge encryption and hashing. Thanks to WhatsApp, end-to-end encryption is probably the best known encryption term at the moment. Read on to find out what it actually is and what it has to do with Tyrion Lannister.

End-to-end Encryption — Your Data Will Survive Everything, Even the Game of Thrones

End-to-end encryption means that a message is secure from the moment it leaves one realm until it reaches its destination. Imagine the brave Tyrion Lannister delivering your message. He has guards and companions that protect him on the journey from one realm to the other. This protection is not penetrable by any threats known today. Nothing that lingers on the roadside between origin and destination can defeat him. When he reaches the castle, the message stays protected as well, Tyrion and his companions do not abandon it until it is brought to the one true intended receiver.

Since Tyrion survived all seasons of Game of Thrones so far — which in itself is a great achievement — he is impossible to break in the world that we know today, just as the very secure end-to-end encryption.


In the words of Wired:“That “end-to-end” promise means that messages are encrypted in a way that allows only the unique recipient of a message to decrypt it, and not anyone in between. In other words, only the endpoint computers hold the cryptographic keys, and the company’s server acts as an illiterate messenger, passing along messages that it can’t itself decipher.”

Well, what is the threat level here? It is actually very low. If your messenger uses end-to-end encryption you can rest assured that no one can read along, not even the provider of the service.

The problem is that end-to-end encryption is not really available for cloud storage, it is an encryption system for messages. WhatsApp and many other messengers, such as Threema, Signal or Wire, offer end-to-end encryption for messages. However, the commonly known cloud providers — Dropbox, OneDrive, Google Drive or iCloud Drive — use other encryption types. If you share data via link in your cloud, it is not end-to-end encrypted either.

A cloud-based option to share data in Dropbox, OneDrive or Google Drive with end-to-end encryption is Whisply. It adds your very own Tyrion to your cloud links, thus making them more secure.

Encryption at Rest — You are Secure in Kings Landing, as long as the Queen is on your side

Encryption at rest is what some cloud providers offer their clients per default, sometimes for private and free cloud storages as well, but sometimes only starting with the paid version. It means that the cloud provider encrypts your data as soon as it reaches your cloud, aka their servers.

Imagine it like a vault where Daenerys hides her precious dragon eggs from someone who tries to steal them, such as her jealous brother Viserys. The problem with encryption at rest is that Daenerys only rents this vault from someone else, let’s say the Iron Bank of Braavos. The provider of this vault, The Iron Bank, is offering her encryption. Thanks to the Iron Bank, an outsider with an interest in harming or stealing the eggs would not be able to access this vault, only if he or she managed to steal the key for this vault (the password) from Daenerys herself.

However, Daenerys is not the only one with a key to this vault. The Iron Bank that rent her this vault has a key, too. If someone with more power comes knocking, the Iron Bank could be forced to hand out the key.

In reality this could be authorities in the USA that refer to the PATRIOT Act. This comparison is a striking one in another way: The dragon eggs symbolize Daenerys’ power and authority. In our digitalized and globalized world, data is power, too. Whoever controls the data is in charge. Daenerys fights to preserve her power and we, the users, should too.

Encryption in Transit: Your Data is Secure During Travel Time

Tyrion Lannister is again delivering your message or your data, and nothing can hurt him during travels from one realm to the other. However, you do not really know what happens to your data once it reaches its destination. Tyrion just hands it over to somebody else.

This means that combining encryption at rest and encryption in transit does not give you end-to-end encryption or zero knowledge encryption, because there can be a weak point between arrival of the data and encryption at its destination. Tyrion delivers your message securely to its destination. Here, a guard takes over and puts the message into the vault. However, at this point, he could read the message, copy it, or make a copy of the key that locks the data away so he can access it whenever he wants. This would also be a great moment to let governments and authorities have a peek, if they request it.

Zero Knowledge Encryption — Or Bring Your Own Dragon

Zero knowledge encryption resembles end-to-end encryption in terms of security. If you have end-to-end encryption for your messages and shared cloud links, as well as zero knowledge encryption for your cloud, it becomes very unlikely that something happens to your data. Imagine Tyrion Lannister with his companions as well as Daenerys and her dragons watching out for your data. All good, right?

Let’s go back to Daenerys protecting the vault. By now, her dragons have hatched and they are her superpower. Since she does not want to trust the Iron Bank to never betray her, she brings in her own dragons that let nobody but her into the vault. Those dragons only listen to their Mum Daenerys, right?

The same applies to zero knowledge encryption. It gives you the power of full control. No one but you can access the vault, because you bring your own protection, aka BYOD, Bring Your Own Dragon. Everything is encrypted at every point in time and nobody but you knows your password, because it is hashed before it even leaves your device.

An additional encryption solution for your cloud, such as Boxcryptor, protects your vault at the Iron Bank of Braavos like Daenerys’ dragons would guard what is most precious to her. So if you have dragons at hand to protect what is our hidden superpower in our digitalized world — our data and our right to privacy — why not use it?

Hashes and Salt — Or About Storytelling and Causality in Game of Thrones

Hashes are an important element of data security. A common use case for them is to protect passwords of users when they are stored in a service’s database, another use case is email signatures.

This is how a hash is created: A word, sentence, or any kind of data is entered into a hash function. This hash function transforms the data into a seemingly random assembly of characters or numbers, but with a fixed length. The output will always be the same for the same input. However, if you just change the input slightly, the hash will be completely different. What’s important is, that you cannot calculate back what the input was when just given the output.

Try to imagine it with the plot and storytelling of Game of Thrones. Imagine you join the series in a couple of weeks at the beginning of season 7, with no previous knowledge. Unless the story offers flashbacks, you will not be able to tell how everything led to the current situation in Season 7. The current situation is the output (the hash) and you cannot derive the input — everything that happened up to that point — from this single point in time.

However, if you just changed the story a little bit in Season 1 — let’s say Ned Stark had survived — the output probably would have been completely different, just as with a hash function.

Since we are not in Game of Thrones but in the very real field of IT-security, there is one big problem with the fact that the hash for a certain value is always the same. When a database with hashed passwords is hacked and 200.000 users have the same password, the hashes will be the same as well. If the hash for this password is known — if you use “Password” or “123456” chances are high — then the hash does not protect the password anymore. The solution to that: Salt and Pepper.

Salting means that you add another component to the password, for example the email address of the user and some application specific string, and then you hash those components. Since it is very likely that the combination of your password, the application specific string and your email address are unique, an attacker cannot just take the hash and google it to get your password. He has to try all his password guesses anew for your hash — and this just costs way too much time. Pepper is a further protection mechanism — no kidding, they really call it that way — that adds another term to the input in the code. This term is stored somewhere else than in the database, so that hackers will not get a hold of it when robbing the database. And without it, they cannot check if their password guesses are right — making everything even more secure.

This is how we do it at Boxcryptor, for example. Your passwords are hashed, salted and peppered. To achieve zero knowledge — remember, we do not know your password — the password is hashed right on your device before it even reaches our servers. It is hashed once again on our servers for storage, just to be sure. This way you can be authenticated by a service, without them knowing your password.

So when a service you use writes that they protect your passwords by hashing them, you better hope — or ask if — they add some salt and pepper first.

A breach is coming. Encryption by clouds

We do not want to keep you much longer. Here is a short comparison of which cloud provider uses what kind of encryption. If you already know all that feel free to scroll down to the end of the page right away.

Dropbox

Google Drive personal accounts

  • Encryption in transit: “All transmissions to and from your device using HTTPS and TLS.”
  • Encryption at rest: apparently not. So better encrypt your Google Drive data yourself and add some dragons.

Google Drive for Business

  • Encryption at rest just as in the Iron Bank of Braavos. But better bring your own dragons, especially if you operate with business data in Europe.

OneDrive

  • “We have implemented and will maintain appropriate technical and organizational measures intended to protect your information against accidental loss, destruction, or alteration; unauthorized disclosure or access; or unlawful destruction.” (Privacy Statement for Online Services). Either have trust that what Microsoft deems appropriate is good for you too, or bring your own security.
  • OneDrive Business: Encryption at rest and in transit.

Amazon Drive and Prime Photos

  • “You are responsible for maintaining appropriate security and protection of Your Files.” (Terms of Use). Ok, got it. I’ll bring my own dragons.

iCloud Drive

  • Encryption at rest aka the Iron Bank of Braavos. But definitely without the dragons.
  • Encryption in transit with SSL/TLS.

Support us by sharing or recommending this article. Help us spread the knowledge and help others to understand encryption so that data security and privacy in the cloud and in communication become the norm one day.