salt of PBKDF2

[mic215fa]

Hello,

Could I custom to define the salt of PBKDF2 for SQLCipher when initializing database ?

Thanks!

Luke

[Stephen Lombardo]

Hello Luke,

There isn't currently a way to define a custom salt to be used for PBKDF2. The salt is generated randomly for each database, and stored in the first 16 bytes of the database file. What is the reason you would want to use a custom salt value?

Cheers,
Stephen

[mic215fa]

Dear Stephen,

Because SQLCipher doesn't define the Key Derivation Function.

So I want to follow the PBKDF2 that define a KDF(use PBKDF2 spec) to create different Derivation Key for :

1. Verify page when read

2. Use another Derivation Key to protect the column data of table

And that I think a custom salt for developer may be more elastic.

Luke

Stephen Lombardo於 2012年11月26日星期一UTC+8下午10時12分38秒寫道：

[Stephen Lombardo]

Hello Luke,

I apologize, but it still isn't clear for me how this would be an improvement. I've commented below.

On 2012-11-27, mic215fa wrote:
> Because SQLCipher doesn't define the Key Derivation Function.

SQLCipher already uses PBKDF2-HMAC-SHA1 for key derivation.

> So I want to follow the PBKDF2 that define a KDF(use PBKDF2 spec) to create
> different Derivation Key for :
>
> 1. Verify page when read
> 2. Use another Derivation Key to protect the column data of table

SQLCipher already uses a separately derived key for page verification than it does for encryption of data. By default the encryption key is derived from the user supplied key data using a full PBKDF2 cycle (4000 iterations by default) and the random database salt stored in the first 16 bytes of the database file. The page verification HMAC key is derived from the encryption key using a reduced number of PBKDF2 iterations and a permutation of the random database salt.

This ensures that the encryption key and HMAC key are different.

> And that I think a custom salt for developer may be more elastic.

The problem is that the salt needs to be stored somewhere that it can be accessed for key derivation. Allowing a custom salt would shift this responsibility to the developer. This would mean more work for integration and would leave the door open for potentially serious mistakes, like using a static salt everywhere.

Cheers,
Stephen

[mic215fa]

Dear Stephen,

I am sorry to cause you distress.

Because I don't know much about the operation of SQLCipher underlying.

So that I think may be some add-on secure procedure could protect data.

Thank you very much enthusiastic assistance.

Cheers,

Luke

Stephen Lombardo於 2012年11月27日星期二UTC+8下午10時17分42秒寫道：