Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#96 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
32/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
android, java, sql
Área
databases, mobile

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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?
Lenguaje dominante
Java
Estrellas
277
Forks
39
Merge medio
1 d 11 h
PR fusionados (30 d)
1

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de sqlcipher/sqlcipher-android

Todos los issues de sqlcipher/sqlcipher-android

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.