{"id":"7354c3f7-84ad-4ce8-a9db-bf62a154448a","arxiv_id":"1909.01785","paper_version":2,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":8.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"Private key formats and optional parameters can route cryptographic libraries into vulnerable code paths, enabling practical side-channel key recovery attacks.","lead":"This paper shows that the file format used to store cryptographic private keys can silently bypass side-channel protections in OpenSSL and mbedTLS. It demonstrates key recovery attacks against ECDSA using only network timing or electromagnetic measurements.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Real-world prevalence of the vulnerable key encodings is asserted, not measured; the central 'significant role in real world SCA security' claim hinges on it.","rationale":"The paper's technical core is strong: Triggerflow traces, code-level root causes, repeated end-to-end key recovery for ECDSA via wall-clock timing and EM, and a published dataset all support the mechanism that key parsing and optional parameters can route execution into SCA-vulnerable code. I considered other candidate concerns: the abstract overstates completed cache-timing key recovery; the zero-cofactor EC key used in the end-to-end attacks may not be strictly standards-compliant; and the mbedTLS 'CRT every time' claim is surprising. None of these undermines the central format-routing thesis as directly as the prevalence issue. The paper's own 'Keys in the wild' sections explicitly raise the question 'does this vulnerability matter?' and answer it with a few named deployments (GOST engine, GOSTCoin, OpenSC, Windows driver signing) without quantitative evidence. The reader's weakest assumption captures exactly this gap. Since the central claim is explicitly about 'real world' significance, and since the authors themselves flag the uncertainty, the conditional verdict is appropriate; a prevalence measurement would either substantiate or narrow the claim. Hence I keep the reader's CONDITIONAL verdict unchanged and agree with the identified weakest assumption.","tokens_in":26439,"tokens_out":18143,"duration_ms":179347,"concrete_test":"Run a corpus-wide scan: collect all PEM/DER private keys from public GitHub repositories, Debian/Ubuntu source trees, and firmware images; parse each with OpenSSL's ASN.1 parser and a PVK/MSBLOB parser, and count EC keys using SpecifiedECDomain with omitted or zero cofactor, DSA PVK/MSBLOB keys, and RSA keys missing d. If the fraction of such keys among all parsed private keys is negligible, the 'significant role in real world SCA security' claim must be downgraded; if non-negligible, the concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim that key format 'plays a significant role in real world SCA security' is load-bearing on the actual deployment prevalence of the triggering encodings. The paper explicitly concedes in Section 3.1 ('Keys in the wild') that the OpenSSL CLI will not organically emit the vulnerable ECDSA key form, and the cited real-world instances are anecdotal: GOST engine, GOSTCoin (whose extracted keys carry an explicit zero cofactor, a semantically invalid value), OpenSC minidriver, and Windows driver signing workflows. No quantitative survey or measurement is provided for any of these. If such keys are rare in practice, the demonstrated ECDSA attacks, while technically sound, affect a small population, and the 'significant role' conclusion overstates real-world impact. The same applies to DSA PVK/MSBLOB triggers (Section 3.2) and to RSA keys missing d in mbedTLS (Section 3.4), where the paper itself notes the CRT-leak path is not format-specific. The vulnerability mechanism is credible; the real-world relevance is the weakest link.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper argues that the format in which private keys are persisted, and in particular the presence or absence of optional parameters in standardized encodings, materially affects side-channel security. Using the Triggerflow execution-path tool, the authors identify four vulnerability classes in widely used libraries: (i) OpenSSL ECDSA with explicit curve parameters and a zero or omitted cofactor reaches the SCA-insecure wNAF scalar multiplication path (Section 3.1); (ii) OpenSSL DSA public-key derivation from PVK and MSBLOB key formats performs variable-time modular exponentiation (Section 3.2); (iii) OpenSSL RSA key validation exercises leaking primality, GCD, and inversion paths (Section 3.3); and (iv) mbedTLS RSA key loading computes missing parameters using leaking GCD and modular inversion routines (Section 3.4). The paper then reports two end-to-end ECDSA key recovery attacks on a time-stamping server using the Section 3.1 trigger: a remote wall-clock timing attack with 91% success over 100 runs, and an electromagnetic attack recovering the key in about three minutes from 172 usable traces. The authors responsibly disclosed the findings, obtained CVE-2019-1547, and contributed patches to OpenSSL and mbedTLS.","tokens_in":26599,"tokens_out":3828,"duration_ms":40383,"significance":"If the central claim is accepted, the paper makes a valuable contribution by moving side-channel analysis from isolated primitives to the key parsing and persistence layer, showing that standards-level optionality can silently switch a library onto an SCA-vulnerable code path. The end-to-end attacks use unmodified OpenSSL 1.1.1 and an unmodified TSA server, and the timing attack operates over a network with a threat model indistinguishable from a normal client, which makes the results concrete. The paper also ships a public dataset for the remote timing attack and integrates the new Triggerflow tests into OpenSSL's CI, which are concrete reproducibility and tooling strengths. The main weakness is that the 'real world' scope of the central claim rests on qualitative, anecdotal evidence about deployment prevalence rather than measurement; the technical vulnerability mechanisms themselves are credible and well supported.","major_comments":[{"comment":"The paper's central claim that key format 'plays a significant role in real world SCA security' depends on the real-world prevalence of the triggering key encodings, but this prevalence is asserted, not measured. The text concedes that the OpenSSL CLI will not organically emit the vulnerable ECDSA key form, and the cited instances (GOST engine, GOSTCoin, OpenSC, Windows driver signing) are anecdotal. No deployment survey, telemetry, or quantitative estimate is provided for any of these cases. If such keys are rare in practice, the demonstrated ECDSA attacks affect a much narrower population than the title and abstract suggest. The authors should either temper the 'real world' conclusion to 'can affect deployments that accept standards-parseable but atypical key encodings' or supply measurable evidence of prevalence.","section":"Section 3.1, 'Keys in the wild'; Section 5"},{"comment":"The section title and the surrounding framing imply that the mbedTLS vulnerability requires missing RSA parameters, but the paper itself states that the CRT-related leakage 'exists regardless of missing parameters in the private key' and that it executes on every private-key load. Only the private-exponent leakage in the 'CRT & d' group is specific to a key missing d. This is a scope-of-claim issue: the universal CRT leak is a separate, arguably more serious finding, and the format-specific contribution should be presented as the additional d-computation path rather than as a single 'bypass via missing parameters' vulnerability.","section":"Section 3.4, 'RSA: Bypass via Missing Parameters'"},{"comment":"The abstract says the authors 'design and implement key recovery attacks utilizing signals ranging from electromagnetic (EM) emanations, to granular microarchitecture cache timings, to coarse traditional wall clock timings.' This implies that full key recovery is achieved with cache-timing signals as well as the other two. In the paper, full end-to-end key recovery is demonstrated for remote wall-clock timing (Section 4.1) and EM (Section 4.2); the microarchitecture cache-timing analysis in Sections 3.2 and 3.3 demonstrates leakage and partial exponent recovery but not completed key recovery for a full signature scheme. The abstract and introduction should be reworded to distinguish leakage analysis from completed key recovery.","section":"Abstract; Section 4"}],"minor_comments":[{"comment":"Calling a key with cofactor explicitly set to zero 'valid from a standards perspective' is too strong: SEC1 allows the cofactor to be optional, but if present it should be the correct positive integer. 'Standards-parseable' or 'accepted by the implementation' would be more accurate and would not weaken the attack.","section":"Section 3.1"},{"comment":"The PVK magic value is stated as '0xb0b5f11e2' with a footnote referring to 'bobsfile'; the standard PVK magic is 0xb0b5f11e. Please correct the value and remove the stray digit.","section":"Section 2.2, PVK key format"},{"comment":"There are several typos and awkward phrasings: 'trasmit' in Section 2.2, 'Impulsed' in Section 2.3, 'lattic errors' in Section 5, and the unexplained 'f_in matrix' label in Figure 2. These should be cleaned up.","section":"Global"},{"comment":"The trace-quality criterion is described as a 'emphatically selected confidence interval' for the peak-to-RMS ratio. Please give the actual threshold or selection procedure, since this step affects the reported 422/500 trace retention rate and the final success rate.","section":"Section 4.2, Signal analysis"}],"recommendation":"major_revision","confidential_remarks":"This is a strong empirical security paper with working end-to-end attacks, responsible disclosure, and a public dataset. The technical core is sound and the ECDSA attacks are convincing. My main concern is scope: the 'real world' framing is load-bearing and is supported only by anecdotal deployment examples. That is fixable in revision either by adding evidence or by softening the claim, so I do not see it as a reject-level flaw. The mbedTLS framing in Section 3.4 also needs a careful scope correction. I would encourage revision rather than acceptance in the current form."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Read this one. It establishes that private key persistence formats can route library execution into SCA-vulnerable code paths, bypassing countermeasures in OpenSSL and mbedTLS. Four concrete vulns, one CVE-2019-1547, patches upstream. The two ECDSA end-to-end attacks are real: remote timing over Ethernet recovers the key in 91% of 100 runs; the EM attack recovers the key in about three minutes. The mechanism is well evidenced with Triggerflow traces and code inspection.\n\nWhat is actually new: the systematic point that mathematically equivalent keys (named vs explicit EC parameters, cofactor present/absent, PKCS#1 with/without optional parameters) are treated differently by libraries, leading to different arithmetic code. The explicit-parameter zero-cofactor bypass of the constant-time nistz256 path is a genuine new attack surface. The DSA PVK/MSBLOB leak (public key computed with non-constant-time exponentiation) and the mbedTLS missing-d computation are also new. The RSA key validation leaks are real, though the general idea that key validation can leak is less novel.\n\nSoft spots, in order of softness. First, the abstract overstates: it says key recovery attacks using \"signals ranging from EM... to cache timings,\" but the cache-timing results are leakage analyses (DSA/RSA), not full key recoveries. That should be corrected. Second, real-world prevalence of the trigger encodings is not measured. The paper's own \"Keys in the wild\" sections cite GOST engine, GOSTCoin, OpenSC, and Windows driver signing, but no numbers. If those encodings are rare, the ECDSA attacks hit a smaller population than the title suggests. This does not undermine the technical results, but it tempers the \"significant role in real world SCA security\" claim. Third, the RSA key validation attack in OpenSSL requires the victim to run `openssl rsa -check` or equivalent; the authors acknowledge that trigger requirement. That is a scope limitation, not a flaw.\n\nNone of these are load-bearing. The central finding—format affects which code path runs, and that matters for SCA—is demonstrated by the code paths themselves, independent of how common the keys are. The data and methodology are reproducible; they publish the timing attack dataset.\n\nWho benefits: anyone doing applied crypto security, library maintainers, and people designing key serialization standards. This deserves a serious referee; I would push the authors to fix the abstract and add an honest prevalence assessment, but it is not a desk reject.\n\nRecommendation: send it to peer review.","headline":"Key serialization formats can silently bypass SCA countermeasures in OpenSSL and mbedTLS—the attacks are real, but the abstract overstates cache-timing key recovery and real-world prevalence is not measured.","tokens_in":27193,"tokens_out":2897,"would_cite":true,"duration_ms":27441,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The format a private key is stored in can silently drop side-channel defenses and reveal the key.","keywords":["side-channel analysis","private key formats","ECDSA","OpenSSL","mbedTLS","wNAF scalar multiplication","lattice attacks","timing attacks"],"falsifier":"Run the paper's 500,000-request timing attack against the same time-stamp server configured with an otherwise identical named-curve P-256 private key: if key recovery still succeeds at the reported rate, the claimed mechanism is wrong, and if it fails, the key format is confirmed as the load-bearing cause.","tokens_in":26216,"feed_emoji":"🔑","tokens_out":10037,"duration_ms":96754,"temperature":0.7,"pith_summary":"The paper sets out to show that the serialized format of a private key is itself a side-channel attack surface: two keys that are mathematically equivalent at the specification level can make a library execute very different arithmetic code, some of it unprotected. It demonstrates this in OpenSSL and mbedTLS with four distinct vulnerabilities, ranging from ECDSA keys carrying explicit curve parameters with a missing or zero cofactor, to DSA keys in PVK/MSBLOB form, to RSA keys whose optional parameters are absent. In the strongest case it recovers the long-term ECDSA private key of a signing server end to end, using only network response timing over Ethernet, and also using electromagnetic emanations. A sympathetic reader should care because the mitigations in individual primitives are bypassed without modifying any code or abusing invalid keys: the keys are standards-compliant and the libraries parse them normally.","feed_headline":"Private key storage format can bypass crypto defenses","feed_subtitle":"Four flaws in two major TLS libraries, plus full ECDSA key recovery from timing alone.","key_machinery":"The load-bearing mechanism is runtime dispatch inside the key parser: the value of an optional ASN.1 field selects between a constant-time scalar-multiplication implementation and an older wNAF implementation. The specific switch is the cofactor in an explicit EC domain parameter block: OpenSSL's scalar-multiplication wrapper only takes the constant-time ladder when both the group order and the cofactor are nonzero, so a zero or omitted cofactor routes P-256 signing into ec_wNAF_mul, whose execution time and cache or EM profile vary with the secret nonce. In the RSA and DSA cases the same dispatch idea operates through key-format code paths that call variable-time bignum routines such as BN_mod_exp, BN_gcd, and BN_mod_inverse, and mbedTLS's binary GCD, without setting the library's constant-time flag.","core_discovery":"The central discovery is that standards themselves, via optional fields in key encodings, determine which arithmetic routine runs on secret data. OpenSSL's ECDSA path normally uses a constant-time, architecture-optimized implementation for named curves, but a valid private key with explicit domain parameters falls to the generic method; if the optional cofactor is zero or omitted, the generic method skips its constant-time ladder and executes a wNAF double-and-add that leaks the nonce. The same pattern repeats elsewhere: PVK and MSBLOB DSA keys force recomputation of the public key with variable-time modular exponentiation; RSA key validation in OpenSSL recomputes secret components with variable-time GCD and inversion; and mbedTLS, when RSA parameters are missing, derives CRT values and the private exponent with the binary extended Euclidean algorithm. The paper completes the chain by turning the ECDSA leak into key recovery: a timing attack that filters short nonces from 500,000 signatures and solves a hidden-number-problem lattice with a 91 percent success rate, and an EM attack that recovers the key from 172 usable traces in about three minutes.","pith_inferences":["Beyond the paper, the same parser-dispatch pattern should be searchable by fuzzing optional fields in other serialization standards; a library that canonicalizes keys to internal named-curve representations at import time would close the entire class rather than patching one routine.","The timing attack's reliance on nonce-bitlength correlation suggests that other signing protocols that expose a network timing oracle, not just time-stamping, are viable candidates if they run on the same vulnerable parsing path.","If standards bodies made cofactor and CRT parameters mandatory, or required import-time validation against canonical values, the specification-level ambiguity this paper exploits would be largely eliminated at the source."],"forward_implications":["A server that signs with a valid explicit-parameter EC key whose cofactor is zero or omitted can be fully key-recovered by a remote client merely measuring response times; the paper's Ethernet experiment succeeded in 91 of 100 attack instances.","Any workflow that loads DSA keys in PVK or MSBLOB form into OpenSSL re-exposes the cache-timing leak in modular exponentiation, since the public key is recomputed from the private key on every load.","Calling OpenSSL's RSA key-checking API on a legitimate RSA key is enough to leak bits of $p$ and $q$; the affected functions include both the direct check and the generic EVP_PKEY_check path, so any OpenSSL-linking application that validates keys inherits the exposure.","mbedTLS key loading is vulnerable even for completely standard, fully populated RSA keys, because the CRT-deduction path runs on every load; the paper groups all 256 possible PKCS#1 parameter combinations into four classes, with 32 of them hitting a leaking code path."],"supporting_citations":[{"why":"Establishes that OpenSSL's wNAF scalar-multiplication routine leaks through cache timing; this is the exact routine the ECDSA vulnerability falls back to.","marker":"[21]"},{"why":"RFC 8017 defines the eight RSA private-key parameters and does not require all of them to be present, the precondition for the mbedTLS missing-parameter attacks.","marker":"[55]"},{"why":"SEC1 defines ECPrivateKey with explicit domain parameters and an optional cofactor, the encoding used to reach the vulnerable ECDSA path.","marker":"[2]"},{"why":"Supplies the execution-path tracking methodology the paper uses to detect which key formats reach security-critical arithmetic operations.","marker":"[40]"},{"why":"Provides the constant-time nistz256 scalar-multiplication implementation that is bypassed when explicit parameters are used.","marker":"[43]"},{"why":"The prior remote timing attack on ECDSA whose nonce-bitlength collection and lattice recovery strategy the timing attack extends.","marker":"[22]"},{"why":"Provides the hidden-number-problem lattice formulation and the variable-time-callee attack background used for key recovery.","marker":"[61]"},{"why":"The original cache-timing attack on variable-time modular exponentiation that the DSA PVK/MSBLOB public-key computation re-exposes.","marker":"[60]"}],"fun_headline_variants":["Private key format flaws enable timing-based ECDSA key recovery","Key storage formats expose crypto secrets via side channels","Standards' optional fields let attackers bypass constant-time code","OpenSSL and mbedTLS key parsing leaks nonces, enabling key theft","Certified side channels: key format determines arithmetic stack leaks"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The practical relevance of the attacks depends on standards-compliant but atypical key encodings appearing in real deployments; the paper itself concedes that OpenSSL's own command-line tool will not organically emit the vulnerable ECDSA key form and instead points to engines, wallets, and conversion workflows.","fun_headline_variants_meta":{"raw":{"variants":["Private key format flaws enable timing-based ECDSA key recovery","Key storage formats expose crypto secrets via side channels","Standards' optional fields let attackers bypass constant-time code","OpenSSL and mbedTLS key parsing leaks nonces, enabling key theft","Certified side channels: key format determines arithmetic stack leaks"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000252,"raw_usage":{"total_tokens":1514,"prompt_tokens":854,"completion_tokens":660,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":470,"completion_tokens_details":{"reasoning_tokens":575}},"tokens_in":470,"tokens_out":660,"duration_ms":6923,"temperature":1.0,"reasoning_tokens":575,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T05:07:24.153686+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the paper's 500,000-request timing attack against the same time-stamp server configured with an otherwise identical named-curve P-256 private key: if key recovery still succeeds at the reported rate, the claimed mechanism is wrong, and if it fails, the key format is confirmed as the load-bearing cause.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Establishes that OpenSSL's wNAF scalar-multiplication routine leaks through cache timing; this is the exact routine the ECDSA vulnerability falls back to."},{"cited_title":"PKCS #1: RSA cryptography specifications version 2.2","cited_arxiv_id":null,"evidence_quote":"RFC 8017 defines the eight RSA private-key parameters and does not require all of them to be present, the precondition for the mbedTLS missing-parameter attacks."},{"cited_title":"Triggerflow: Regression testing by ad- vanced execution path inspection","cited_arxiv_id":null,"evidence_quote":"Supplies the execution-path tracking methodology the paper uses to detect which key formats reach security-critical arithmetic operations."},{"cited_title":"Remote timing attacks are still practical","cited_arxiv_id":null,"evidence_quote":"The prior remote timing attack on ECDSA whose nonce-bitlength collection and lattice recovery strategy the timing attack extends."},{"cited_title":"Constant- time callees with variable-time callers","cited_arxiv_id":null,"evidence_quote":"Provides the hidden-number-problem lattice formulation and the variable-time-callee attack background used for key recovery."},{"cited_title":"Cache missing for fun and profit","cited_arxiv_id":null,"evidence_quote":"The original cache-timing attack on variable-time modular exponentiation that the DSA PVK/MSBLOB public-key computation re-exposes."}],"review_version":1}