Repository navigation
Android/arm64 startup regression after OpenSSL → LibTomCrypt switch (4.11.0 vs 4.17.0) #96
Description
Summary
Changing only net.zetetic:sqlcipher-android from 4.11.0 to 4.17.0 adds approximately 300 ms to cold activity launch in our Android application. Restoring the original 4.17.0 APK restores the delay.
Perfetto samples and native disassembly identify LibTomCrypt's PBKDF2-HMAC-SHA512 path during first encrypted database open as the bottleneck. The sampled 4.11.0/OpenSSL path uses ARM SHA-512 instructions; the 4.17.0/LibTomCrypt path uses scalar SHA-512 and repeated HMAC setup.
Related: sqlcipher-android #91, sqlcipher #620. This report adds a dependency-only A/B/A comparison and native hot-path evidence.
Environment
- Galaxy S25 Ultra (SM-S938U1), Android 16,
arm64-v8a. - SQLCipher Android Community Edition 4.11.0 versus 4.17.0; resolved versions and packaged native libraries verified.
- SQLDelight
AndroidSqliteDriverwithSupportOpenHelperFactory, opening an encrypted policy database during startup. - Passphrase API, not raw-key format; unchanged key/cipher/KDF configuration. Source defaults are PBKDF2-HMAC-SHA512, 256,000 rounds in both versions; runtime PRAGMAs were not collected.
- Same app source, other dependencies, signing, account and database data; non-debuggable release builds, R8 disabled.
Controlled results
Four untraced force-stop launches per condition, in order. Authentication/setup occurred beforehand. Before each launch, app-specific ART state was reset and status=verify confirmed; process absence and cold-launch classification were checked. One validation launch per install was excluded. Cooldowns were 20 seconds; thermal status remained 0.
| Condition | Android launch samples (ms) | Median |
|---|---|---|
| Original APK, SQLCipher 4.17.0 | 603, 603, 603, 597 | 603 ms |
| SQLCipher-only 4.11.0 control | 307, 301, 301, 311 | 304 ms |
| Exact original 4.17.0 APK restored | 602, 605, 595, 596 | 599 ms |
Measurement: Android am start -W TotalTime. The initial 4.17.0 median is 299 ms slower than the 4.11.0 control, and the delay returns after switching back.
These are activity-launch timings, not isolated database-open or PBKDF2 timings. The small cohorts establish a repeatable local signal, not population confidence intervals. APK resources/manifest were unchanged; aggregate uncompressed Dex size differed by only 116 bytes.
Trace and native-code evidence
Separate Perfetto captures at 100 Hz are excluded from the table. In the restored 4.17.0 trace, the main thread waits approximately 270 ms for SQLDelight's synchronized lazy database initialization while the owning worker runs on CPU in SQLCipher connection initialization/key derivation.
Native mapping build IDs were matched to the packaged ELFs. Because the libraries are stripped, attribution used disassembly, embedded diagnostic/source strings, and SHA-512 constants:
- 4.17.0: 35 startup samples contain
sqlcipher_ltc_kdf→pkcs_5_alg2. Its iteration loop callshmac_memory, repeatedly allocating and initializing HMAC state. Sampled leaf PCs execute scalar SHA-512 compression. This matches LibTomCrypt's PBKDF2 and HMAC implementations. - 4.11.0: sampled leaf PCs execute ARM
sha512h,sha512h2,sha512su0, andsha512su1instructions. Its OpenSSL 3.5.4 PBKDF2 implementation also reuses a keyed HMAC template.
This strongly implicates provider-related KDF execution, but does not separately quantify hardware acceleration versus HMAC setup/allocation costs. The 4.15.0 JNI critical-section fix is already included in the tested 4.17.0 build.
Application-level reproduction
- Build the same application with each SQLCipher version, preserving the encrypted database and key settings.
- Complete setup outside measurement; run four force-stop launches per version under the controls above, recording Android
TotalTime. - Restore the original 4.17.0 APK and repeat; capture separate CPU profiles of first database initialization.
A public standalone reproducer and direct first-open benchmark are not yet available. WAL/connection-pool multiplicity has not been independently isolated. Proprietary APKs/raw traces are not attached.
Questions for maintainers
- Is the loss of ARM SHA-512 acceleration in Android Community's PBKDF2 path expected or tracked?
- Is a supported 4.x fix planned for ARM acceleration and/or HMAC-state reuse, preserving KDF strength and database compatibility?
- Is this addressed in a newer release? If not, what additional measurements would help you investigate?
Activity
javadjafari1 commentedon Oct 13, 2026
Query-time regression on a low-end device — v4.13.0 → v4.14.0
This matches a benchmark I ran that brackets the provider switch itself
(v4.13.0 vs v4.14.0), rather than 4.11.0 vs 4.17.0.
Environment
Controlled results
100+ runs per version, medians:
That is a ~4.5× regression on ordinary query execution, not just open/KDF
cost — so unlike the launch-time numbers above, this isolates
per-page (AES-256-CBC + HMAC-SHA512) crypto throughput during page reads,
which on a page-cache-constrained device dominates query time.
PRAGMA cipher_providerreportsopensslon v4.13.0 andlibtomcrypton v4.14.0. Setting
PRAGMA cipher_provider = 'openssl'at runtime onthe v4.14.0 community AAR does not help — OpenSSL is not compiled into
the artifact, so this cannot be corrected per-database.
Source confirmation (v4.13.0...v4.14.0 diff)
sqlcipher/src/main/jni/sqlcipher/Android.mk: default CFLAGS changedfrom
-DSQLCIPHER_CRYPTO_OPENSSLto-DSQLCIPHER_CRYPTO_LIBTOMCrypt;static-libcryptois linked only when the CFLAGS already contain"SSL", so the shipped community build has no OpenSSL code at all
9004efb5bundles the LibTomCrypt v1.18.2 submodule; commit8129dcb3adds "recommended / default LTC compiler optimizations",still a portable pure-C implementation with no ARMv8 crypto-extension
/ NEON AES or SHA paths
Request
Echoing the above: please restore OpenSSL as the default provider for
the community edition artifacts (or publish an OpenSSL-enabled community
build), at minimum while pure-C LibTomCrypt lacks ARM hardware SHA/AES
acceleration. A ~4.5× regression on low-end devices makes v4.14.0+
effectively block upgrades for budget-device support.
sjlombardo commentedon Oct 14, 2026
Thanks for taking the time to write up this analysis and submit these reports. We acknowledge that the change to LibTomCrypt may change the performance characteristics of the library for some workloads and device families.
That said, the decision to switch was based on a broader set of factors than performance alone. This included ease of use, greatly simplified source builds, reduced footprint, and lower exposure for security reports. LibTomCrypt has been widely used for many, many years as a cryptographic provider for SQLCipher Community Edition packages. Furthermore, we've seen limited performance impact for most applications (with the exception of some outliers). Therefore, I want to be clear that we don't intend to change the direction right now, though that doesn't preclude potential future changes or improvements (including hardware acceleration).
If your application is heavily impacted by performance differences, several options are available today without library changes:
Applications not using password-based key material (e.g. those using randomized key material managed by Keystore, an online api, etc.) do not need to rely on key derivation at all. They can use raw keys which will completely eliminate that overhead (basically eliminating the cold-start problem). This is the single biggest startup optimization available. Note this applies where the key material is already high-entropy, so a passphrase-backed application would need to change its key management approach and rekey existing databases.
Applications using password-based key material can still externalize their key derivation or evaluate whether a lower-iteration count (PRAGMA kdf_iter) will provide adequate security with lower performance impact.
For per-page read / write impact, applications with appropriate threat models (e.g. those that run on devices where sandboxing makes database tampering difficult or impossible) can disable HMAC (PRAGMA cipher_use_hmac = OFF).
Since key derivation is deliberately slow and runs once per low-level connection, it is worth reviewing how applications open and hold database connections. sqlcipher-android can use a pool in some configurations (e.g. WAL mode), with each additional connection that initializes the key triggering derivation. The number of connections your application actually creates is a big part of the picture.
SQLCipher for Android is fully Open Source and still supports building against OpenSSL. So, if your needs dictate, you can clone this repo, build OpenSSL for Android yourself, and then create your own sqlcipher-android packages for use in your application.
If you want drop-in and completely seamless performance improvements, you can license SQLCipher Commercial or Enterprise libraries, which include optimized cryptographic providers. For sqlcipher-android, this will perform even faster than the old OpenSSL-only builds did. A 15-day free trial is available for evaluation.
Even outside of the encryption-specific options, there are many optimization opportunities that don't require encryption changes. These include tweaking the schema, queries, and indexes to minimize database access, wrapping writes in transactions, disabling secure_delete where the forensic tradeoff is acceptable, tuning cipher_page_size to the workload, and appropriate key material selection.
Finally, I want to directly address the specific questions asked. First, the loss of ARM SHA-512 acceleration in the Community build's KDF is expected. The included LibTomCrypt is a portable pure-C build without processor instructions. Second, there are no plans to change the default provider for 4.x at this time, which includes the request to restore OpenSSL as the default for Community edition.
In summary, we appreciate the analysis and reports, but we don't plan to change the underlying library at this time. Therefore we don't want you to expend more time collecting measurements or stats.