Set password for cloud sync encryption

Antyrox

timo
Glad to hear that this feature may be out soon.

I doubt that the switch from gzip to Brotli is gonna be a worthwhile one. As far as i know Brotli is optimized primarily for text and web pages, but about 95% of the size of my diary is actually taken up by the pictures and the videos. I assume this is the case for most people. As far as i know most modern image and video formats are already compressed and compressing them further yields very little benefit. But i suppose your testing will ultimately show if it worth it or not.

Thanks for your work. I will be eagerly waiting for the release of the migration to v5.

timo

Antyrox As far as i know Brotli is optimized primarily for text and web pages, but about 95% of the size of my diary is actually taken up by the pictures and the videos

This is right, but Diarium splits the text part from the media part (which is compressed already anyways) and when you just change text in your journal, Diarium only syncs the journal without the media part. So Brotli could achieve that a smaller file (which is called "v4_database" on your Cloud storage) would have to be up-/downloaded.

Antyrox

timo
I see, if the text is separated from the media then Brotli can actually be an improvement in terms of sync speed. Especially since this file is uploaded/downloaded literally every time. Thanks for clarification.

I assume that breaking change that you mentioned means that everything in the Diarium cloud storage will have to be re-compressed from gzip to Brotli and reuploaded. But if Brotli compression is only relevant to one file with text data, then why not simply re-compress only v4_database and leave everything else as is with gzip? Surely it must be possible to check if this file is compressed with gzip or br. Maybe by simply calling a new version "v4_database_br" or by some internal marker. If old gzip version is detected in the cloud then download it, decompress it with gzip and then upload a new br version. That gives advantage of using Brotli without the need of full diary reupload.

timo

Antyrox I assume that breaking change that you mentioned means that everything in the Diarium cloud storage will have to be re-compressed from gzip to Brotli and reuploaded

Not everything, because media files are not additionally compressed, but essentially that's the reason, yes.

I don't want to do checks for gzip or brotli for a feature that is in beta. I made it beta so that I could make changes like these without having to add code (and potential problems) for checks like these.

As I said before, I will do some benchmarks again to see if Brotli is actually worth using, my last tests didn't really show that much of a benefit. And adding Brotli as a dependency would make the Windows app slightly larger in size and I'd just have to stick with it for the rest of the apps lifetime. If I kept using gzip, this wouldn't be the case

Med

Good morning,

I’ve noticed that my Diarium files are on version v5, and I completed the migration at the end of December 2023.

Does this mean I’m using E2EE encryption? Are there any updates or upcoming actions regarding this matter?

Once v5 is released as the default version, will users already on v5 need to perform any kind of update?

Thank you very much,

timo

Med Does this mean I’m using E2EE encryption?

It depends on what option you selected when you have set up the v5 sync.

Med Are there any updates or upcoming actions regarding this matter?

I am still planning to roll out this feature publicly in the future. There is just always something else that needs to be fixed first...

Med Once v5 is released as the default version, will users already on v5 need to perform any kind of update?

I hope not - unless there will be a breaking change. At the moment, it's in Beta for a reason 😉

Med

timo

Good afternoon,

I don't quite understand.

How can I verify that my v5 files are properly encrypted with E2EE?

Thank you very much.

timo

Med What do you mean with "verify"? As described above, when setting up the v5 sync for the first time, you will be presented with a dialog with two options:

no encryption
e2ee encryption

Depending on what you choose, Diairum will use

Med

timo

Good afternoon,

I didn't see any menu appear.

Back then, I enabled it as follows:

I opened an entry in Diarium for Windows, and in the header field, I entered the following text: "ENABLE E2EE" and set a password, which was then required on the other devices when synchronizing.
Best regards,

timo

Sounds like you have e2ee enabled then

leonix

Hi Timo. Nice work!

Just to clarify: "Default" means no encryption at all?
With enabled E2EE encryption: Would it be possible to change the encryption password later on?

However: back to your thought to the "standard user": I agree most of them do not care about the lesser security of a "single key for all users" - more important for them is not to loose their data. This will happen in case they forgot where they wrote down their password (that they set 4 years ago, and never had to re-enter it)! I case you switch to the new V5 with individual passwords you will get many request "how can I get my diary back" and many frustrated users. All the other E2EE I see in the world are hidden to the users, e.g. https or the E2EE of whatsepp - no user have to set a passwd...

I would recommend to set the option of a "single key for all users" as the default option (as in v4) - instead of no encyption at all.

Best Leo.

timo

leonix Just to clarify: "Default" means no encryption at all?

Yes.

leonix With enabled E2EE encryption: Would it be possible to change the encryption password later on?

I talked about this in the thread above

timo The encryption key is automatically generated when first setting up the E2EE encryption Cloud Sync. The encryption key itself is encrypted (also using AES265-CBC) using an encryption key that is derived (using PBKDF2 key derivation) from a user-provided password. The encrypted encryption key is then appended to the "v4e_database" file before uploading, together with the salt for . The advantage of not using a key derived from the user password to encrypt all files is that the user could in the future change his password, without the app having to re-encrypt & re-upload all journal files. Only the "main" encryption key would then have to be re-encrypted using the new key derived from the new password. I don't plan to add such a "change password" feature for now, but it's good to have the option if I decide to do so.

leonix I case you switch to the new V5 with individual passwords you will get many request "how can I get my diary back" and many frustrated users.

I already get these now, because users don't use the sync at all, even though the app shows warning dialogs every 30 days.

leonix I would recommend to set the option of a "single key for all users" as the default option (as in v4) - instead of no encyption at all.

Can you elaborate why you think this would be better?

leonix

timo leonix I would recommend to set the option of a "single key for all users" as the default option (as in v4) - instead of no encyption at all.

Can you elaborate why you think this would be better?

After thinking about it further, it doesn't seem to make sense to encrypt it with a generic key that is part of the app binary. If someone has captured the data, they just need to upload it to a cloud service and install Diarium to decrypt it.

timo

leonix Exactly. Diarium currently does exactly that in the sync and I don't know why I decided to do it like that in the first place (probably because I had much less experience).

BES

Thank you Timo for this app—I use Diarium daily and love your application.

Please excuse me but I will back off from the technical conversation because it is above my pay grade.

Having said that, I have opted to not sync via iCloud because of my extensive journaling. I transfer backup files to my mobile devices via Mac’s file transfer facility with a wired connection.

I would certainly like to confidently sync between devices but I think that I would have to be convinced that I control my data. I should determine the encryption key for my data. I think the app should seamlessly support data integrity and my encryption key between all my devices via app sign-in.

So, my thought is that if this is done right, all the user should have to worry about is selecting a file password. Wiz, bang, bop, the app protects the user's data.

« Previous Page