Pith. sign in

REVIEW 4 major objections 5 minor 18 references

Assessing and Enhancing Quantum Readiness in Mobile Apps

T0 review · 4 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Across 4,018 Android apps, the paper finds widespread quantum-vulnerable crypto and zero post-quantum adoption, and it shows that current LLMs cannot complete PQC migrations.

desk verdict A plausible but under-validated first cut at quantum-readiness measurement for Android apps; the zero-PQC-adoption and LLM-failure claims need artifacts and validation before they can be trusted. read the letter →

arxiv 2506.00790 v1 pith:ALMGGQTC submitted 2025-06-01 cs.CR cs.SE

Joseph Strauss , Krishna Upadhyay , A.B. Siddique , Ibrahim Baggili , Umar Farooq This is my paper
classification cs.CRcs.SE
keywords post-quantumcryptographyAndroidappsstaticanalysiscryptographicmigrationlargelanguagemodelsharvestnowdecryptlaterquantumreadiness
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to answer two questions: how prepared are Android apps for quantum computers, and can current AI coding tools upgrade them. It scans 4,018 apps from Google Play and F-Droid by statically resolving the algorithm strings passed to cryptographic factories, then labels each use as quantum-safe or quantum-vulnerable. The paper reports that quantum-vulnerable algorithms are everywhere—MD5 in over 2,500 apps, SHA-1 in over 2,400, RSA in 781—and that no app shows evidence of post-quantum cryptography. It then tests LLMs on migration tasks and finds they handle simple hash swaps but none produce a correct Kyber or Dilithium integration. A sympathetic reader should care because if the measurement holds, mobile ecosystems are starting the post-quantum transition at close to zero, with automated assistance not yet up to the job.

What carries the argument

The load-bearing mechanism is a backward dataflow analysis that resolves string arguments passed to factory methods such as Cipher.getInstance() and KeyPairGenerator.getInstance(), recovering exact algorithm identifiers like AES/CBC/PKCS5Padding or RSA/ECB/PKCS1Padding. Those identifiers are then labeled quantum-safe or quantum-vulnerable using the NIST post-quantum categorization. On the migration side, the mechanism is the LLM prompt-and-edit setup: each model receives source files, target API references, and in some cases a PR-like diff, and is run in both plain edit mode and agentic mode; the unit of success is a secure, compilable patch, and the paper's finding is that the multi-file, dependency-aware nature of PQC changes defeats all tested models.

What would settle it

Re-run the analysis on a sample of apps whose cryptographic calls are independently verified through runtime instrumentation or source review; if even a handful of unresolved calls turn out to use Kyber or Dilithium, the zero-PQC conclusion fails, and if many recovered 'RSA' strings are dead code, the prevalence estimates would need revision.

Watch

Extended reading notes

Core claim

The paper's central claim is that the Android app ecosystem, as sampled through 4,018 binaries, is not quantum-ready: RSA appears in 781 apps, SHA-1 in 2,454, MD5 in 2,531, and no production app uses NIST-standardized post-quantum algorithms. It claims this is the first large-scale measurement of quantum readiness in mobile apps, and it pairs that measurement with an intervention study: four leading LLMs (GPT-4o, Gemini Flash 2.0, Claude Sonnet 3.7, DeepSeek) were asked to migrate representative code from SHA-1 and RSA to SHA-256, Kyber, or Dilithium. Every model succeeded at the simple hash replacement, but none completed a PQC migration; the outputs lacked correct multi-file edits, imports, or dependency handling. The paper concludes that structured guidance and system-aware tooling are needed before LLM-assisted PQC migration can work.

Load-bearing premise

The measurement rests on the assumption that the backward dataflow analysis recovers the exact algorithm strings passed to factory methods such as Cipher.getInstance() and KeyPairGenerator.getInstance(); if apps hide algorithm choices behind dynamically constructed strings, reflection, JNI, or native code, the reported prevalence and the conclusion that no production app adopts PQC could be wrong.

Editorial extensions

If this is right

  • Any serious attempt to bring Android apps to post-quantum safety will have to coordinate changes across multiple files, because the mechanisms that defeated the LLMs are the same ones a human engineer must manage: new method bodies, imports, and dependency updates.
  • Users of apps that rely on MD5, SHA-1, or RSA should assume that data captured today can be decrypted or forged once a large-scale quantum computer exists.
  • Simple cryptographic hygiene such as upgrading SHA-1 to SHA-256 is within reach of current AI code assistants, so a portion of crypto debt could be addressed before PQC tooling matures.
  • The absence of PQC imports in production apps means the ecosystem is starting from near zero after NIST's standardization, not partway through a transition.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper, the zero-PQC result is best read as a lower bound: apps using reflection, JNI, or server-supplied algorithm parameters could hide PQC usage or vulnerable primitives from the static scanner.
  • The same multi-file failure pattern suggests a concrete research target: migration tools that pair static analysis with dependency-aware patch generation might outperform unassisted LLMs on PQC upgrades.
  • The harvest-now-decrypt-later threat applies unevenly; apps protecting short-lived session tokens face less quantum risk than apps storing health, financial, or authentication data for years, so readiness priorities could be differentiated by data lifetime.
  • If Android's standard library later ships Kyber and Dilithium defaults, a repeat of this measurement could show rapid adoption driven by default choices rather than developer effort.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper reports a static analysis of 4,018 Android apps to measure the prevalence of quantum-vulnerable cryptographic algorithms (MD5, SHA-1, RSA, and others) and to test whether large language models can migrate app code to post-quantum cryptographic algorithms such as Kyber and Dilithium. The authors find widespread use of legacy algorithms and report that no analyzed app adopts PQC in production, and that no tested LLM produced a correct, complete post-quantum migration. The paper's contributions are intended as an end-to-end pipeline: binary-level cryptographic usage extraction followed by LLM-assisted migration.

Significance. If the measurement is validated, this would be one of the first large-scale snapshots of quantum readiness in the mobile app ecosystem, and the negative LLM migration result would be a useful, cautionary data point for automated security refactoring. The threat model is clearly stated, and the classification of algorithms as quantum-vulnerable versus quantum-safe follows NIST IR 8105, which is a reasonable external basis. The use of CryptoAPI-Bench-inspired rules is a sensible starting point, but the paper does not validate the analyzer against a ground truth, does not release the detector or dataset, and does not describe the LLM experimental protocol in sufficient detail. For these reasons, the headline prevalence and zero-PQC-adoption claims are not yet auditable from the manuscript alone.

major comments (4)
  1. [III (Methodology), Phase 1] The static analysis that produces every prevalence number in Table I is not validated. The paper states that backward dataflow analysis resolves string arguments to Cipher.getInstance() and KeyPairGenerator.getInstance(), but reports no precision, recall, false-positive rate, or comparison with a ground-truth corpus such as CryptoAPI-Bench, and no dynamic analysis. Since Android apps can construct algorithm strings at runtime or perform cryptography in native code via JNI/NDK and TLS stacks like BoringSSL, such usages are invisible to the stated extraction. This matters most for the absence claim in Section IV: if any of the 4,018 apps uses PQC through a native library or a hybrid TLS ciphersuite, the statement that 'PQC adoption remains absent in production apps' is unsupported. The mention of 'unused class-level imports referencing PQC libraries' shows that the scanner can surface PQC references without a stated method for distinguishing live use from dead code, and the same ambiguity could affect the legacy-algorithm counts if the matching rules are not call-site precise.
  2. [IV (Results), LLM migration experiments] The claim that 'no model completed post-quantum migrations' is the paper's second central result, but the experimental protocol is not described. No task set, prompt templates, trial counts per model, model versions, temperature or sampling settings, or grading rubric are given, and no examples of successful or failed patches are included. The phrases 'edit mode' and 'agentic mode' are used without definitions. Without this information, and without release of the prompts and outputs, the result is not reproducible, and the statement that 'all tested models performed well on hash upgrades' cannot be quantified or compared across models.
  3. [III (Methodology), dataset collection] The dataset description is incomplete. Section III says 4,018 apps were collected from Google Play and F-Droid, but gives no collection date, category distribution, app selection criteria, version pinning, package list, or APK hashes. The analyzer is also not released. A measurement paper whose headline numbers cannot be reproduced from the text alone does not meet the usual standard for a large-scale empirical claim. Please release the detector and dataset, or provide a detailed validation appendix with the false-positive and false-negative rates on a labeled corpus.
  4. [Table I] The table reports '# of instances' and '# of apps' without defining either. RSA has 781 instances and 781 apps, while MD5 has 28,994 instances across 2,531 apps; the text says SHA-256 is 'the most frequently used algorithm' based on app count, but MD5 has more instances. If the unit of measurement is an app, the per-app denominator matters; if it is an API call, the table needs call-site counts and normalization. This ambiguity makes it impossible to interpret the prevalence claims and should be clarified with a precise counting definition.
minor comments (5)
  1. [V (Conclusion)] The sentence 'While LLMs succeed at basic refactoring but fall short on secure, compilable PQC migrations' is grammatically incomplete; it should read 'While LLMs succeed at basic refactoring, they fall short on secure, compilable PQC migrations.'
  2. [I (Introduction) / V (Conclusion)] The paper claims to present 'the first large-scale analysis of quantum readiness in Android apps' but has no related-work section and does not compare with any prior Android cryptographic measurement studies. This claim should be qualified with a literature comparison.
  3. [II (Threat Model)] The threat model mentions insecure cipher modes such as ECB and non-random IVs, but Table I does not report misuse patterns for these configurations. Please clarify whether the static analysis detects such misuses or whether the table only lists algorithm names.
  4. [Table I] The footnote that AES/CBC is 'secure with 256-bit keys' should also clarify the security level assumed for SHA-256 and MD5/SHA-1, since post-quantum safety is not binary and depends on the security parameter under Grover's algorithm.
  5. [III (Methodology)] Figure 2 is very high-level; adding labeled arrows to show exactly what metadata is passed from Phase 1 to Phase 2 would improve reproducibility of the pipeline description.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the central measurement is externally labeled and the LLM evaluation is a direct experiment; unvalidated static analysis is a correctness risk, not circularity.

full rationale

The paper's derivation chain contains no step that reduces to its inputs by construction. The central measurement (prevalence of MD5, SHA-1, RSA, and absence of PQC adoption) comes from static analysis whose labels are assigned from an external classification source, namely the NIST post-quantum report [3] and the external CryptoAPI-Bench [2] rules, not from data fitted within this work. There are no fitted parameters, no load-bearing self-citations, and no ansatz smuggled in via citation; the authors' own binary analysis outputs are the measurements, not predictions derived from definitions. The LLM migration results are direct empirical evaluations against compilation and correctness criteria, not a derivation from assumptions. The skeptical concern that the backward dataflow analysis is unvalidated, with no ground truth, precision, recall, or dynamic cross-check, is a serious correctness and validity risk, but it is not a circularity concern: an unvalidated measurement can be wrong without being circular. Similarly, the observation that unused PQC imports exist while live PQC usage is absent is a measurement interpretation issue, not a self-referential reduction. Accordingly, no circular step is identified.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

The paper introduces no free parameters or invented entities; all classifications come from external standards. The main burden is on the unvalidated dataflow analysis, the unstated LLM evaluation protocol, and the future quantum threat assumption.

assumptions (5)
  • domain assumption A large-scale fault-tolerant quantum computer running Shor's algorithm will be available.
    The entire threat model and the need for migration rest on this future capability, stated in Section II, but the paper does not argue for its likelihood or timeline.
  • domain assumption Backward dataflow analysis correctly resolves algorithm strings in factory methods such as Cipher.getInstance().
    Section III uses this to label each detected instance, but no validation, ground truth, or false-positive analysis is reported, so correct resolution is assumed.
  • domain assumption SHA-256 and AES-256 are quantum-safe while RSA, SHA-1, and MD5 are quantum-vulnerable.
    The paper takes these labels from NIST IR 8105 and Grover's algorithm, with a caveat for AES key sizes. This is a standard but external classification, and it is an input to the analysis rather than a result of it.
  • ad hoc to paper The LLM migration tasks and prompts are representative of realistic developer workflows.
    Section III states the prompts are 'designed to reflect realistic developer workflows,' but the actual tasks, prompts, and grading criteria are not included, so representativeness is asserted rather than demonstrated.
  • domain assumption The 4,018 apps collected from Google Play and F-Droid are representative of the mobile ecosystem.
    Section III describes them as 'from diverse categories' but gives no sampling rules, dates, or inclusion criteria, so representativeness is assumed.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Assessing and Enhancing Quantum Readiness in Mobile Apps." pith.science (2026). https://pith.science/paper/ALMGGQTC

@misc{pith2026250600790,
  author       = {Pith},
  title        = {Pith review of: Assessing and Enhancing Quantum Readiness in Mobile Apps},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ALMGGQTC}},
  note         = {Machine review of arXiv:2506.00790}
}
read the original abstract

Quantum computers threaten widely deployed cryptographic primitives such as RSA, DSA, and ECC. While NIST has released post-quantum cryptographic (PQC) standards (e.g., Kyber, Dilithium), mobile app ecosystems remain largely unprepared for this transition. We present a large-scale binary analysis of over 4,000 Android apps to assess cryptographic readiness. Our results show widespread reliance on quantum-vulnerable algorithms such as MD5, SHA-1, and RSA, while PQC adoption remains absent in production apps. To bridge the readiness gap, we explore LLM-assisted migration. We evaluate leading LLMs (GPT-4o, Gemini Flash, Claude Sonnet, etc.) for automated cryptographic migration. All models successfully performed simple hash replacements (e.g., SHA-1 to SHA-256). However, none produced correct PQC upgrades due to multi-file changes, missing imports, and lack of context awareness. These results underscore the need for structured guidance and system-aware tooling for post-quantum migration

Figures

Figures reproduced from arXiv: 2506.00790 by the authors.

Figure 1
Figure 1. Harvest Now, Decrypt Later (HNDL) attack model [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. System overview: Our two-phase system analyzes [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

18 extracted references · 4 canonical work pages

  1. [1]

    Eason, B

    G. Eason, B. Noble, and I. N. Sneddon, ``On certain integrals of Lipschitz-Hankel type involving products of Bessel functions,'' Phil. Trans. Roy. Soc. London, vol. A247, pp. 529--551, April 1955

    1955

  2. [2]

    Clerk Maxwell, A Treatise on Electricity and Magnetism, 3rd ed., vol

    J. Clerk Maxwell, A Treatise on Electricity and Magnetism, 3rd ed., vol. 2. Oxford: Clarendon, 1892, pp.68--73

  3. [3]

    I. S. Jacobs and C. P. Bean, ``Fine particles, thin films and exchange anisotropy,'' in Magnetism, vol. III, G. T. Rado and H. Suhl, Eds. New York: Academic, 1963, pp. 271--350

    1963

  4. [4]

    Elissa, ``Title of paper if known,'' unpublished

    K. Elissa, ``Title of paper if known,'' unpublished

  5. [5]

    Nicole, ``Title of paper with only first word capitalized,'' J

    R. Nicole, ``Title of paper with only first word capitalized,'' J. Name Stand. Abbrev., in press

  6. [6]

    Yorozu, M

    Y. Yorozu, M. Hirano, K. Oka, and Y. Tagawa, ``Electron spectroscopy studies on magneto-optical media and plastic substrate interface,'' IEEE Transl. J. Magn. Japan, vol. 2, pp. 740--741, August 1987 [Digests 9th Annual Conf. Magnetics Japan, p. 301, 1982]

    1987

  7. [7]

    Young, The Technical Writer's Handbook

    M. Young, The Technical Writer's Handbook. Mill Valley, CA: University Science, 1989

    1989

  8. [8]

    D. P. Kingma and M. Welling, ``Auto-encoding variational Bayes,'' 2013, arXiv:1312.6114. [Online]. Available: https://arxiv.org/abs/1312.6114

    arXiv 2013

Show all 18 references
  1. [9]

    Liu, ``Wi-Fi Energy Detection Testbed (12MTC),'' 2023, gitHub repository

    S. Liu, ``Wi-Fi Energy Detection Testbed (12MTC),'' 2023, gitHub repository. [Online]. Available: https://github.com/liustone99/Wi-Fi-Energy-Detection-Testbed-12MTC

    2023

  2. [10]

    Department of Health and Human Services, Substance Abuse and Mental Health Services Administration, Office of Applied Studies, August, 2013, DOI:10.3886/ICPSR30122.v2

    ``Treatment episode data set: discharges (TEDS-D): concatenated, 2006 to 2009.'' U.S. Department of Health and Human Services, Substance Abuse and Mental Health Services Administration, Office of Applied Studies, August, 2013, DOI:10.3886/ICPSR30122.v2

    2006 doi

  3. [11]

    Eves and J

    K. Eves and J. Valasek, ``Adaptive control for singularly perturbed systems examples,'' Code Ocean, Aug. 2023. [Online]. Available: https://codeocean.com/capsule/4989235/tree

    2023

  4. [12]

    write newline

    " write newline "" initialize.prev.this.status FUNCTION begin.bib " write newline preamble empty 'skip preamble write newline if " thebibliography " longest.label * " " * write newline " [1] #1 " write newline " url@samestyle " write newline " " write newline " [2] #2 " write ...

  5. [13]

    4" FUNCTION default.is.dash.repeated.names #1 FUNCTION default.name.format.string

    11em plus .33em minus .07em 4000 4000 100 4000 4000 500 `\.=1000 = #1 \@IEEEnotcompsoconly \@IEEEcompsoconly #1 * [1] 0pt [0pt][0pt] #1 * [1] 0pt [0pt][0pt] #1 * \| ** #1 \@IEEEauthorblockNstyle \@IEEEcompsocnotconfonly \@IEEEauthorblockAstyle \@IEEEcompsocnotconfonly \@IEEEco...

    2007

  6. [14]

    write newline

    " write newline "" initialize.prev.this.status FUNCTION begin.bib " write newline preamble empty 'skip preamble write newline if " thebibliography " longest.label * " " * write newline " [1] #1 " write newline " url@samestyle " write newline " " write newline " [2] #2 " write ...

  7. [15]

    https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards, 2024

    Nist releases first 3 finalized post-quantum encryption standards. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards, 2024. Accessed: 2025-04-01

    2024

  8. [16]

    Cryptoapi-bench: A comprehensive benchmark on java cryptographic api misuses

    Sharmin Afrose, Sazzadur Rahaman, and Danfeng Yao. Cryptoapi-bench: A comprehensive benchmark on java cryptographic api misuses. In 2019 IEEE Cybersecurity Development (SecDev) , pages 49--61, 2019

    2019

  9. [17]

    Report on post-quantum cryptography

    Lily Chen, Stephen Jordan, Yi-Kai Liu, Dustin Moody, Rene Peralta, Ray Perlner, and Daniel Smith-Tone. Report on post-quantum cryptography. https://doi.org/10.6028/NIST.IR.8105, 2016. Accessed: 2025-04-01

    2016 doi

  10. [18]

    Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer

    Peter W Shor. Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer. SIAM review , 41(2):303--332, 1999

    1999

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.