10 lines of encryption, 1500 lines of key management

EN

Often when users ask for some features, they don’t understand how long it takes to make them. When features are related to security, developers also often don’t understand how long it will take.

I will show the real case about one large note taking the app, that decided to implement convenient note encryption and note locking for their existing user base. But finding a balance between usability, security and mobile platforms' restrictions is complicated.

We will start with the security design scheme, then select the proper encryption library, then implement the flow, and prepare for incidents. Now — think about it — cryptography is only chapter 3 in OWASP MASVS (7 chapters in general). Even the best cryptography will fail if basic security controls are badly implemented.

Points we will go through the difference between "locking" and "encrypting", the difference between password and encryption key, how to sync passwords between devices, what exactly to store in keychain/keystore, how to use proper cryptography (AES CBC or AES GCM, random salt? IV? padding? what a hell is this mess), how to use biometrics (we don’t want to bother user, let’s use biometric keychain, but what if users will change their fingerprints — shall we invalidate all passwords?), updating encryption version (imagine, vulnerability is discovered in our library or app — how to update cipher, and softly migrate users to the new cipher, if users don’t even have a clue that encryption was versioned).

In the end, this is only one simple JIRA ticket "let's encrypt the notes" from the eyes of security software engineer :)