What's Encryption?

How developers protect sensitive data

This is a guest post from Shane at Evervault. If you’re in the market for software to help you with encryption, check them out.

The TL;DR

Encryption is one of the ways that developers protect sensitive information, like credit cards or social security numbers. 

• Sensitive information is important in many of the apps you use every day, but it’s dangerous to store and use unprotected

• Encryption has existed for thousands of years as a way to communicate securely, and it’s the main way developers protect sensitive info today

• You can do encryption yourself, and most developers do; but it is easy to mess up the implementation, and most developers aren’t security experts

• You can use an encryption platform to outsource your data security, think Stripe for encryption

Privacy is important

Privacy is everything these days. In a world of ever-increasing amounts of data, customers want to know that their data is safe, businesses want to avoid the financial and reputational damage caused by data breaches, and governments are passing sweeping privacy-focused legislation. A clear trend is emerging: businesses that design their services around privacy are more likely to succeed than those that don’t. 

To put the problem into perspective, the average data breach cost in 2021 was $4.24 million, an all-time high. The World Economic Forum concludes that 95% of all data breaches are attributable to human error. Protecting sensitive information with things like encryption help prevent breaches and keep your data safe.

Here’s how encryption works

You may not realize it, but encryption is everywhere, from sending a text, to using an ATM or buying something online. And it’s been around for a while (dating back to 600 BC!). Julius Caesar devised his own encryption scheme by shifting letters: A becomes D, B becomes E etc. 

‘Hey Brutus, super excited for the Senate meeting tomorrow. It’s the Ides of March and I can’t wait to celebrate with my closest friends. I really just want it to be the perfect day!’ 

This is the plaintext version. To keep this a secret, Caesar then uses a cipher to encrypt this message into a seemingly unintelligible form called ciphertext.

‘Khb Euxwxv, vxshu haflwhg iru wkh Vhqdwh phhwlqj wrpruurz. Lw’v wkh Lghv ri Pdufk dqg L fdq’w zdlw wr fhoheudwh zlwk pb forvhvw iulhqgv. L uhdoob mxvw zdqw lw wr eh wkh shuihfw gdb!’

Caesar ciphers are still used today in some Welsh towns.

This is a simple way to send secret messages, but there’s a problem. In Caesar’s message, he used a shift of 3 letters (the key). Now, with 26 letters in the alphabet, he could have used any option between 1 and 25. But any Roman with enough time, or a big enough abacus, could crack the code by brute-forcing it: trying every possible shift of 1-25 and eventually decoding the message, ruining an otherwise lovely Ides of March.

So Caesar’s encryption was decent, but far from foolproof. Encryption schemes can get arbitrarily complicated, going well beyond a letter shift here or there. And that’s where modern cryptography comes in.

Developers use encryption to protect data

The principles of encryption today are fundamentally the same, just more sophisticated. We noted above that you could brute (Brutus?) force Caesar’s cipher — something that today would take seconds with a computer. But, there’s another issue: how does the receiver know what the key is? If you got Caesar’s message, how would you know how to decode it? That requires a plaintext communication (explaining to your recipient what the code is), which is easy, but not secure. 

Cryptographers have two solutions for these problems:

1) More encryption!

The standard today is 256-bit encryption. So, rather than just a range of 1-25 (the letters in the alphabet), it’s a range of 2 ^256. That’s something an abacus, let alone today’s most powerful computers, can’t handle.

2) More keys!

Today, developers use what’s called asymmetric encryption. There are two types of keys: a public key and a private key. The public key can be shared with anyone and is used to encrypt messages. The private key is kept secret and is used to decrypt the messages that were encrypted with the public key. Only someone with access to the private key can decrypt the message.

This idea of asymmetric encryption generally started to pop up in the late 70’s, and is now the standard way encryption is done across the web. 

It’s not perfect though

Anybody who has the ciphertext and doesn’t have the key can’t access the original data. However, anybody who steals the key and ciphertext now has access to all of the original sensitive data — as if the encryption wasn’t even there. The key is just as sensitive as the original sensitive data and must be treated as if it was the original secret you were looking to keep safe. Just like a key to a safe. 

So, encryption isn’t perfect. Still, encryption has its superfans, including Werner Vogels, Amazon’s CTO. Werner has been wearing this t-shirt at every conference for the past three years. 

Only slightly disappointed this t-shirt isn’t actually something like ev:Tk9D:in0+WDhHs2cpetd/:AqaGHmNI8XCxO0S9pAQDusU+rwf6WpIrM9wM0xbAXYFM:fKKW==:$

As the founder of an encryption company, I’m obviously Team Encryption™ – but it does have its drawbacks. It's not a trivial thing to implement encryption properly. Although most developers will have at least some expertise, true experts are few and far between.

Ideally, you want to build your security systems on zero-trust models, where you only ever put your trust in things that can definitely prove their trustworthiness. Definitely here means ‘by the power of math’. The problem with in-house encryption is that you can’t always (mathematically) trust yourself or your developers. 

When you can’t (mathematically) trust yourself

 More broadly, implementing encryption properly is hard. You have to:

1. Pick which open-source library to use (and ensure it is well implemented and tested!).

2. Generate and store the keys yourself (and deal with all of the “gotchas” involved in handling keys — generation, storage, rotation, deletion and more).

3. Still handle sensitive data in plaintext before encrypting it.

4. Decrypt the data every time you want to use it.

Even with just these four steps outlined, encryption is frequently implemented incorrectly. Worse still, in most cases implementing encryption the wrong way isn’t better than having no encryption at all.

So, what’s the solution?

So, encryption is super important, but easy to mess up. Should we all just not bother? This quandary is the reason why encryption platforms like Evervault exist. An encryption platform combines the security of encryption with the ease of use of any other provider like Stripe or Twilio. With this model, you store your data, and the platform stores your encryption keys. That way, you don’t have to worry about key management or implementing complicated encryption schemes. 

Take this

You might be thinking, wait. Am I not just offloading my users’ most sensitive data to an encryption platform? What happens if they get hacked? With an encryption platform model, users store encrypted data, but not private keys. The encryption platform stores private keys, but not encrypted data. This way, if the encryption platform or one of its users gets hacked, all the hacker would get is a bunch of worthless ciphertexts. In order to steal real private information, they would have to successfully hack both the encryption platform and a client at the exact same time, which is theoretically possible but exponentially less likely.

Appendix

Why not tokenization?

Technically reader Sam asked: “Any POV on why encryption is more popular than tokenization? It sounded like tokenizing is more secure and easier to use so was kind of surprised at the last bullet.” This is for you, Sam. While tokenization has its advantages, it has two critical weaknesses:

Trust 

Tokenization is not a zero-trust model. It requires you to place your trust in a tokenization provider, who isn’t verifiably trustworthy. Ultimately, all tokenization does is move the problem. Human error causes 95% of data breaches. Tokenization providers are just as human as you. If a tokenization provider were to fall victim to an attack, then that hack would expose all of the private user data they store.

Latency 

All storage or retrieval operations must occur through the tokenization provider's API. This added latency slows down your app, causing pain for your users.