Copy

Bug #492

SQLCipher uses a ridiculously low iteration count in the key derivation function

Added by abeluck about 5 years ago. Updated over 3 years ago.

Status:ClosedStart date:01/10/2013
Priority:NormalDue date:
Assignee:hans% Done:

0%

Category:-
Target version:0.2 - reliability and cacheword interop
Component:libsqlfs

Description

"The default configuration uses 4000 iterations for key derivation (this can be changed at runtime using “PRAGMA kdf_iter”)." - http://sqlcipher.net/design/

We definitely need to up this an order of magnitude or two.

Reasoning: http://security.stackexchange.com/questions/3959/recommended-of-iterations-when-using-pkbdf2-sha256

We should go about this by benchmarking sqlcipher's KDF on different Android devices and arrive at a suitable count.

Related issues

Related to CacheWord - Bug #3146: make quick and easy KDF calibrator based on /proc/cpuinfo Closed 03/27/2014
Related to IOCipher - Bug #1714: sqlfs doesn't support sqlcipher's raw key Closed 08/13/2013

History

#1 Updated by abeluck about 5 years ago

It is crucial to note, that in our mobile device context, n, the amount of entropy in the user's password, is likely to be very low.

This is because typing in high entropy passwords on a tiny device is a PITA.

#2 Updated by n8fr8 about 5 years ago

  • Project changed from IOCipher to SyncSafe
  • Priority changed from Normal to High
  • Target version set to 45

#3 Updated by n8fr8 about 5 years ago

  • Project changed from SyncSafe to IOCipher

Hmm... we need a SQLCipher project... or perhaps this bug should be filed with Zetetic?

#4 Updated by n8fr8 about 5 years ago

  • Target version changed from 45 to Phase II - Stage 1.

#5 Updated by abeluck about 5 years ago

I've talked with Nick from Zetetic before about this issue. They don't really view it as a bug, and while it is my opinion the default iteration count is very low, they argue it is suitable for them.

That is OK, as SQLCipher offers the PRAGMA kdf_iter runtime option to change the iteration count. So, in IOCipher and every other project we use SQLCipher, we should change this to something much higher.

I'm preparing an Android Test project to benchmark iteration counts so we can empirically arrive at a good number.

#6 Updated by abeluck almost 5 years ago

  • Component set to libsqlfs

#7 Updated by hans almost 5 years ago

  • Target version changed from Phase II - Stage 1. to 61

#8 Updated by abeluck almost 5 years ago

The SQLCipher API page shows that we can pass our own raw key data directly, which would presumably allow us to do our own key derivation, with scrypt or bcrypt perhaps. Definitely not an ideal choice, just documenting the option.

#9 Updated by abeluck almost 5 years ago

I'm making use of the raw key data in CacheWord. It works quite snazzy. Found an sql injection vuln while I was at it. Pushing fixes to Zetetic.

#10 Updated by abeluck over 4 years ago

Discussion about an adaptive algorithim to determine the best number of iterations per device:

https://github.com/WhisperSystems/TextSecure/issues/184
https://github.com/joeykrim/PBEKeyTester

#11 Updated by hans almost 4 years ago

  • Priority changed from High to Low

#12 Updated by hans almost 4 years ago

  • Target version deleted (61)

#13 Updated by hans over 3 years ago

  • Target version set to 0.2 - reliability and cacheword interop

This is something that will be handled by CacheWord, since it already does the iteration count calculation. When using IOCipher without CacheWord, IOCipher will just use SQLCipher's default number of iteration counts. As of #1714, people are also free to make their own techniques and pass the raw AES key to IOCipher. It is not really something that should be handled by IOCipher itself.

#14 Updated by hans over 3 years ago

  • Status changed from New to Feedback
  • Priority changed from Low to Normal

#15 Updated by hans over 3 years ago

  • Assignee set to hans

#16 Updated by hans over 3 years ago

  • Status changed from Feedback to Closed
Copy

Also available in: Atom PDF