Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Android/arm64 startup regression after OpenSSL → LibTomCrypt switch (4.11.0 vs 4.17.0)

Open
  • Is something wrong?
#96 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
32/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
android, java, sql
Domain
databases, mobile

Research direction

Start by comparing the cited OpenSSL PBKDF2 and LibTomCrypt PBKDF2/HMAC implementations, then review the reported Perfetto and native-disassembly evidence. The report says a standalone reproducer and direct first-open benchmark are not yet available, so first determine how to isolate database-open time and reproduce the ARM64 regression. Done means establishing whether the KDF path causes the slowdown and providing maintainers evidence to assess acceleration or HMAC-state reuse without changing KDF strength or database compatibility.

Written by the indexing model from the issue text.

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 AndroidSqliteDriver with SupportOpenHelperFactory, 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 calls hmac_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, and sha512su1 instructions. 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

  1. Build the same application with each SQLCipher version, preserving the encrypted database and key settings.
  2. Complete setup outside measurement; run four force-stop launches per version under the controls above, recording Android TotalTime.
  3. 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

  1. Is the loss of ARM SHA-512 acceleration in Android Community's PBKDF2 path expected or tracked?
  2. Is a supported 4.x fix planned for ARM acceleration and/or HMAC-state reuse, preserving KDF strength and database compatibility?
  3. Is this addressed in a newer release? If not, what additional measurements would help you investigate?
Dominant language
Java
Stars
277
Forks
39
Avg merge
1d 11h
Merged PRs (30d)
1

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from sqlcipher/sqlcipher-android

All issues in sqlcipher/sqlcipher-android

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.