Should Your Notes Be End-to-End Encrypted?

If you use a messaging app like Whatsapp, Signal, or Telegram, you’ve probably heard the term “end-to-end encryption” or E2EE for short. But what does that actually mean? What does that actually do? Do you need it? Is it important to have in something like a note-taking app? This post is a basic overview of the most commonly used types of encryption and why encrypting as much as possible is almost always A Good Thing™ – but not quite always. Even if you’re pretty confident you understand E2EE, ask yourself the following questions:

Pop quiz
1. Can you clearly explain the difference between Encryption at Rest, Encryption in Transit, and End-to-End Encryption?
2. Did you know there are different ways to implement E2EE, and that one of the most widely used is the Double Ratchet Algorithm?
3. Are you aware that it is very difficult for you (the end user) to know if an E2EE service hasn't added any backdoors which render the encryption useless?
We highly recommend reading on if you can't answer these confidently...

Said simply, the great thing about using message apps with strong end-to-end encryption is that it ensures messages sent to your loved one, friend, or co-worker are for your eyes only. Nobody else can see the contents of the message. The people sharing the same wifi network at Starbucks can’t see the message. Your Internet Service Provider (ISP) can’t see the message. The US Government cannot see the message. Even the operators of the messaging service themselves can’t see the message. Only the two of you can see the message.

In the note-taking space, E2EE has been gaining traction because it allows you to behave as if your notes were only ever stored on your own computer, while having the benefit of allowing a 3rd-party service to back up / sync your notes for you.

That sounds fantastic in theory – who wouldn’t want that security and peace of mind? However in practice there are some fundamental requirements of E2EE that make it not quite the obvious win it seems on the surface. We’ll get into that in a bit, but first let’s talk about other types of encryption that build towards the holy grail of encrypting stuff “end-to-end”.

Different types of encryption

We’ll assume that if you’re reading this article, you know what encryption on the whole is, but we also think it’s worthwhile to run through a few specific types of encryption to give a bit more perspective on the security benefits in various scenarios.

1. Encryption at Rest – storing data

Encryption at Rest means that when data is not being actively utilized, it is encrypted. The two major examples of this would be encrypted backups and full-disk encryption.

1A. Encrypted backups

In the context of a web platform, encrypted backups are straightforward and usually apply to databases. Web platforms are built on top of databases, which should be periodically backed up offsite, to ensure that if anything ever happens to the database (like hardware crashes, accidental deletion, etc.), there’s a backup somewhere you can restore, so that all the relevant information is not lost. It’s a best practice to encrypt these backups, so that if anyone (say an attacker) ever gets access to said backups (but not the live database), they won’t be able to read the contents within — and user information isn’t compromised.

1B. Full-Disk (or Drive) Encryption (FDE)

Encrypting an entire disk also does what it says on the tin, with one slight caveat. Many modern operating systems allow you to encrypt your entire hard disk — whether it’s an old school spinning disk drive or an SSD. Then, when your computer is powered off or locked, all that information is encrypted. So, if a thief steals your laptop from your car, you’ll be out a laptop, but at least they won’t be able to access any of your sensitive information.

However (and here’s the caveat), when the computer is powered ON and unlocked, the information on your drive is not encrypted. It needs to be decrypted (and stay that way while using the system) in order for you to actually use the data. So, if you have FDE turned on but someone steals your laptop while you’re using it — for example it gets swiped off of your table at a coffee shop – then the thief will be able to access that data.

2. Encryption in Transit – moving data

Let’s go back to online services for a second: 99% of the time when you send data over the web, you’re interacting with a website and using HTTP (an unencrypted protocol) to do it. “Encryption in transit” means that when such data is sent “over the wire”, the information is encrypted between the two parties (i.e. between the user and the service they are interacting with).

This is usually indicated by appending an “S” to the various protocols used on the web — HTTP included. Which is how you get “HTTPS”, which stands for ”HyperText Transfer Protocol Secure”. Instead of doing the normal (unencrypted) HTTP stuff, you do HTTP stuff on top of an encryption layer. Historically this layer was called Secure Sockets Layer (SSL), but these days SSL is being replaced by Transport Layer Security (TLS).

In practice, this means that although people can still intercept traffic (people such as your ISP or other users of a public wifi network), it will just look like random gibberish to them. However, once the intended recipient receives it, it will be decrypted again until it is sent somewhere else via HTTPS (or another protocol). Luckily, most internet services these days force the use of HTTPS, so that’s one less thing for you to worry about.

Interlude: What we do at Supernotes

At Supernotes, we’ve spent a lot of time ensuring that both Encryption at Rest and Encryption in Transit are applied wherever we can. Our database backups are encrypted, the machines our databases run on have full-disk encryption, and any data you ever send to Supernotes is encrypted in transit using HTTPS (or other encrypted protocols). In fact, this is one reason we decided to go with a .app domain name https://supernotes.app when starting out, because .app domains are actually required to always use HTTPS. If you ever try to access a .app website with regular old unencrypted HTTP, it just won’t let you. Add all these together and you almost have E2EE. But not quite.

3. End-to-End Encryption (E2EE) – secret handshakes

But what about when you want absolutely maximum security? You never want anyone to be able to see some content — like passwords — except for you. But you still want another service like 1Password to be able to sync and store those passwords for you.

That’s where E2EE comes in.

Instead of relying on encrypting things at rest or encrypting things in transit, E2EE means that data is only ever encrypted / decrypted on your own devices (or devices of people you want to share information with). In practice, this means that the encryption keys which are used for this can never leave those devices except when you want to add a new device to this ring, at which point the keys need to be shared secretly.

So if you are sending a message to your friend via a service that is encrypted end-to-end (like WhatsApp or Signal), the message is encrypted on your computer / phone / device, sent over the wire via the third party’s servers (which don’t have access to the encryption key) and onwards to your friends device. The message is only decrypted on your friend’s device once it has reached them. In principle, this means that absolutely nobody else besides you and your friend can see what the message contained.

If you’re an astute reader, you might realize that this has actually been possible for a long time just by sharing such a secret key phrase (read: password) with someone directly. Let’s say you and your friend share the password “SuperNova11” with each other offline, while having lunch at a cafe. Later, you use that agreed-upon password to encrypt the note you want to send. Then, when your friend wants to read the note, she can type in that same password on the other end and read it.

Only people with the password “SuperNova11” can read the message, and since you haven’t given it to anyone else — that means just the two of you. E2EE achieved!

Hmmm, not so fast. After a moment of reflection, you realize that sharing passwords in person has some obvious drawbacks: firstly, it means you need to already have a secure way to communicate, whether that’s talking in person without being eavesdropped or communicating over some other system which you know is secure. Because of that, it makes it much harder to interact with strangers you’re not already in close communication with. E2EE schemes address this by using sophisticated methods of exchanging secret keys so that you (the end user) do not have to think about any of that, while still guaranteeing the highest levels of security.

The most widely applied algorithm for this is probably the Double Ratchet Algorithm (developed in 2013), which not only provides end-to-end encryption but also “perfect forward secrecy”. Forward secrecy isn’t a necessary property of E2EE, it’s a bonus feature so that even if an attacker somehow gets their hands on one of the encryption keys used for the current message, they will not be able to decrypt past or future messages with that key (as the Double Ratchet Algorithm creates a new session for every message).

The Double Ratchet Algorithm can be found in many applications these days, but most notably it’s used in both WhatsApp and Signal for their E2EE. And that’s the idea behind modern end-to-end encryption: give users the benefit of fully encrypted data that even the operator of the service can’t expose — while still being able to move that data around without the usability burden of whispering passwords to each other.

Note-taking and the downsides of E2EE

Since we think more about note-taking and knowledge management than secure messaging around here, now is probably a good time to talk about how E2EE can specifically apply to notes.

For the most part, all the same ideas apply. You have some content — notes — that you want to ensure nobody can read but you (and people you trust). Again, the simplest way to do this is with a password, with which you encrypt the notes on your computer, and any time you want to access them you decrypt them with the same password.

This can be an effective strategy, but as mentioned before, using passwords like this will make it much harder to share information with people or devices that are not already part of a secure communication channel and places the burden of remembering all these passwords on the user. A better strategy is for the software that you are using to write the notes to automatically create passwords (called “keys” in this context) for your notes.

Either way, your notes are now end-to-end encrypted, which brings us to the sad part of this story: the downsides of E2EE.

Loss of data

The first downside is somewhat obvious — if something happens and you lose access to the encryption key(s) used to encrypt your notes, you’re outta luck. That’s why when you start using an E2EE service, they always tell you to copy down one or more recovery keys into a very safe place (which if you’ve used any cryptocurrencies in the last few years should be a familiar process). If you don’t back up that key properly and, say, your computer dies — your notes will be gone forever. Nobody will be able to help you get them back (by design).

Ease of Access

An important part of having notes (especially compared to messages) is being able to access them whenever you want and to add to your collection wherever you are. At the most basic level, this means accessing them on all of your own devices. But sometimes it means accessing them on devices that aren’t yours, such as a work or school computer or a friend’s phone. With E2EE, this becomes more difficult, because you need to have some way to get the encryption keys from your existing devices onto this entirely new one. That’s why, if you’ve ever used the Signal app, you may’ve been frustrated when you signed in on a new device and can’t access previous message history. That forward secrecy property we mentioned earlier can be a bit annoying if it’s you that wants to access old data.

Collaborating with Others (and 3rd-party integrations)

When it comes to collaboration in 2022, obviously “share a password with each other” isn’t a great solution. So, any E2EE apps you use should be managing keys for you – synchronizing them between devices in the background.

However, this becomes a serious stumbling block if you ever want to allow a third party access to your content. For example, let’s say you want a new note to be created/updated in your collection every time you bookmark a tweet. In order to update that note you would need to disable E2EE (at least for that specific note), otherwise changes could not be made. Now you have some notes on your system that are encrypted and some that are not, and the developers of such a system would need to ensure the two things are delineated clearly, otherwise you end up accidentally exposing sensitive content that you thought was secure. Add bi-directionality to your integrations and this becomes even more of a mess.

Safety (Fighting Abuse / Spam / Phishing)

Taking the concept of publishing your notes one step further, another issue that needs to be considered is what you do if the notes being published are actively harmful. Any platform which allows publishing has to contend with the possibility that a malicious actor will use the platform to attempt to publish harmful content, whether for the purposes of abuse, spam, or phishing. As an example of this, a few months ago at Supernotes we had to deal with a malicious user that was trying to use Supernotes to trick people into handing over their Microsoft account passwords. Luckily we were able to detect this activity before anyone was duped, but if we had been enforcing a strong E2EE policy we would’ve had no way of knowing this was happening until an affected person let us know.

In the end, trust is Still Required™

The final (and probably most important) thing to note about E2EE is that it’s really hard to do correctly. Like really, really hard. Even when it is being implemented by people who can 100% do it correctly (of which there are not many, by the way), it is nearly impossible for you (as the end user) to know if that service hasn’t placed any backdoors in the code which render the encryption useless.

The app that you’re using isn’t supposed to send your secret keys anywhere except to your other devices (again, that’s effectively the central tenet of E2EE). But in reality, there are a dozen ways this could change at any moment — and usually it would be very hard for you to detect such a change. The most obvious method: the creators of the app add a backdoor. But there could also be a vulnerability introduced into a dependency used by the app that they accidentally overlook and presto – keys compromised. Unless the app is open source and you are checking every dependency the software uses and you are either personally building the app from source code or the app uses reproducible builds (and you’re verifying the hash every time there is an update), you just won’t know.

Our app, Supernotes, is not E2EE

These reasons are why Supernotes cards are not end-to-end encrypted. Although the privacy benefits can definitely be worth it, the associated difficulty both from a development perspective and from a user convenience perspective are too great given our current set of priorities.

We want to give our users peace of mind that their notecards will always be accessible, without placing the onus on them to maintain recovery keys or else. We also want users to be able to seamlessly collaborate with anyone (or 3rd-party platforms like our recently announced Raycast extension) without fragile key exchange systems that can break in so many ways.

That’s why, if you have truly sensitive information that absolutely should never be seen by anyone else (like passwords), we highly recommend storing it somewhere that is purpose-built for that use case (and preferably audited to prove it) like a password manager, which is designed to make the necessary tradeoffs to ensure security.

In fact, most content apps you use are not E2EE

Until the Signal protocol was developed and integrated into the Signal and WhatsApp messaging apps, very few consumer-facing apps used E2EE. Even now, it is mostly the purview of messaging apps. Content-based apps like Google Docs or Notion are not E2EE and probably never will be. Neither are any of your Slack messages. Your emails most likely aren’t encrypted, though a few providers (like ProtonMail) are doing their best to get E2EE working alongside the existing email protocols, with some large caveats (e.g. with ProtonMail you cannot use your own favorite email client and need to use theirs).

Please note: just because these services are not E2EE does not mean that nothing should be. The point is merely that most content benefits more from accessibility and usability than from the very high levels of privacy provided by E2EE. Most content you create every day is not passwords, trade secrets, or your deepest darkest desires.

Never Say Never

Having said all that, we at Supernotes can definitely understand how managing all your content — both secure and non-sensitive — under one roof can be a very useful property. So we aren’t against the idea of having E2EE enabled on specific Supernotes cards in the future. If that happens, it is very important to us that such a feature is developed very deliberately and thoroughly to ensure none of the above issues arise, which as mentioned would be a highly involved process. Our preference in the interim would be to integrate with other services where this is the top priority and therefore are that much more likely to do it right. But for the moment our small team (still only 2 people!) wants to focus on making the user experience as solid as possible, so that our users can just get on with taking notes.

We hope this article helps you form a better understanding of E2EE. If you’d like to learn more about encryption we recommend reading Real-World Cryptography. And if you haven’t tried Supernotes before, please give it a go and let us know what you think! Have any further thoughts? Get in touch with us over on Twitter, @supernotesapp or send us an email, info@supernotes.app