Crypto: Increase Performance

[petermax2]

Problem

The crypto plugin keeps the Initialization Vector (IV) secret by retrieving the IV via PBKDF2 for each Key, that is being encrypted/decrypted. Thus the crypto plugin invokes the slow-by-design PBKDF2 for every Key it processes.

However, the IV does not have to be a secret. [1, page 194]

Proposal

1. The crypto plugin invokes the PBKDF2 once per kdg get and kdb set in order to retrieve the cryptographic key.
2. The IV is generated as random sequence by the crypto provider (OpenSSL, gcrypt, Botan).
3. The IV is stored (unencrypted) in the header of the crypto payload.

The proposed changes do not affect the security of the plugin. [1] The steps mentioned above should significantly increase the performance of the crypto plugin.

I want to start the implementation as soon as possible, if there are no objections against the proposal.

Literature

[1] Bruce Schneier. 1995. Applied Cryptography (2nd Ed.): Protocols, Algorithms, and Source Code in C. John Wiley & Sons, Inc., New York, NY, USA.

[markus2330]

Thank you for this well-thought proposal! There are no objections from my side.

Of course better performance is good to have but I am not sure if this is (at all) a hindering factor of the crypto plugins' usability and adoption.

From my understanding, people would usually either encrypt the file or the "three" sensitive configuration values. In these use cases, your described performance improvement would not matter, would it?

So I think better docu, better tutorials, less dependencies (e.g. #896) and overall better usability (e.g. #898) might be way more important than such a performance improvement.

But of course you can do with your free time what you think is the most important task 😉

[petermax2]

The tasks you mentioned are still on my TODO list and I will tackle them soon. Now that the pressure of writing my Bachelors thesis is gone, I enjoy hacking on Elektra even more. 😀

[ingwinlu]

It would also be interesting to see how gpgme's performance is vs the manual gpg forks we do now.

[petermax2]

After analyzing the code I don't support the idea of this issue any longer.

If we reduce the number of PBKDF2 invokations to one per (Elektra) KeySet we re-use the same cryptographic key for every (Elektra) Key within the KeySet.

Keeping the initialization vector (IV) unencrypted does not cause a performance increase by itself. We would also have to get rid of the salt, that is generated for every Key within the KeySet. At the moment the salt is used for deriving a cryptographic key and an IV.

We might weaken the security with this proposal, and since performance is not a top priority for the crypto plugin(s) anyway I will close this issue for now.

[markus2330]

Yes, I fully agree and it is good to reduce issues which do not bring us closer to 1.0.

I think the best for the crypto plugins would be to simply use them more (e.g. password manager). Then we will see what is really important.