ElliesDad

No, you can reuse the same password for mltiple notes. However, EN's encrypted document support remains primative in design, and the web client implementation does not allow editing (I believe is due to multiple bugs which haven't been fixed in classic web UI (I haven't tried the new web Ui recently, because it it is so unusable for me. I posted about that in a different post. I am hoping EN will provide a stable CRUD UI to enable 3rd parties to develop replacement UIs....

Strong encryption at the notebook level (eg, all note content, and all note metadata (eg title, tags, creation date, change history) with no escrowing of keys, and the ability to perform rich-text-editing of the contents of an encrypted note (which includes encryption of attachments to the note) on any device, is a requirement before I will pay for Evernote. I'll use the free basic account lightly until then, but I won't go "all in" with Evernote until this is implemented. As a software developer who has implemented all the parts of encrypted note store functionality which I envision, I assure you there is no rocket-science to doing this, these days. You want one or more seasoned developers to do it, but it is certainly do-able. To do it properly (given the current feature sets), EN will need to implement both server-side crypto (for EN Web and EN APIs), and client-side-only crypto (for tin-foil hats like me who are annoyed at the fact that GCHQ and NSA have staff and/or data-feeds and/or secret letters which enable them to access anything stored in the major cloud services, and are concerned about APT threats to corporate data -- such as what has recently been disclosed about Russia's and WikiLeak's actions in the US elections. To do it properly, sync-ing and change history and search indexing should be enhanced to work properly with ciphertext (post-encryption) as well as plain-text (unencrypted) content. Encryption does not mean you can't have searchability -- EN would need to index the unencrypted text, then encrypt the resulting search indices with the appropriate encryption key. Then, in order to search, the search engine would need to decrypt the indices which it can using the password(s) which the user has provided, in order to include those indexed values in the search process. This might not scale to be able search millions of users' databases in a single query -- which is actually quite desirable from my perspective -- but it should scale quite comfortably for 1 to 1000 users/passwords over 1 to 1000 notebooks. Modern mid-to-high-end cell phones have enough RAM and enough CPU to provide searching of client-side-encrypted notebooks (eg, keys never supplied to servers); I can't speak for others, but for me, only indexing of note metadata and note text would be good enough (eg, no client-side searching of attachments such as PDFs). Finally, client-side encryption does not mean you can't share encrypted documents on the server, or do server-side merging of encrypted changes from multiple people. To support these features you'd need to use public key-encryption, and it does mean you'd need to canonicalize the pasted-in HTML which you store or create, since the unit of merging and change history recording would need to match the unit of encryption -- which I suggest would be a complete HTML tag and its nested children, for simplicity. If I were designing the feature set, I would make the recording in the change history of who initiated certain changes and when they were done, a configurable feature at the notebook level, to provide a degree of plausible deniability. You would need to record change sequence, but you should allow updates to be persisted anonymously. Implementing server-side key-escrow/storage for those users who want it (eg, corporations) is not a big deal either. For those who don't want it, it should be possible to prove by inspection, that the encryption key is not hidden in any files which are synced to the server, and is never sent to the servers using an API, unless a user initiates such a transfer explicitly, and is never stored on disk locally. You should allow a user to use different keys for different documents (and even different sections of a single document) within an encrypted notebook. In summary, I believe the problems which need to be solved are well understood, are tractable, and do not involve any compromise of the current feature set. So EN, please just do it! PS: I encourage you to crowd-source a detailed technical requirements spec, and the priority of various features, in order to ensure you don't miss critical security details, and that you implement features in the correct order to avoid serious gotchas along the way. If you go this way, I would be interested in participating.