Set password for cloud sync encryption

RuiMarques

The reply within this thread* explaining the new v5 sync options & workflow. 😊

I went through most of this thread, and you seem to be making some solid strides in the security space for Diarium, but I think it would be great to have a single post, or location where existing, and prospective users can see the security the product has in place, as well as what's in the pipeline (if applicable).

I work in cybersecurity, and the only reason I didn't pick Penzu over Diarium at the end is because I think your app looks and feels better, has better features, and seems to have an extremely responsive developer (yourself) which is golden.

I've seen an uptick in trends where users are checking for security when they purchase or use apps, so I just think it would be awesome to have that on the site, or somewhere.

timo

RuiMarques The "v5 sync" is still in beta and opt-in. I am also planning to make a breaking change to the v5 sync in one of the next updates, which will require deleting the data from the Cloud and setting it up again. I will make a "proper" post once this feature is fully implemented and released. At the moment this feature is beta and "use at your own risk"

RuiMarques

timo How can I opt-in kind sir?

timo

It's explained in this post

Antyrox

timo
Can you give any approximate release dates for this breaking change of the v5 sync? I really want to use e2ee sync with a custom password. However it seems that if i configure it now, then soon enough i will have to delete everything and reconfigure everything from scratch all over again.

timo

Antyrox In the meantime, I think I decided against that breaking change. I considered using "Brotli" compression algorithm instead of the currently used gzip algorithm, but the benefits (compression speed & compressed size) would be too small. I'm not 100% sure though, I might do some final tests.
Btw, I hope to finally introduce this feature later this summer, with a button in the settings to migrate from v4 to v5 and maybe even making v5 the default mode for new users.

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).

« Previous Page Next Page »