Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#96 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
32/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
android, java, sql
Domaine
databases, mobile

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

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?
Langage dominant
Java
Étoiles
277
Forks
39
Merge moyen
1 j 11 h
PR mergées (30 j)
1

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de sqlcipher/sqlcipher-android

Toutes les issues de sqlcipher/sqlcipher-android

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.