—
Tadeas Kriz
tkriz(a)redhat.com
On 21 Jan 2014, at 15:26, Bruno Oliveira <bruno(a)abstractj.org> wrote:
--
abstractj
On January 21, 2014 at 12:18:34 PM, Tadeas Kriz (tkriz(a)redhat.com) wrote:
>> You can’t compare EncryptedSQLStore with SQLCipher. Completely
Keep in mind that I never did that ;)
Then I had to misunderstood the "APIs like SQLCipher don’t do that.”, sorry about
that.
> different way of encryption. SQLCipher encrypts the database
> page by page (mostly chunks of 1024 bytes), but EncryptedSQLStore
> encrypts only the data row by row individually (check [1] for
> very simple comparsion). That’s completely different approach.
> This way you can find out if the passphrase is right by calling
> basically any SQL command and an exception will be thrown if it
> won’t succeed. That’s something that cannot be achieved with
> current EncryptedSQLStore implementation. The EncryptedSQLStore
> already saves IV and Salt in separate table. It wouldn’t be a problem,
> performance issue or space issue to add one more row, which the
> EncryptedSQLStore would try to decrypt and if successful, that’d
> mean the passphrase is correct. The value of that row might be
> just an encrypted JSON with random key and value. That way, you’d
> check if the decrypted is valid JSON. There should be no security
> issue with that, or is there?
I never mentioned “security issue” in any kind of e-mail or Jira.
Then why would it be a problem?