Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

RNCryptor: Which settings to change to improve performance?

I have a lot of short strings to decrypt in my app and decryption speed is critical.

Currently I am experimenting with RNCryptor but find its default settings a bit slow for my use case. Otherwise it is an awesome framework :-)

Encryption will be done only once and hence its performance is not important.

I am fine giving up protection for speed as I just want to have a very basic encryption in place.

Which RNCryptor settings would you recommend using to encrypt and decrypt in order to accomplish the fastest decryption performance? A short code sample would be great!

Again, I am fine with very basic encryption protection for the current use case.

like image 301
AlexR Avatar asked Dec 20 '22 21:12

AlexR


1 Answers

The lion's share of time in RNCryptor are in the calls to PBKDF2. It iterates 20,000 times (10,000 for each key). While it may get a little faster in upcoming versions of RNCryptor, password-based encryption will always be slow. This is a security feature; it's slow on purpose. It's designed to be slow in a way that frustrates attackers while having acceptable impact on the most common use cases.

You can dramatically improve performance by using the key-based, rather than password-based, methods. The key-based methods have no injected slowdowns. This would be my recommended approach if possible. Generate two random 256-bits keys rather than using a password.

You can potentially set the number of PBKDF2 iterations to a smaller number (and that's necessary when dealing with JavaScript for instance), but the faster you make key generation, the worse your security is going to be.

There are a number of ways to modify the format to improve performance for your use case, but it's very easy to mess it up and significantly hurt security. As @Zaph notes, I would either do a lot of study or engage an expert before modifying any security framework.

like image 193
Rob Napier Avatar answered Feb 19 '23 22:02

Rob Napier