Internal Encryption mechanism and Library used in SQLCipher

#1

Hi Team,

Please answer the below questions:

  1. I am using Android studio and declared SQLCipher in dependencies and current size is 2.6 MB. What libraries it has internally ?

  2. How the encryption is happening on both (KitKat and Nougat) ? Are the encryption libraries enclosed in above @aar file ? and what are they ? (EX : OPENSSL , Java Crypto provider)

  3. And for 1000 rows below are the statistics on “SQLLite” and “SQLCipher” , is it true ?

             (SQLLite)        (SQLCipher)

Insert 10398 MS 185699 MS
Update 6760 MS 10266 MS
Read 52 MS 66 MS

#2

Hi @AshokKasthuri

I am using Android studio and declared SQLCipher in dependencies and current size is 2.6 MB. What libraries it has internally ?

SQLCipher for Android utilizes SQLCipher internally, the community edition also includes OpenSSL for the crypto provider.

How the encryption is happening on both (KitKat and Nougat) ? Are the encryption libraries enclosed in above @aar file ? and what are they ? (EX : OPENSSL , Java Crypto provider)

You can read about the design of SQLCipher here, also, you can review the source of SQLCipher for Android here.

And for 1000 rows below are the statistics on “SQLLite” and “SQLCipher” , is it true ?

The will be a performance impact moving from standard SQLite, often 5-15% depending on the application. We have some performance guidance for using SQLCipher here.

#3

Thank you for your reply.

It would be helpful to know why OpenSSL is proffered over Platform crypto ? any performance advantages please clarify.

The x86(closed to 1 MB) which is the part of library, is it going to be part of final Android APK file ?

Thanks in advance.

#4

Hi @AshokKasthuri

SQLCipher for Android statically links OpenSSL as opposed to using the system provided version of OpenSSL. Historically the version of OpenSSL found on different Android devices varied; statically linking the library provides a guarantee of the version being used with the library.

Yes, unless you exclude x86 support within your build process.

#5

Hello Nick,

You mention that one should be aware of potential import restrictions for some countries due to the inclusion of encryption technology.
Have you ever considered to hookup directly to the Android Java encryption functions? Obviously that means a lot of JNI transitions. But it does lessen or maybe even remove the impact of import restrictions.
Mainly wondering whether you tried it and discarded because of for example performance reasons, or maybe other reasons.

Thank you in advance!

#6

Hello @Rayzet

That is not something we have done, however the performance impact of that design may likely be unacceptable due to the heavy marshaling that would be required due to the database library being written in C.

#7

Hi,
Yes i also expect as much, but i’m no JNI expert.
Mainly wanted to confirm with you.
Thank you for the fast response.