If using ESS, all information necessary to sync the items is cloned to ESS server. Text fields of the items get encrypted. Metadata stays in the clear, for example creation and modification times, the type of the item (projecs vs action) and so on.
Everdo uses 256-bit AES CBC encryption to encrypt each text field before transmitting data to the server. The server only stores encrypted fields and IV values and never sees or can access the clear text.
256-bit encryption requires a key length of exactly 256 bits. To meet this requirement in a relatively user-friendly manner, it was decided to use a 16-word passphrase to encode the key using a 65536-word dictionary.
When generating a new key, Everdo simply chooses 16 random words from the dictionary. The resulting passphrase will represent a random 256-bit key.
The keys are absolutely not pre-selected - you can choose and specify 16 words yourself and it will work, provided each word appears in the dictionary
When talking about a protocol, I’m not sure what you’re interested in. SSL(HTTPS) is used, of course for transport. Regarding the data being sent, you can assume: (a) all text fields (titles, descriptions/notes) are encrypted on the client-side, as described above (b) metadata is unencrypted (timestamps, references between objects, object types).
Another piece of data transmitted is a hash/fingerprint (SHA-256) of the encryption key. This is needed to avoid data corruption by clients configured with different encryption keys by mistake.
Not yet. Until all platforms are supported and some important improvements affecting sync get added. Code is being changed a bit too often at the moment to make audit feasible.
What has been done in-house to ensure encryption security and correctness:
- only using industry-standard crypto libraries (nothing custom-made /DIY)
- using the recommended, strong cypher modes (CBC)
- conforming to other best practices (IV generation, etc)
Correct. Without ESS there isn’t even an account to store anything in/for.