{"id":"b2a0ec4b-8aa6-4bc8-be97-38296b59d002","arxiv_id":"2412.05904","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":1.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A review of how quantum computers could break healthcare IoT encryption, and why post-quantum cryptography migration is difficult on resource-constrained medical devices.","lead":"This book chapter surveys how future quantum computers could break the encryption used by healthcare IoT devices such as glucose monitors, smart inhalers, and heart-rate sensors, and reviews post-quantum cryptography and quantum key distribution as countermeasures. A general reader should read it for a plain-language map of a known but unresolved migration problem: securing small, low-power medical devices before quantum attacks become practical.","discovery_kind":"review","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The chapter's 'near future' threat claim lacks a credible timeline: Table 1 and Table 2 report AES-128 break times that differ by about 12 orders of magnitude, so the central urgency is asserted rather than demonstrated.","rationale":"The reader's conditional verdict is appropriate. The chapter is a review, so the test is not about a new derivation but about whether the central urgency is evidenced. The strongest load-bearing soft spot is the timeline and the quantitative support for it: even if every device resource figure were exactly correct, the conclusion that healthcare IoT devices will be vulnerable 'in the near future' still depends on when a cryptographically relevant quantum computer exists. The inconsistency between Table 1 and Table 2 is concrete and checkable, and it directly affects the credibility of the chapter's only quantitative threat assessment. I do not elevate the device-specification details to the same level, because the central claim does not hinge on exact RAM or flash figures; the resource-feasibility discussion is secondary, and the chapter's own examples show that constrained devices struggle with PQC even under optimistic assumptions. Thus the reader's identification of the timeline as a load-bearing assumption is correct, but I would not move the verdict further toward rejection. The chapter's qualitative message is consistent with the broader literature, and the factual errors it contains are correctable. Keeping the verdict as conditional, with the concrete check above, is the right outcome.","tokens_in":14995,"tokens_out":7163,"duration_ms":78674,"concrete_test":"Recompute the AES-128 rows in Tables 1 and 2 from a single stated model. Take a published AES-128 Grover circuit (for example, Grassl et al. 2016 or Jaques et al. 2020), apply the chapter's stated 10^9 operations-per-second assumption from Section 2.4, and check whether Table 2's 585 years is reproduced. Then add the logical-qubit and surface-code overhead apparently used in Table 1 and recompute the wall-clock time. If the two tables still differ by more than an order of magnitude after accounting for error correction, the quantitative threat evidence is internally inconsistent and the 'near future' claim requires an independent supporting citation; if they agree, the discrepancy is an artifact of unstated assumptions and should be explained in the text.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim in Sections 1.2 and 2.2 is that traditional cryptographic algorithms in healthcare IoT 'will be vulnerable in the near future' and that quantum attackers could then access records and control devices. That claim requires a cryptographically relevant quantum computer to arrive within a relevant time window. The chapter never supplies a timeline or a reproducible resource estimate for such a machine. Its only quantitative support is Table 1, but that table is internally inconsistent with Section 2.4 and Table 2: AES-128 is listed as 2.61×10^12 years in Table 1, while Table 2 gives 585 years under an explicit 10^9 operations-per-second assumption. RSA-1024 at 3.58 hours and the ECC rows also lack a stated error-correction model or derivation from the cited source. The chapter does not explain whether Table 1 includes quantum error-correction overhead and Table 2 does not, so a reader cannot tell which estimate is being relied on. Because the near-term threat is the load-bearing premise for urgency, this is a correctness gap in the argument, not merely a typo. It does not defeat the broader consensus that PQC migration is prudent, but it means the device-control scenarios in Sections 2.2.1–2.2.3 should be presented as conditional on a fault-tolerant machine appearing within device lifetimes, not as an established near-term certainty.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"This book chapter surveys the quantum computing threat to cryptographic systems used in healthcare IoT. It reviews quantum attacks on RSA, ECC, AES, and hash functions, presents three healthcare IoT use cases (continuous glucose monitoring, smart inhalers, and heart-rate monitoring), and discusses post-quantum cryptography (PQC), quantum key distribution (QKD), and global standardization efforts such as NIST and IETF initiatives. The central claim, stated in Sections 2.2 and 2.2 of the healthcare IoT discussion, is that current public-key algorithms used in healthcare IoT devices will be vulnerable to quantum computers in the near future, requiring migration to quantum-resistant primitives despite severe device resource constraints.","tokens_in":15201,"tokens_out":5821,"duration_ms":56265,"significance":"The chapter addresses a timely and practically important topic: the security of resource-constrained medical IoT devices in a future with cryptographically relevant quantum computers. Its strengths are the accessible overview of Shor's and Grover's algorithms, the concrete device datasheet figures (e.g., CGM, K32W061, QN9090, STM32, MSP430), the use-case-specific threat narratives, and the summary of PQC projects (PQCrypto, Open Quantum Safe, PQClean, SAFECrypto, NIST, IETF). The chapter does not ship machine-checked proofs or new derivations, but it usefully compiles and organizes external evidence for a non-specialist readership. However, the quantitative material that is meant to support the urgency claim is internally inconsistent, and several specific cryptographic claims are inaccurate. These issues are local and fixable, but they are load-bearing for the chapter's 'near future' urgency argument and therefore require revision.","major_comments":[{"comment":"The AES-128 break times in Table 1 and Table 2 differ by roughly 12 orders of magnitude: Table 1 reports 2.61×10^12 years, while Table 2 reports 585 years under an explicit 10^9 operations-per-second assumption. The chapter does not explain whether Table 1 includes quantum error-correction overhead, code distance, parallelization, or a different clock model, so a reader cannot determine which estimate the argument relies on. This matters because the 'near future' claim in Section 2.2 is the load-bearing premise for urgency. Please reconcile the tables by stating a single, coherent set of assumptions or by removing the exact times and instead citing ranges with sources.","section":"Section 2.4 and Tables 1, 2"},{"comment":"The text states that Shor's algorithm can factor a 1024-bit number 'in about 10 hours,' while Table 1 lists RSA-1024 as 3.58 hours. No derivation or error-correction model is provided for either number, and the cited source is a National Academies report that does not itself give simple wall-clock times of this kind. Additionally, the ECC-521 row in Table 1 lists 1.13×10^6 physical qubits, which is an order of magnitude smaller than the ECC-384 row's 9.05×10^6; this is internally implausible unless a different error-correction code or security model is intended. The table must be corrected and the source assumptions stated explicitly.","section":"Section 2.3 and Table 1"},{"comment":"The chapter recommends 'adopting Post-Quantum Cryptography (PQC) algorithms like Kyber, Dilithium, and NTRUEncrypt, as recommended by the National Institute of Standards and Technology (NIST) [49].' NTRUEncrypt was not selected by NIST for standardization; it was a third-round alternate candidate, and the cited NIST status report [49] does not recommend it as a standard. This is a factual error in a recommendation that practitioners may follow. The sentence should be corrected to name only NIST-selected algorithms (e.g., ML-KEM/Kyber and ML-DSA/Dilithium) or to state the actual status of NTRUEncrypt.","section":"Section 4.2.3 (Use Case-3 mitigation)"},{"comment":"The threat scenarios are stated with near-certainty, e.g., 'traditional cryptographic algorithms that are widely being used in today's healthcare IoT devices will be vulnerable in the near future.' Given the unresolved timeline and resource-estimate inconsistencies noted above, these statements should be framed as conditional on a cryptographically relevant fault-tolerant quantum computer arriving within the confidentiality lifetime of the data and devices. In particular, the 'harvest now, decrypt later' argument should explicitly weigh data-retention periods against expected quantum-development timelines, or it should be presented as a risk-management rationale rather than an established immediate threat.","section":"Sections 2.2 and 2.2.1–2.2.3"}],"minor_comments":[{"comment":"The headings after '3.3 IoT Perspective' are misnumbered: '1.1 PQC General Implementation Requirements', '1.2 IoT Perspective', and '2 Overview of HealthCare IoT' should be renumbered to continue the sequence (e.g., Sections 3.4, 3.5, and 4). This is likely a carryover from an earlier draft and should be fixed in the final version.","section":"Section numbering after Section 3.3"},{"comment":"The text says IBM Condor 'demonstrates significant progress towards achieving quantum supremacy'; Condor is a 1,121-qubit processor, but quantum supremacy has not been demonstrated with it. The wording should be changed to 'towards fault-tolerant quantum computing' or 'quantum utility.'","section":"Section 2.1 (IBM Condor)"},{"comment":"Section 3 says NIST's PQC standardization process is 'currently in its fourth round,' while Section 5.1 states that NIST finalized the selection in 2022, selecting three signatures and one KEM. These statements should be harmonized with the actual 2024 final standards (ML-KEM, ML-DSA, SLH-DSA) and the fourth-round KEM candidates.","section":"Section 3 vs. Section 5.1 (NIST process)"},{"comment":"Reference [57] duplicates reference [4], and reference [60] (a paper on GNSS time synchronization in vehicular networks) appears to be unrelated to the sentence about NB-IoT and LTE standardization in which it is cited; the citation placement should be checked.","section":"References"},{"comment":"Table 2 lists RC4 with a 2048-bit key and a Grover complexity of O(2^1024) operations. While RC4 supports variable key sizes, including it in a table of symmetric block ciphers without comment may confuse readers, since RC4 is a stream cipher and is not part of current NIST-recommended suites; a footnote or removal would improve clarity.","section":"Table 2"}],"recommendation":"major_revision","confidential_remarks":"The chapter is a survey and its core qualitative recommendation—that healthcare IoT should plan for PQC migration—is consistent with the broader consensus in the field. The main problem is that the quantitative tables are mutually inconsistent, and the text makes stronger 'near future' claims than its own evidence supports. These issues are fixable within the manuscript's scope, so I do not see them as grounds for rejection. The fit for a book chapter on quantum threats is appropriate, but the authors should make the assumptions behind Table 1 and Table 2 explicit and correct the NTRUEncrypt and NIST-process statements before publication."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this is a readable survey chapter, not a research paper. It does a decent job applying known quantum-attack results to healthcare IoT use cases and stresses a real point: constrained medical devices make PQC migration genuinely hard. But the quantitative support is internally inconsistent and there are avoidable factual/citation errors. I would not cite it for specific numbers today, though with corrections it could be a useful overview.\n\nWhat is genuinely useful: the chapter walks through three concrete healthcare IoT deployments — remote glucose monitoring, smart inhalers, heart rate monitors — and gives hardware figures (RAM, ROM, clock speed) for the relevant microcontrollers. It also summarizes the NIST PQC process and important implementation projects (pqm4, OQS, PQClean, SAFECrypto). The conclusion that Dilithium is too RAM-heavy for low-end devices and Kyber is more practical comes from the embedded-systems literature and is credible.\n\nSoft spots, in rough order of importance. First, the central urgency claim — that classical crypto in healthcare IoT will be vulnerable 'in the near future' — is asserted, not demonstrated. There is no timeline or resource estimate for a cryptographically relevant machine. The problem is compounded by an internal contradiction: Table 1 lists AES-128 break time as 2.61×10^12 years, while Table 2 gives 585 years under an explicit 10^9 operations/second assumption. That is a difference of about twelve orders of magnitude, and the chapter never explains the basis (e.g., whether quantum error correction is included). A reader cannot tell which estimate is meant to be load-bearing. Second, Section 2.2.3 says NTRUEncrypt is 'recommended by NIST' for heart-rate monitoring; NTRU was not among the standardized algorithms. Third, the section numbering is garbled — '1.1' and '1.2' appear inside Section 3, and the healthcare IoT section is numbered '2'. Fourth, reference [60] (GNSS time synchronization) does not support the sentence it is attached to about NB-IoT/LTE standardization constraints. These are fixable, but they make the chapter unreliable for quantitative claims without checking sources.\n\nOverall, the big-picture message — quantum threats warrant PQC migration planning for healthcare IoT — holds up and matches the broader consensus. The chapter just needs careful revision before it is usable as a reference. Who should read it: someone wanting a quick orientation to the topic, not someone making security decisions based on the tables. I would send it to peer review with expectations of substantial revision rather than desk reject it, because the survey structure and use-case focus have value.","headline":"A useful but uneven review chapter that needs quantitative and citation cleanup before it is trustworthy.","tokens_in":15778,"tokens_out":3952,"would_cite":false,"duration_ms":37459,"reading_group":"no","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This chapter argues that quantum computers will break the encryption protecting healthcare IoT devices, and that migration to post-quantum cryptography must start before fault-tolerant machines arrive.","keywords":["quantum threat","healthcare IoT","post-quantum cryptography","Shor's algorithm","Grover's algorithm","harvest now decrypt later","medical device security","Kyber"],"falsifier":"A concrete check would be comparing credible hardware roadmaps against the roughly 2,050–8,194 logical qubits the chapter cites as needed to break RSA-1024 through RSA-4096; if fault-tolerant machines at that scale are predicted to arrive only after the confidentiality lifetime of current medical data expires, the urgency claim weakens. Another decisive observation would be running Kyber and Dilithium on a representative glucose-monitor microcontroller with 32–64 KB of RAM and finding that they fit, which would overturn the resource-constraint conclusion.","tokens_in":14767,"feed_emoji":"🔐","tokens_out":9405,"duration_ms":85704,"temperature":0.7,"pith_summary":"This chapter argues that the encryption currently protecting healthcare IoT devices—RSA, ECC, and AES—will be broken by sufficiently powerful quantum computers, and that this is a near-term problem because data intercepted today can be decrypted later. It makes the threat concrete by describing what a quantum attacker could do: read and alter patient records, manipulate real-time readings from glucose monitors, smart inhalers, and heart-rate sensors, and take control of devices such as pacemakers and insulin pumps. The chapter then surveys post-quantum cryptography (PQC) and quantum key distribution (QKD), and evaluates which candidate algorithms fit the severe memory and clock limits of real medical devices. A sympathetic reader would take away that healthcare IoT needs a planned, resource-aware migration to quantum-resistant algorithms, not a wait-and-see posture.","feed_headline":"Quantum computers will break healthcare IoT encryption","feed_subtitle":"Attackers could read and alter patient data and seize control of pacemakers, insulin pumps, and monitors.","key_machinery":"The carrying mechanism of the argument is a pairing between quantum attack estimates and device resource ceilings. Shor's algorithm, a polynomial-time quantum factoring and discrete-log method, would break RSA and ECC; Grover's algorithm, a quadratic-speedup search, would reduce the effective security of a 128-bit AES key to about 64 bits. Against those attack estimates, the chapter sets concrete hardware limits—continuous glucose monitors with 32–64 KB of RAM, smart-inhaler microcontrollers with about 512 KB of RAM, and heart-rate-monitor microcontrollers with up to 640 KB of RAM—and asks whether post-quantum primitives fit. The feasibility conclusion is driven by public figures such as Dilithium needing 40–70 KB of RAM and Falcon needing roughly 500 bytes of RAM, not by a proof.","core_discovery":"The chapter's central claim is stated plainly: with the extraordinary computational power of quantum computers, traditional cryptographic algorithms widely used in today's healthcare IoT devices will be vulnerable in the near future. In concrete terms, a quantum attacker could access, read, and change private healthcare information and could take control of critical devices such as pacemakers and insulin pumps. The chapter also argues that the threat is current rather than purely future through the 'harvest now, decrypt later' model, in which encrypted medical data is stolen today and decoded once a capable quantum machine exists. It identifies Shor's algorithm as the breaker of RSA and ECC, Grover's algorithm as the halver of symmetric key strength, and post-quantum primitives such as Kyber, Dilithium, and Falcon as the candidate replacements, while noting that device resource limits will decide whether those replacements actually run.","pith_inferences":["An implication the chapter leaves implicit is that migration is not a single algorithm swap; devices need cryptographic agility so they can replace algorithms as standards settle.","If the quoted memory figures are accurate, the practical bottleneck is hardware: devices with less than 64 KB of RAM may require a hardware refresh rather than a software patch to run PQC.","A testable extension would be to benchmark the candidate key-encapsulation and signature schemes on actual glucose-monitor and inhaler microcontrollers, since the chapter relies on published figures rather than new measurements.","The urgency claim carries a timing assumption: if fault-tolerant quantum machines arrive after the confidentiality window of today's medical data, the near-term threat recedes, though long-lived records would still justify migration."],"forward_implications":["Healthcare IoT vendors should start migration planning now, because encrypted medical data collected today can be harvested and decrypted later.","RSA and ECC keys in current sizes will not survive a cryptographically relevant quantum computer, so public-key operations need post-quantum replacements.","Symmetric cryptography can remain usable by moving to 256-bit keys, but key exchange and digital signatures still need new algorithms.","Some standardized PQC candidates will not fit low-end medical devices; Dilithium's larger RAM footprint may exclude it from CGM-class hardware, while Kyber and Falcon-style schemes may be feasible.","Quantum key distribution offers strong key security but needs dedicated hardware, so it is not a general substitute for PQC in constrained healthcare IoT."],"supporting_citations":[{"why":"Frames healthcare IoT security through the confidentiality, integrity, and availability triad and gives the migration viewpoint the chapter adopts.","marker":"[3]"},{"why":"Surveys quantum-resistant cryptosystems for IoT and supplies the connection between the generic quantum threat and constrained devices.","marker":"[4]"},{"why":"Provides the quantum resource and time-to-break estimates for RSA, ECC, AES, and SHA-256 used in the threat tables.","marker":"[15]"},{"why":"Establishes the background of post-quantum cryptography, defining why classical algorithms fail against quantum attackers.","marker":"[19]"},{"why":"Surveys the standardization process and identifies Kyber and Dilithium as the recommended PQC algorithms.","marker":"[24]"},{"why":"Defines the resource classes of IoT devices and the difficulty of fitting PQC into them.","marker":"[28]"},{"why":"Supplies the concrete code-size and RAM figures for Falcon and Dilithium on Cortex-M4-class devices.","marker":"[29]"},{"why":"Documents RSA, AES, and ECC as the encryption algorithms currently used in healthcare IoT communications.","marker":"[31]"},{"why":"Introduces the harvest-now-decrypt-later attack model that makes the threat current for long-lived medical data.","marker":"[32]"}],"fun_headline_variants":["Quantum attackers will decrypt your medical data","Harvest now, decrypt later: quantum risk to medical IoT","Quantum break lets hackers control pacemakers"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that cryptographically relevant quantum computers will arrive while today's RSA and ECC keys still protect data that must remain confidential, so 'harvest now, decrypt later' is a real threat.","fun_headline_variants_meta":{"raw":{"variants":["Quantum attackers will decrypt your medical data","Harvest now, decrypt later: quantum risk to medical IoT","Quantum break lets hackers control pacemakers"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001454,"raw_usage":{"total_tokens":5804,"prompt_tokens":846,"completion_tokens":4958,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":462,"completion_tokens_details":{"reasoning_tokens":4912}},"tokens_in":462,"tokens_out":4958,"duration_ms":38459,"temperature":1.0,"reasoning_tokens":4912,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T20:12:49.509129+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A concrete check would be comparing credible hardware roadmaps against the roughly 2,050–8,194 logical qubits the chapter cites as needed to break RSA-1024 through RSA-4096; if fault-tolerant machines at that scale are predicted to arrive only after the confidentiality lifetime of current medical data expires, the urgency claim weakens. Another decisive observation would be running Kyber and Dilithium on a representative glucose-monitor microcontroller with 32–64 KB of RAM and finding that they fit, which would overturn the resource-constraint conclusion.","supporting_citations":[{"cited_title":"IEEE Access, 2024","cited_arxiv_id":null,"evidence_quote":"Frames healthcare IoT security through the confidentiality, integrity, and availability triad and gives the migration viewpoint the chapter adopts."},{"cited_title":"IEEE Internet of Things Journal, 2019","cited_arxiv_id":null,"evidence_quote":"Surveys quantum-resistant cryptosystems for IoT and supplies the connection between the generic quantum threat and constrained devices."},{"cited_title":"and Medicine, Quantum Computing: Progress and Prospects , ed","cited_arxiv_id":null,"evidence_quote":"Provides the quantum resource and time-to-break estimates for RSA, ECC, AES, and SHA-256 used in the threat tables."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Establishes the background of post-quantum cryptography, defining why classical algorithms fail against quantum attackers."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Surveys the standardization process and identifies Kyber and Dilithium as the recommended PQC algorithms."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the resource classes of IoT devices and the difficulty of fitting PQC into them."},{"cited_title":"Requirements for Post -Quantum Cryptography on Embedded Devices in the IoT","cited_arxiv_id":null,"evidence_quote":"Supplies the concrete code-size and RAM figures for Falcon and Dilithium on Cortex-M4-class devices."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Documents RSA, AES, and ECC as the encryption algorithms currently used in healthcare IoT communications."},{"cited_title":"and C.J.a.p.a","cited_arxiv_id":null,"evidence_quote":"Introduces the harvest-now-decrypt-later attack model that makes the threat current for long-lived medical data."}],"review_version":1}