Skip to content

Draft: Feature: Encrypted export

Liv M requested to merge livgm/drip:feature/encrypted-io into main

Why this change?

There is little point in having the app's database password-encrypted if there is no way to export/backup the data in an encrypted way. I think there are two points to this problem and this feature aims to fix the encryption side of things (at least to a degree).

Description

I have tested this MR:

  • tested this PR on iOS simulator/physical device,
  • tested this PR on Android simulator/physical device,
  • ran e2e tests.

This is the 1st of many steps towards encrypted, automatic backups. This feature mimics the regular import/export functionality, but requires a password to be set. I am currently using pbkgf to generate a key from password & salt and then aes-128-gcm to encrypt the data using a random iv. The iv & salt do not have to be kept secret, therefore they can be prepended to the encrypted file. This works fine as long as the user keeps inputting a password each time they want to export the data.

If we want to move a step closer to automatic backups, there needs to be a way in which the file can be encrypted without needing to permanently store the key used to decrypt it. This is what public-key-crypto is used for. The public key would need to be saved to the device (is not secret, does not need to be encrypted) and the private key would be encrypted with the user's password when they first set up backup functionality. The flow would then be the following:

EXPORT:

First/manual export?

Yes -> Ask for password. Generate public & private key pair, encrypt private key with password. Save public & encrypted private key to device.

Encrypt user data with public key & prepend encrypted private key to file.

IMPORT:

Ask for password. Extract encrypted private key from file, decrypt using password. This private key can then be used to decrypt the entire file.

Ideally, the user would remember their private key, but since this is not viable, the next best thing would be to generate it and encrypt it using the user's password. This means that the file still cannot be read without the user's input but can be written to, which is exactly what we want.

(... exporting without the user triggering it will be opened in a new issue)

Steps to Test or Reproduce

Settings -> Export encrypted -> Set password & location to save file. Settings -> Import encrypted -> Choose file to import & enter password that was used to encrypt file.

Reviewing

Here's what I am looking for feedback on in particular:

  • Crypto advice :)
  • Specific use cases, what should happen if device is lost etc.? What happens if a user has multiple exports and we want to change encryption algorithms?

In addition:

crypto.gif

Merge request reports