Client-side encryption poll

What Alan said was 100% correct. If you want to keep a document private, keep the key private. If you want to share an encrypted document, also share the key so that they can read and edit it.

Public key isn’t in view here because it’s not needed in our scenario. We can get into the technical details if anyone’s interested.

The problem with a single key is it would kill facility to collaborate. It would be nice to have the ability to choose to either:

  • encrypt a folder, AND/OR
  • encrypt a document.

THEN you can choose to either encrypt a single thing OR a group of things. So if you need to share a key it doesn’t become burdensome as docs and people relations may expand.

I’m new here, I am already having associates ask me about Dynalist’s encryption.
Just my two-Sense (Twohawks ;^)

3 Likes

Yeah, collaboration is something people need to trade off for if they want to encrypt everything with the same key, unfortunately.

Maybe encrypting folders is a good solution that would satisfy both needs : Fast and easy encryption of many documents while still being able to collaborate.

2 Likes

Great to see this being considered. A lack of proper end-to-end encryption is the one thing keeping me from going premium on Dynalist or Workflowy - I need some reassurance that compromised servers won’t also compromise my data!

4 Likes

I see the problems of encrypting all content with a single key, so I voted for encrypting each document individually.

However, it would still be nice to encrypt everything with a single key during export (both manual and automatic). This would reduce the number of possible breaches from three or more (Dynalist server, Google or Dropbox server and every single computer or medium containing a manual backup copy) to just one (Dynalist server). And it wouldn’t induce the problems of end-to-end encryption.

(I know that there is a feature request regarding encrypted automatic daily backup, but I think that the above might be beneficial to your poll.)

1 Like

I feel the “just one” breach point (i.e. Dynalist server) is what people are most concerned about, therefore we’re only asking about end-to-end encryption vs simple password protection here.

For me, a backup needs to be useable outside of Dynalist. How does that happen if it’s encrypted. Is there a way if I know the key to decrypt it apart from DynaList?

1 Like

Thanks for your answer – so do I.

It’s hard to explain why I wrote this. Maybe like this: I’m a developer myself, and it has always helped me when someone pointed out (seemingly) related things. :slightly_smiling_face:

The export key could simply be stored in Dynalist’s settings. But I did not want to hi-jack this topic and think that further discussion of this topic should happen in *Encrypted* automatic daily backup. Thanks!

I asked the same question there with no answer. I also disagree that this is an independent question. The purpose of backup is an independent copy of my data. Encryption secures my data from reading. Backing up my data unencrypted foils the security. Backing up my daa encrypted also must be decryptable by me or the backup feature becomes pointless. I assume these matters impact the poll.

One solution is to provide a lightweight standalone HTML page that would take a .zip file, a key, and output the decrypted content.

Because this HTML page doesn’t need to have any of Dynalist’s functionalities, it can be quiet small and lightweight. It’s not prone to change either. You can download it once and store it in your Dropbox/GDrive for later use.

3 Likes

I would suggest to use a standardized encryption scheme so that third party apps (e.g. apps that operate over the api, say Quick Dynalist) also can use the respective decryption / encryption routines.

Of course, it’d likely be something like AES-128 which I believe is one of the most popular encryption schemes around for this kind of use-case.

Maybe look into keybase.io they have some awesome thoughts on how encryption should work.

It’s great to see that you are seriously considering adding encryption to Dynalist. Do you have any ETA for it?

2 Likes

i voted for encrypting all of dynalist with a key first because i was thinking that encrypting each document individually would mean having to have a separate key for each one… but maybe im reading that wrong? could you just use the same key to encrypt multiple documents?

that would be my use case anyway. i would probably encrypt most of my documents and leave the 2 or 3 documents i want to share unencrypted

i wouldnt be too worry about losing the encryption key myself. i would have it stored in my keepass database which is backed up to multiple locations!

For my needs of private journaling, the ability to password/PIN protect on a document-level(and encrypt the document with the same password) a great solution. I imagine it working the same way Apple Notes work, you can individually select which notes you want Locked and you can protect those with a PIN, and it syncs all the same on all devices requiring the PIN(separate from iCloud password) to view or edit Locked notes.

Right now the way I mitigate is by using Apple Notes for journaling and Dynalist for content I don’t mind being public, if PINs come to Documents on Dynalist, I see no use of using Apple Notes.

-Michael :slight_smile:

Lack of encryption is the only thing that’s holding me from migrating to Dynalist. Can you give us an ETA on this feature? So I don’t have false expectation. Thank you.

2 Likes

I would really like to use client-side encryption. If there is client-side encryption I can upgrade to Pro!

I can find a card on Trello Dynalist Roadmap about ‘end-to-end encryption’ but there could be a difference between end-to-end encryption and client-side encryption. Where can we vote for client-side encryption on the Trello Dynalist Roadmap?