Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#96 0 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
32/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
android, java, sql
Domínio
databases, mobile

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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?
Linguagem predominante
Java
Estrelas
277
Forks
39
Merge médio
1d 11h
PRs com merge (30d)
1

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de sqlcipher/sqlcipher-android

Todas as issues de sqlcipher/sqlcipher-android

Issues semelhantes

Mais issues de Java

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.