We are currently developing the functionality of syncing the TTL data to Google Drive, related to #913.
When exporting the data, it would be good to encrypt it with a passphrase that the user enters into TTL (this will be optional, otherwise a TTL passphrase is used). If the user loads the data back into TTL, he has to enter the passphrase used before and then the data gets decrypted and imported into TTL (or the TTL passphrase is used for decryption).
What change is being introduced by this PR?
This PR introduces methods to de/encrypt and de/compress a file. This can be used during the exporting and importing of TTL data.
During the export, the file is first compressed then encrypted with a passphrase. During the import the file is decrypted first then decompressed.
For compressing, I used the compressing npm module. The file is compressed to .tgz. As the user is not supposed to decompress the file, I think the archive format does not matter that much.
For encryption, I used the cryptify npm module. I used the aes-256-cbc Cipher algorithm and utf8 encoding. The Cipher algorithm I choose was a rather arbitrary choice (the default algorithm used by cryptify) as I think we are using the encryption mostly to ensure the file is not changed (as discussed in #932). But cryptify offers a range of different cipher algorithms, so we could also change that.
How will this be tested?
I wrote unit tests for the new functions I implemented. But we definitely have to do more tests once the functionality is integrated with the sync-data-to-google-drive functionality.
Related issue
Towards #932
Context / Background
We are currently developing the functionality of syncing the TTL data to Google Drive, related to #913.
When exporting the data, it would be good to encrypt it with a passphrase that the user enters into TTL (this will be optional, otherwise a TTL passphrase is used). If the user loads the data back into TTL, he has to enter the passphrase used before and then the data gets decrypted and imported into TTL (or the TTL passphrase is used for decryption).
What change is being introduced by this PR?
This PR introduces methods to de/encrypt and de/compress a file. This can be used during the exporting and importing of TTL data. During the export, the file is first compressed then encrypted with a passphrase. During the import the file is decrypted first then decompressed.
For compressing, I used the compressing npm module. The file is compressed to .tgz. As the user is not supposed to decompress the file, I think the archive format does not matter that much.
For encryption, I used the cryptify npm module. I used the aes-256-cbc Cipher algorithm and utf8 encoding. The Cipher algorithm I choose was a rather arbitrary choice (the default algorithm used by cryptify) as I think we are using the encryption mostly to ensure the file is not changed (as discussed in #932). But cryptify offers a range of different cipher algorithms, so we could also change that.
How will this be tested?
I wrote unit tests for the new functions I implemented. But we definitely have to do more tests once the functionality is integrated with the sync-data-to-google-drive functionality.