4

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.

AlexR
  • 5,514
  • 9
  • 75
  • 130

2 Answers2

7

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.

Rob Napier
  • 286,113
  • 34
  • 456
  • 610
4

There isn't much you can do, RNCryptor is not slow.

AES128 will be a little faster than AES256 -- or not depending on the platform.

There is a large cost in the setup so that is a place to possibly make things faster. One possibility is combining the strings.

If you could make all the strings a multiple of block size you could use one setup, ECB mode and the partial CCryptor functions. Note, ECB mode will degrade security especially on short strings. Setup with CCCryptorCreate()and decrypt with the short padded strings with CCCryptorUpdate().

Another thing to consider is TinyCrypt. "The first point of TinyCrypt is to both compress and encrypt your file VERY quickly." I rarely suggest other than AES and using non-mainstream cyphers is dodgy at best--but you stated you were willing to tradeoff security for speed.

zaph
  • 111,848
  • 21
  • 189
  • 228
  • I will look definitively look into `TinyCrypt`. Any idea on how to improve the performance of setting up `RNCryptor`? I just use it in one line of code: `NSData *decryptedData = [RNDecryptor decryptData:encryptedData withPassword:password error:&decryptionError];`. – AlexR Nov 23 '13 at 12:33
  • Most encryption methods have to create a lot of state on startup so that is the only real hope for speed. Most of the chip sets have some form of encryption support. I suspect that Rob will provide some help. Best advice, get a crypto domain expert to write your encryption code or at least review it--if you care about the security. – zaph Nov 23 '13 at 12:46
  • Can you recommend an crypto expert (preferable with iOS and Core Data experience)? – AlexR Nov 23 '13 at 12:50
  • 1
    [Rob Napier](http://robnapier.net) and [Graham Lee](http://blog.securemacprogramming.com) come to mind immediately. The people I have used for review are in the financial industry. – zaph Nov 23 '13 at 12:59