search

samuel-lucas6 / Kryptor

A simple, modern, and secure encryption and signing tool that aims to be a better version of age and Minisign.
https://www.kryptor.co.uk
GNU General Public License v3.0
414 stars 33 forks source link

📋 Feature: Faster folder encryption #6

Closed samuel-lucas6 closed 3 years ago

samuel-lucas6 commented 3 years ago

Is your feature request related to a problem? Please describe. Kryptor currently takes quite a while to encrypt a large number of files (e.g. thousands) at a time because key derivation occurs for each file. This approach works well for fewer files, but it leads to a greater delay when encrypting lots of files - e.g. 250 ms per file = 250 seconds of key derivation for 1000 files.

Describe the feature you'd like Investigate a way of encrypting folders in a similar way to Cryptomator. In other words, derive an encryption key and MAC key once using a longer delay (e.g. 1 second). Then either a) use these keys to encrypt all the files in the folder (quickest approach) or b) store these keys in a file inside the selected folder and use them to encrypt randomly generated keys per file (a more secure approach but slower). Cryptomator and AxCrypt use approach b), but it leads to slower decryption. However, there are potential issues that can arise from encrypting a large amount of data under the same keys, so approach b) is probably best.

Implementing this feature will make some of the code a bit more messy, and the Argon2 memory size/iterations settings will become a problem. It doesn't make sense to use a 250 ms delay to generate master keys when a 1 second delay can be used for increased security without it being very noticeable to the user. I'm not sure how this problem can be solved.

Why should this feature be implemented? It will make encrypting folders/lots of files faster.

lynn-stephenson commented 3 years ago

What kind of issues can arise from encrypting TBs (potentially) of data under the same keys?

I know you can run out of nonces and etc. But you still got a lot of room for "safe" encryption.

samuel-lucas6 commented 3 years ago

Yeah you're right; with the current algorithms, there isn't a problem with using the same keys because of the 2^64 messages limit. I was thinking of the AES-GCM limit.

Using the same keys would be much faster and easier to implement. I guess my main motivation for using unique keys per file is because that's how it's done in Cryptomator and AxCrypt. Also to stay consistent with the current claim that each file is encrypted with a unique key.

This is the next thing I'm going to work on after I finish the CLI version. It shouldn't be too difficult, but like I said, I'm not sure how I'll approach the key derivation delay issue.

lynn-stephenson commented 3 years ago

I can do some math and designs at some point here soon and give a few pointers.

But I think it'd be entirely plausible to do it that way.

samuel-lucas6 commented 3 years ago

Related: #10

samuel-lucas6 commented 3 years ago

Fixed in v3.0.0 Beta.