Libelektra: Crypto: Increase Performance
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
- The
cryptoplugin invokes the PBKDF2 once perkdg getandkdb setin order to retrieve the cryptographic key. - The IV is generated as random sequence by the crypto provider (OpenSSL, gcrypt, Botan).
- 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.
petermax2
All 5 comments
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 :wink:
markus2330
on 13 May 2018
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. :grinning:
petermax2
on 13 May 2018
It would also be interesting to see how gpgme's performance is vs the manual gpg forks we do now.
ingwinlu
on 11 Jun 2018
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.
petermax2
on 17 Aug 2019
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.
markus2330
on 17 Aug 2019
Related issues
markus2330
·
4Comments
mpranj
·
3Comments
mpranj
·
3Comments
markus2330
·
4Comments
dominicjaeger
·
3Comments
Most helpful comment
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. :grinning: