Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>OK, that (see below) is not exactly your problem, PBKDF2 is slow but should be <em>nowhere as slow</em> as described with those parameters on that hardware. There are some stats (and tips) here on Android PBE/KDF performance: <a href="http://nelenkov.blogspot.com/2012/04/using-password-based-encryption-on.html" rel="nofollow noreferrer">http://nelenkov.blogspot.com/2012/04/using-password-based-encryption-on.html</a> . <code>SecretKeyFactory</code> performance problems are not unknown: <a href="https://stackoverflow.com/questions/3814972/any-way-around-awful-secretkeyfactory-performance-with-lvl-and-aesobfuscator">Any way around awful SecretKeyFactory performance with LVL and AESObfuscator?</a> .</p> <p><code>SecretKeyFactory</code> is likely using pure Java implementation. <em>SQLCipher</em> has two relevant features:</p> <ul> <li>it uses OpenSSL, compiled native code (on my <em>desktop</em> OpenSSL's PBKDF2 is nearly 100x faster than a JVM6 <code>SecretKeyFactory</code> version for 2000 iterations, excluding JVM startup time. I haven't compared AES speed, it appears other people find it slow on Android too)</li> <li>the 4000 iteration PBKDF2 is only done on database open, after that there's at most 2 iterations for the page HMAC secret (assuming the default configuration, as documented)</li> </ul> <p>Your code seems correct, there should not be such a large (linear?) performance degradation when you increase your iterations. The <em>Xoom</em> should be running a non-ancient JVM with JIT, can you verify the performance problem with <a href="https://stackoverflow.com/questions/2860943/suggestions-for-library-to-hash-passwords-in-java">other code</a>?</p> <p><hr> PBKDF2 is <em>designed</em> to be slow (see the answer to this question <a href="https://security.stackexchange.com/questions/7689/clarification-needed-for-nists-whitepaper-recommendation-for-password-based-ke">https://security.stackexchange.com/questions/7689/clarification-needed-for-nists-whitepaper-recommendation-for-password-based-ke</a> ) due to the intended <a href="http://en.wikipedia.org/wiki/Key_stretching" rel="nofollow noreferrer">key stretching</a> operation. The iteration counter lets you trade off speed for security.</p> <p>AES was always <a href="http://cryptome.org/jya/aescomm.htm" rel="nofollow noreferrer">intended to be fast</a> and is fast (<a href="http://csrc.nist.gov/archive/aes/round1/conf2/Schneier.pdf" rel="nofollow noreferrer">speed comparison PDF</a>, the chosen AES candidate is referred to by its original name <em>Rijndael</em> in that paper).</p> <p>I assume you are comparing the PBKDF2 computation time directly to the time taken to perform an SQL operation on your SQLCipher database which will almost certainly have been designed to be fast. </p> <p>You are effectively comparing two different operations with different requirements, hence the speed difference.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload