We are happy to announce the availability of SQLCipher 3.3.0. This release is based on the upstream SQLite 3.8.8.3 release which included many beneficial updates including a general performance increase of over 20% for the same number of CPU cycles from the previous release. Specifics for the SQLite 3.8.8.3 release are covered here.
Directly within SQLCipher we have included a few additional items as well. First, we introduced a new PRAGMA, cipher_default_page_size, a mechanism which facilitates setting a non-default page size value to be used when attaching databases. Next we have added API hooks to support FIPS integration within the OpenSSL crypto provider. SQLCipher for Android has also been updated with community edition binaries available here. Binaries that ship with support for OpenSSL have been upgraded to the latest 1.0.2a release. Commercial binary updates to be available soon.
android::MemoryBase was removed quite a while ago. Is it possible you didn’t fully upgrade all binary components within your project, or that your application is still referencing older binaries?
This is great news. Thank you guys for the hard work you do to provide a valuable resource for us. Can you provide me with a list configure options that you use to build the Android platform? https://www.sqlite.org/compile.html
I’ve had to rebuild the Android library myself to get at the options I need, but it would be a huge break if you would be wiling to include a few more for us on the Android side.
I specifically am looking for
SQLITE_ENABLE_FTS3, SQLITE_ENABLE_FTS4, SQLITE_ENABLE_RTREE, SQLITE_ENABLE_FTS3_PARENTHESIS
Hi There i have a question and not sure if I am even using this forum correct, as you can tell I’m brand new to this, My question is I have downloaded the app to my mac a couple years ago and have been using it with my iPod. I recently upgraded to a iPhone and installed the app to it, How do i get all my data (usernames and password) to install in the app on the iPhone. Curently they are still all installed on my iPod. Thank You Henry.
If you are referring to STRIP, we have put together some documentation on synchronization here. There are a few options available to you, either a cloud service such as Dropbox, or Google Drive, alternatively since you have the desktop version of the application you could also use local WiFi.
Is this the correct response to verifying the signature? The warning is worrying…
$ gpg --verify “sqlcipher-for-android-community-v3.3.0.zip.sig” "sqlcipher-for-
android-community-v3.3.0.zip"
gpg: Signature made 03/26/15 10:52:50 using RSA key ID 67FD0322
gpg: Good signature from "Zetetic LLC support@zetetic.net"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: D83F 5F9E B811 D6E6 B4A0 D9C5 D1FA 3A2A 97ED 25C2
Subkey fingerprint: A4EA 79E6 49E7 45B9 2117 A56F 0CB9 9EE2 67FD 0322
my application successfully works with the pre-built libsqlcipher_android.so file. We have tested with J, K, and M. I need to use my version of openssl which is 1.0.1c with maintenance on it. I successfully statically linked my libcrypto.a using the latest git master with my openssl with a few minor changes to make files. I changed external/openssl with mine removed the build_openssl.sh in the make files and replace git libcrypto.a with mine.
When I integrate my application I get a c crash in FIPS. From my previous experience if you do not enable FIPS the library should work without changing the vectors for the methods for the FIPS object model.
I replaced libsqlcipher_android.so, libdatabase_sqlcipher.so and libstlport_shared.so as well as sqlcipher.jar and my icudt46l.zip in my assets folder was the same because of the pre-built version we successfully used.
I used ndk 10e, crashes on libsqlcipher_android.so (FIPS_cipherinit+116) I see a similar issue with x86, but I am only interested in armeabi/armeabi7a
in the application we are currently just doing:
myDb.getWritableDatabase(key);
we did not enable fips as we are trying to make minimum changes for validation. What is the root cause of the crash?
@drcrypto Yes, that is the default output, indicating that the signature is good, but that you don’t trust our key. In order to get rid of the warning you would need to edit Zetetic’s signing key and explicitly trust it: https://www.gnupg.org/gph/en/manual/r899.html
@Ken_Montagna The first thing you should check is that you don’t have mismatched headers (i.e. make sure you are not using headers for one version, but then linking another). That can cause some odd and esoteric behavior.
Outside of that, it’s very difficult to troubleshoot this sort of issue since there are so may places that things can go wrong in the build chain, linking, deployment etc. For this reason, we typically don’t support custom builds of SQLCipher without an enterprise support agreement.
If you are finding commercial value in using SQLCipher and would like to discuss enterprise support options please feel free to reach out to us at support@zetetic.net.