Standard Notes is built on top of an encryption library we built to ensure an independent, trustless, and self-hostable architecture. Our specification is open-source and audited, and describes how to encrypt, decrypt, and sync data with Standard Notes.
When you register, sign in, or read or write notes, we use this library to authenticate your session, generate your encryption keys, and turn your keystrokes into gibberish through encryption.
Each Standard Notes account has an encryption version associated with their account. The version describes the set of steps required to generate encryption keys and encrypt data. Like any software system, upgrades are issued over time to address improvements and vulnerabilities alike.
A security update inside of Standard Notes is a process that updates your encryption version to the latest, most secure version. It also generates new encryption keys and re-encrypts and syncs all your items.
The latest encryption version is 003, and was released on June 12, 2018. If your account was created before that date, you will see prompts in the web or desktop app about an available security update. The in-app process will guide you through the update.In general, the steps to updating your security version are:
- Sign out of all devices (except for the session you're using to perform the update).
- Download a backup of your data.
- Enter your current password. This is used to generate new keys.
- Re-encrypt and reupload your items.
Strict Sign In
Strict sign in is an additional security layer that can be enabled during sign in. Strict sign in tells the app you're using "don't accept any encryption version less than the latest available version." It ensures you're signing in with the most up to date security version.
How strict sign in works:
When you attempt to sign in to your Standard Notes account, a request will be made to our servers to retrieve what are known as "authentication parameters" for your account. Authentication parameters are non-secret data that describe the methods used to generate your password. These parameters contain the encryption "version" we described earlier.
In designing our architecture to make the server "dumb", we want to treat the server as a non-trustworthy entity. This is because servers are not in the user's control, while the app in front of them is more directly in their control. So, we've designed our system to require a trustworthy application, but not a trustworthy server.
Given our design goal is a trustless server, the question arises of: what if the server is under an active attack and misleadingly conveys an older version to a requesting application?
For example, if there are two versions for an account, A and B, and A is an older version that describes a certain set of steps to generate passwords, and B is a new version that describes a more secure method of generating passwords, it would be in an attacker's favor to try to spoof the application into generating passwords using version A (the older version) instead of version B (the new version).
Strict sign in essentially says: ignore the version that is returned from the server. Instead, use the latest version that is hardcoded into my application.
The latest version of our encryption specification is 003. If your account was created before June 12, 2018, and you have not yet performed a security update, it's likely you're running version 002. If you presently try to sign in using the latest version of Standard Notes, and you enable strict sign in, your sign in will be refused. This is because strict sign in will only accept 003. In this case, you should perform the security update first, then begin signing in with strict sign in, if you so choose.
Is strict sign in required?
Strict sign in is optional, but can be a long term 'good move', just like two-factor authentication.
Even without strict sign in, older versions of our encryption specification are hardcoded to expire after a set time, usually about 1 year from the release of the upgraded version. After a version expires, it is no longer accepted without explicit consent from the user. This also prevents the server from tricking the application into using a lower account version. Strict sign in can be another way to say: "I don't want to wait 1 year for the older security version to expire. I want to get the same benefit right away."
If you have any questions about Standard Notes, or general security, please don't hesitate to get in touch.