{"id":"0fa84e7c-f2b3-4eed-9012-ebb23fc5dd1b","arxiv_id":"2607.28551","paper_version":1,"verdict":"ACCEPT","confidence":"HIGH","novelty_score":2.0,"correctness_risk":"low","formal_verification":"none","parameter_count":0,"one_line_summary":"A survey chapter maps proof-assistant applications across system security, language-based security, secure compilation, and cryptography, without new theorems.","lead":"This handbook chapter surveys how proof assistants have been used to check security properties of systems, languages, compilers, and cryptography. It is a literature map for researchers who need machine-checked security arguments or certification support.","discovery_kind":"review","skeptic_critique":{"model":"grok-4.5","headline":"No significant objection identified","rationale":"The manuscript is explicitly a survey chapter (Abstract, §19.1). Its load-bearing assertion is organizational and historical: that a coherent body of machine-checked work now exists and is mature enough to be surveyed. Because the text does not advance new theorems, the only plausible failure mode would be systematic misrepresentation of the primary literature or an indefensible claim of completeness. Neither appears. Coverage is broad yet properly caveated, major tools and results are cited with correct high-level statements, and the genre conventions of handbook chapters already license reliance on unre-audited primary formalizations. The reader’s ACCEPT / low-correctness-risk assessment is therefore unchanged; the suggested spot-check is ordinary due diligence, not a threat to the verdict.","tokens_in":34925,"tokens_out":373,"duration_ms":8243,"concrete_test":"Spot-check three high-impact citations that anchor major subsections (e.g., seL4 noninterference [165], CompCert constant-time preservation [35], EasyCrypt AWS KMS proof [10]) against the original papers’ stated theorems; confirm the chapter’s one-sentence summaries match the claimed results without material omission or inflation.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The chapter is a handbook survey whose central claim is field maturity and usefulness of mechanized security proofs across systems, languages, compilers, and cryptography. That claim is supported by an extensive, accurately scoped citation map rather than by new theorems. The reader’s weakest assumption (that primary formalizations hold as stated) is inherent to the genre and does not undermine the survey’s internal coherence or its utility as an organizing reference. No hidden technical inconsistency, scope overclaim, or missing counter-example rises to a load-bearing concern.","agreement_with_reader":"agree"},"referee_report":{"model":"grok-4.5","summary":"This handbook chapter surveys the use of proof assistants to validate security properties of designs and implementations, and to support certification. It organizes a large literature under information-flow security (systems-level and language-based), resource usage, access control and capabilities, hyperproperties, secure compilation, and cryptography (computational game-based and constructive frameworks, post-quantum adversaries, symbolic/Dolev–Yao models, the generic group model, and implementation correctness), with shorter treatments of zero-knowledge/e-voting, smart contracts, and differential privacy. The load-bearing claim is descriptive and organizational: mechanized security proofs are mature and routinely applied across these areas (Abstract; §19.1), supported by an extensive citation map rather than new theorems.","tokens_in":34967,"tokens_out":1194,"duration_ms":42524,"significance":"As a handbook survey the contribution is organizational and bibliographic rather than theorematic, but that is appropriate and valuable. The chapter gives a coherent map of multi-community work (seL4 and related OS/hypervisor isolation, language-based IFC, CompCert/Jasmin-style secure compilation, CHERI/capabilities, and the main crypto provers CertiCrypt, EasyCrypt, FCF, CryptHOL, SSProve, Squirrel, plus implementation stacks such as Fiat-Crypto, VST, Jasmin, and HACL*). Machine-checked developments and certification-motivated formalizations are named explicitly. If accurate, the chapter is a useful reference entry point for readers who need orientation across systems, languages, compilers, and cryptography.","major_comments":[{"comment":"§19.5 (Hyperproperties) is markedly thinner than neighboring sections yet is elevated to a top-level topic. It cites only a handful of mechanizations (BiKAT, Hyper Hoare Logic, a separation hyperlogic) and does not connect them back to the noninterference, secure-compilation, and crypto material that dominate the chapter. Either expand with the main hyperproperty/hyperlogic formalization lines and their relation to §19.2 and §19.6, or fold the material into those sections so the TOC weight matches the substance.","section":"§19.5"},{"comment":"§19.3 (Resource usage) is only loosely tied to security for much of its length. Side-channel/constant-resource motivation appears in §19.2.2.6, but §19.3 largely surveys general complexity and cost formalizations (master theorems, time credits, expected runtime). For a chapter titled Formalization of Security, the security-relevant subset should be foregrounded and the purely algorithmic material shortened or explicitly justified as dual-use infrastructure for leakage and crypto reductions.","section":"§19.3"}],"minor_comments":[{"comment":"§19.7.4 ends with a broken sentence: “...proofs of ElGamal encryption. model [117] have found many novel applications...”. Restore the intended reference to the algebraic group model (or similar) and fix grammar.","section":"§19.7.4"},{"comment":"Author-name and diacritic glitches appear in several places (e.g., “V on Oheimb” for von Oheimb; “Hrit,cu” / “Hrit ,cu” for Hriţcu; similar comma artifacts in other names). Sweep names and BibTeX for consistency.","section":"§19.2.1 and passim"},{"comment":"The text mixes “Rocq (formerly known as Coq)” with bare “Rocq” and occasional older “Coq” citations in the narrative. A one-time naming note early on, then consistent use, would help handbook readers.","section":"§19.2.1"},{"comment":"§19.6.1 discusses full abstraction shortcomings and trace-preserving / robust property preservation criteria; a short forward pointer from the information-flow sections to which hyperproperties are actually preserved by the cited compilers would tighten the arc between §19.2, §19.5, and §19.6.","section":"§19.6.1"},{"comment":"§19.8 is a catch-all; differential privacy (§19.8.3) is closer in technique to the relational crypto logics of §19.7.1 and could be cross-referenced there to avoid the appearance of an afterthought.","section":"§19.8.3"},{"comment":"A few citations are used for broad claims without a clause on what was machine-checked versus paper-only (e.g., overview citations in §19.2.1). Where the chapter’s theme is formalization, prefer one precise formal artifact per claim when space allows.","section":"§19.2.1"}],"recommendation":"minor_revision","confidential_remarks":"Genre fit is good for a handbook methods/applications volume; the bar is faithful organization, not novelty. Author is a central contributor to several surveyed lines (CertiCrypt/EasyCrypt, constant-time compilation, etc.); self-citation level looks normal for a senior survey and is balanced by extensive independent work (seL4, CryptHOL, FCF, CHERI, Iris IFC, HACL*, etc.). No integrity concern. The two major comments are balance/scope polish, not soundness failures—accept after a revision pass is realistic."},"author_rebuttal":null,"desk_editor":{"model":"grok-4.5","letter":"This is Chapter 19 of a handbook: Barthe surveying machine-checked security work across information flow, resources, access control/capabilities, hyperproperties, secure compilation, and cryptography. Nothing new is proved. The value is organization and coverage.\n\nWhat it does well is scope and attribution. The chapter cleanly separates systems-level noninterference (seL4, KVM, SAFE, browsers), language-based work, secure compilation criteria and CompCert/Jasmin constant-time preservation, and the main crypto stacks (CertiCrypt/EasyCrypt, FCF, CryptHOL, SSProve, symbolic model, generic group, post-quantum notes, implementation lines like Fiat-Crypto, VST, Jasmin, HACL*). Certification motivation is stated up front and recurs where it actually mattered (Formavie, AAMP7G). Citations are dense and mostly point to the right primary formalizations. For a handbook audience that is the job.\n\nSoft spots are the ones you expect from the genre. Depth is uneven: some subsections are little more than a named result and a citation; hyperproperties and a few crypto tools get thinner treatment than CompCert-adjacent or EasyCrypt material. The chapter reports primary claims rather than re-checking TCBs or proof scripts, which is normal for a survey and not a hidden flaw. Self-citations sit among many independent groups and do not drive the descriptive thesis. No load-bearing technical inconsistency showed up on a full read.\n\nWho it is for: students and practitioners who need a map of where mechanized security has actually landed, and people writing related surveys or grant narratives. Specialists already living in one of these sub-areas will skim. Math and data are not the point; the citation pattern looks solid for the genre.\n\nI would send it to peer review as a handbook chapter without hesitation. Engage with it as a reference, not as a source of new theorems.","headline":"Solid handbook survey that maps a mature field without claiming new theorems; useful reference, not a research advance.","tokens_in":35597,"tokens_out":475,"would_cite":true,"duration_ms":14493,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"grok-4.5","headline":"Proof assistants now routinely check that systems, languages, compilers, and crypto meet their security claims—and those proofs can support certification.","keywords":["proof assistants","information flow","noninterference","secure compilation","cryptography","language-based security","hyperproperties","certification"],"falsifier":"An independent audit that finds a critical gap in a flagship cited development (for example, a broken isolation or constant-time preservation theorem in a major kernel or compiler formalization, or a flawed reduction in a widely cited crypto proof) would undercut the claim that the field is routinely reliable.","tokens_in":35773,"feed_emoji":"🔐","tokens_out":888,"duration_ms":19472,"temperature":0.7,"pith_summary":"This chapter surveys how proof assistants are used to show that software and hardware designs actually enforce the security properties their designers claim. The motivation is twofold: security analyses are easy to get subtly wrong, and machine-checked proofs can feed formal certification regimes such as Common Criteria. The survey organizes a large body of work around information-flow noninterference (for systems and languages), resource bounds, access control and capabilities, hyperproperties, secure compilation, and both computational and symbolic cryptography. A sympathetic reader cares because the chapter argues that these applications have matured into a coherent, usable practice rather than isolated case studies: isolation kernels, constant-time compilers, and reductionist crypto proofs are already being machine-checked end to end.","feed_headline":"Proof assistants now check real security claims end to end","feed_subtitle":"A survey shows machine-checked isolation, constant-time compilation, and crypto proofs are routine practice","key_machinery":"Unwinding lemmas for noninterference (step-consistency and step-preservation relative to an attacker equivalence on states), together with the parallel machinery of relational program logics (e.g., probabilistic relational Hoare logic) and secure-compilation criteria (full abstraction, hyperproperty preservation, compartmentalizing compilation). These are the devices that turn security goals into checkable proof obligations inside assistants.","core_discovery":"The chapter’s central claim is that proof assistants are productively and routinely applied to validate security properties of systems, languages, compilers, and cryptographic constructions, and that the resulting mechanized proofs also support certification. It treats the surveyed formal developments—from unwinding-based noninterference through secure compilation criteria to game-based and constructive crypto proofs—as a mature, coherent field rather than scattered experiments.","pith_inferences":["The survey’s breadth implies that the bottleneck is shifting from ‘can we formalize this at all?’ to engineering reusable libraries, smaller trusted bases, and proof automation that non-experts can apply.","Cross-linking the crypto, compilation, and systems strands (already visible in constant-time-preserving compilers and assembly-level crypto) points toward end-to-end stacks where a single assistant carries security from high-level spec to machine code.","Certification regimes that still accept paper proofs may eventually require or strongly prefer the kinds of mechanized artifacts catalogued here, changing how vendors prepare evidence."],"forward_implications":["Security evaluations at high assurance levels can treat mechanized proofs of isolation, noninterference, and crypto reductions as primary evidence rather than informal arguments.","Compilers can be required to preserve side-channel and resource policies (constant-time, stack bounds) with machine-checked guarantees from source to assembly.","Cryptographic designs can be accompanied by checkable reductionist or constructive proofs before standardization or deployment.","Language-based enforcement (type systems, dynamic monitors, capability logics) can ship with machine-checked soundness relative to a formal semantics.","Hyperproperty and relational logics become standard tools for stating and verifying multi-trace security goals inside proof assistants."],"fun_headline_variants":["Proof assistants routinely validate system and crypto security properties","Mechanized proofs now cover isolation, secure compilation, and cryptography","Survey treats machine-checked security proofs as a mature coherent field","Proof assistants support certification of languages, systems, and crypto","From noninterference to game-based crypto: formal security is routine"],"cache_read_input_tokens":32896,"weakest_assumption_plain":"The chapter takes the theorems claimed in the cited machine-checked developments as established; if those primary proofs or their trusted bases fail, the survey’s picture of a mature field collapses.","fun_headline_variants_meta":{"raw":{"variants":["Proof assistants routinely validate system and crypto security properties","Mechanized proofs now cover isolation, secure compilation, and cryptography","Survey treats machine-checked security proofs as a mature coherent field","Proof assistants support certification of languages, systems, and crypto","From noninterference to game-based crypto: formal security is routine"]},"model":"grok-4.5","effort":"low","cost_usd":0.001919,"raw_usage":{"total_tokens":769,"prompt_tokens":565,"num_sources_used":0,"completion_tokens":85,"cost_in_usd_ticks":19188000,"prompt_tokens_details":{"text_tokens":565,"audio_tokens":0,"image_tokens":0,"cached_tokens":256},"completion_tokens_details":{"audio_tokens":0,"reasoning_tokens":119,"accepted_prediction_tokens":0,"rejected_prediction_tokens":0}},"tokens_in":565,"tokens_out":85,"duration_ms":3808,"temperature":1.0,"reasoning_tokens":119,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-07-31T03:56:31.881709+00:00","model_set":{"reader":"grok-4.5"},"falsifier":"An independent audit that finds a critical gap in a flagship cited development (for example, a broken isolation or constant-time preservation theorem in a major kernel or compiler formalization, or a flawed reduction in a widely cited crypto proof) would undercut the claim that the field is routinely reliable.","supporting_citations":[],"review_version":1}