A storm “in the cloud”

Last month, we got (or kept) your home dumb and disconnected. Now how about the rest of your life? Do you have a contacts app that saves your contacts in the cloud, a calendar app that saves your appointments in the cloud, a notes app that saves your notes in the cloud, and even a password manager that saves your passwords in the cloud?

ʕ·ᴥ·ʔ: Yep, totally!

Do you really need that?

ʕ·ᴥ·ʔ: Well, no, but it’s nice to know that they’re there whenever I need them.

Is it nice to know that they’re there whenever bad guys need them as well?

ʕ ಠ ᴥಠ ʔ: No, no it is not.

I mean, there’s nothing wrong with keeping them there if you really want them backed up and constantly synced easily and conveniently. Backing stuff up offline can be a pain, though it’s certainly much more secure than backing it up online. So if you’re really going to keep all of those personal details about your life in the cloud, then at least secure it all to the best of your ability.

ʕ·ᴥ·ʔ: Hold on a sec. If Google Drive or iCloud or Dropbox get hacked and let my data get stolen, what could I do to secure it? I can’t possibly do security better than any of those guys. I’m just a bear!

You’re right; you can’t do security better than they can. But what you can do is: make it so that hacking Google, Apple, or Dropbox isn’t enough to read your data, by encrypting it before uploading it to the cloud. If you keep all your data encrypted in transit and in storage, then hackers wouldn’t be able to read it or get anything useful out of it, even if they were to successfully hack Google, Apple, or Dropbox.

ʕ·ᴥ·ʔ: Hold on another sec. Don’t Google, Apple, and Dropbox already transport and store my data encrypted?

Yes, they do.

ʕ·ᴥ·ʔ: Then doesn’t that mean that hackers already wouldn’t be able to read my data even if they hacked Google, Apple, and Dropbox?

No, it doesn’t.

ʕ ಠ ᴥಠ ʔ

Let me explain.

See, how does someone decrypt encrypted data?

ʕ·ᴥ·ʔ: By using the right key with the right decryption algorithm.

Right. And there are only so many (and I mean few) decryption algorithms, so the only thing that’s really protecting encrypted data is the decryption key. Now who has the decryption keys to your data on Google Drive, iCloud, and Dropbox?

ʕ·ᴥ·ʔ: They do.

And therein lies the rub: hacking Google, Apple, or Dropbox could mean stealing the decryption keys as well as your encrypted data. Encryption ain’t very useful in that scenario. And the issue isn’t just hackers; it’s governments too. Remember the PRISM Program? It included companies such as Google, Apple, and Dropbox. The US FBI and the US CIA are constantly trying to get Android’s Google and iOS’ Apple to let them decrypt smartphone data. And, again, Apple might be very good at putting up a show of respecting users’ privacy, but their actions speak otherwise.

So these companies that keep your data encrypted can also decrypt it whenever they like. That’s why I say: encrypt it before uploading it to the cloud. Make sure that you’re the only one who can decrypt it.

ʕ·ᴥ·ʔ: Okay, okay. But is there a way to do this conveniently? Like, I just let my phone automatically sync my contacts, my calendar, my notes, and my passwords to the cloud. Now I have to manually encrypt them first? There’s gotta’ be a better way to do this.

And there actually is…

Zero-knowledge clouds

The solution is to pick a cloud service provider who has “zero knowledge” of your decryption key built into their cloud service. They allow you to automatically encrypt your data yourself, and then sync your encrypted data to their cloud. They also never ask for your password, and never see it, not even to hash it. That’s why it’s called “zero-knowledge”: you’re proving to them that you have the password and decryption key to access your data, without ever revealing to them your password or decryption key. Even if they were to ever get hacked, or if governments forced them to hand over your data, your data would be encrypted and unreadable to anybody but you, because you’re the only one who has your decryption key.

ʕ·ᴥ·ʔ: Okay, that’s cool, but now I have to not just memorize a password, but carry around a decryption key too? What if I wanna’ access my data from a different computer or a different phone? I won’t be able to decrypt it if I don’t have my decryption key with me. Still sounds like a pain to me.

You won’t have to lug around your decryption key; just memorize your password.

ʕ·ᴥ·ʔ: And why is that?

Because your decryption key will be cryptographically derived from your password. As long as you memorize your password, you’ll be able to derive your decryption key.

ʕ·ᴥ·ʔ: Oh, okay! That’s cool, that’s cool. But, uh, I still don’t get one thing: how does the service provider know I’m putting in the correct username and password to give me my encrypted data, if they don’t know my password or ever see it?

Good question. If you already understand hashing, salting, and asymmetric cryptography, then you have all the ingredients to understand how a zero-knowledge proof is cooked up. There are numerous ways to achieve it, but currently the most widely used and available implementation looks something like this:

Account Creation

  1. When you create an account with a zero-knowledge service provider, you keep your super secret password to yourself, never sending it to the server. Instead, you salt and hash your password yourself.
  2. Then you use that salted hash in two more cryptographic operations: one to generate the symmetric encryption/decryption key that encrypts and decrypts your data, and the other to generate an asymmetric public/private key pair.
  3. You send the public key and the salt you used to the server, and the server stores them for you. So instead of the server storing the salt and the salted hash of your password, it’s storing the salt and your public key.

Login and Encryption/Decryption

  1. Whenever you try to log in to get your encrypted data, the server sends you the salt.
  2. With the salt in one hand, and the password in the other, you hash them together again and do the same cryptographic operations to generate the same symmetric key and the same private key.
  3. Now that you have your private key, and the server has your public key, you authenticate yourself by sending the server a message encrypted with your private key. If the server can decrypt the message with your public key, it will know that you’re really you without you ever sending it your password, even at account creation.
  4. Whenever you sync your data, you encrypt it before sending it to the cloud, and decrypt it after receiving it from the cloud, all automatically and using the same symmetric key.

ʕ·ᴥ·ʔ: Wow. All that is really cool, and really complicated. But I think I understand the most important part: my password is all I need. Hehehe.

Yes, your password is all you need. With a setup like this, the zero-knowledge service provider won’t know what your password is, won’t be able to decrypt your data, but still be able to authenticate you and store your data securely encrypted in the cloud, all while leaving your user experience completely unchanged.

Free advertising I should be getting paid for

Now that you know how zero-knowledge proofs work, here are a bunch of zero-knowledge cloud service providers who will keep your data safe and secure in the cloud (though I still say offline storage is better).

Let’s start off with the most important stuff: passwords. If you really want to sync your passwords to the cloud, you have quite a few options. Bitwarden, Dashlane, and LastPass are all zero-knowledge cloud password managers. When you use their services, they’ll have encrypted copies of your passwords, but you’re the only one who’ll be able to derive the decryption keys to decrypt them and read them.

For general cloud storage to keep all kinds of files, there are Sync.com, pCloud, and Mega.

For notes, you have Standard Notes, Notesnook, and Turtl.

For a calendar, we have ProtonMail and Tutanota for that. Soon, CTemplar will also be an option.

For contacts, we have – oh – also ProtonMail, Tutanota, and CTemplar.

And for email, we have again: ProtonMail, Tutanota, and CTemplar. If you want to securely store your emails in the cloud, they’re the ones to go to.

ʕ·ᴥ·ʔ: Just for securely storing my emails in the cloud? How about securely sending and receiving emails, or secure communications in general? I mean, communicating over the internet counts as communicating “in the cloud,” doesn’t it?

Hm, yeah, I guess so. Makes sense to me. Just like how you don’t want your cloud service providers to be able to read your data because of potential hackers or government coercion, you also don’t want your communications providers to be able to read your messages. You want only the sender and the receiver/s to be able to read the messages that are being passed around on the internet (“in the cloud”).

ProtonMail, Tutanota, and CTemplar all perform that function for you with email. There is, however, a caveat: your emails have to be sent from and received within their respective ecosystems. Meaning: only emails sent from ProtonMail email addresses to ProtonMail email addresses are encrypted in such a way that only the sender and receiver/s can read them. Only emails sent from Tutanota address to Tutanota address/es are unreadable to anybody but the sender and receiver/s. Same is true for CTemplar. If you send an email from a ProtonMail address to a Tutanota address, or vice-versa, that will be readable to both ProtonMail and Tutanota. If you send an email from a ProtonMail address to a Gmail address, or vice-versa, that’s going to be readable to both ProtonMail and Gmail.

Finally, for chat messaging, voice calls, and video calls, there are: Signal, Wickr, Wire, and – surprise – WhatsApp. It should be noted, however, that all of these services store your messages locally on your device/s and not in the cloud. Using these services, your messages only “pass through the cloud” (the internet). They are all also zero-knowledge services.

In light of that lack of cloud storage, I suppose I should mention Telegram, which is very popular and often compared to Signal and WhatsApp. Telegram actually does store your messages in the cloud, however, messages stored with them can be read by them. They’re not providing a zero-knowledge service either; they either store your messages unencrypted, or they have the decryption keys if the messages are encrypted.

Don’t you miss the good, old days, when there were no clouds or smart homes to secure and worry about?

ʕ·ᴥ·ʔ: Nope!

Okay. Guess that’s just me then.

ʕ·ᴥ·ʔ: Totally! And if you like this brave, new, internet-connected world, and want to learn more about how to secure your cool digital lifestyle, subscribe to get notified of Lambert’s new articles!

You’ll be–

ʕ·ᴥ·ʔ: You’ll be notified of new articles, and only new articles! Just submit your email address below or get his RSS feed from the menu!

ʕ·ᴥ·ʔ: That’s what you were about to say, right?