{"id":"3cf8e554-69ee-4bcf-bae6-4884fb91be02","arxiv_id":"1908.04193","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"A discrete-log method recovers ZMap's internal multiplicative state from 20 observed probes and identifies 28.5% of IP-ID-labeled ZMap scans with at least 20 packets on telescope and backbone traffic.","lead":"ZMap scans can be fingerprinted from as few as 20 observed IP addresses by recovering the secret multiplier ZMap uses to walk the IPv4 address space. This lets defenders recognize ZMap probes, predict which addresses will be hit next, and characterize scan speed, scope, and sharding.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The real-world 28.5% result depends on precomputed offsets from a 2019-archived ZMap blacklist being valid for 2014–2017 scans; the paper never verifies this version match.","rationale":"I read the paper's central contribution as the Det2 generator-recovery method, with the 28.5% real-world rate as the headline empirical validation. The mathematical core (Theorems 1–3) is coherent under its stated idealizations: a single-threaded scan, a known offset, and enough packets. The synthetic evaluation is clean and the runtime model matches. The weakest point is not the discrete log machinery; it is the bridge from idealization to real traffic, specifically the precomputed offsets. Theorem 1's affine relation is only useful if the offset fed into Det2 is the true one. The paper uses one archived blacklist snapshot for all historical data without demonstrating that ZMap's default blacklist was static over 2014–2017. The reader identified exactly this assumption; I agree. A second theoretical gap, the independence/equidistribution assumption behind Theorem 3's false-positive bound, is real but less load-bearing: even if the bound is off by orders of magnitude, the empirically observed false-positive count (3 non-ZMap-IPID scans) is small, and the offset problem can invalidate the entire positive detections. I therefore keep the CONDITIONAL verdict: the method is promising and internally consistent, but the real-world headline needs the historical blacklist check before it can be accepted as measured.","tokens_in":20572,"tokens_out":16866,"duration_ms":183362,"concrete_test":"Use Internet Archive snapshots of the ZMap Blacklisting wiki page (reference [7]) from the collection periods (e.g., 2014-06, 2015-01, and 2017-04) in addition to the 2019-01 archive; reconstruct the default blacklist at each date, recompute offset^{BZMap}_k for the telescope /22 and backbone /16 observation prefixes, and rerun Det2 on the same scan set. If Table 3's identification counts or the BZMap-versus-/0 attribution change by more than a few percent, the 28.5% claim is not supported.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Det2 only works if h_j - offset equals the internal state s_{i_j}. Section 4.4 computes offset^{BZMap}_k from the 2019-archived default blacklist [7], and Section 5.2.1 applies those offsets to telescope traffic from June 2014–January 2015 and backbone traffic from April 2017. The default blacklist is not versioned in the paper; [16] documents that it grew by thousands of /24 exclusions (5.4 million addresses, 21,094 /24 subnets) through 2014 and continued to change afterward. An offset is the difference between the observation prefix's host-byte value and the number of non-blacklisted addresses preceding it, so any blacklist change before that prefix changes the offset. With a wrong constant offset Δ, f_j = log((s_j+Δ)/(s_1+Δ)) is not a multiple of the state gap δ_j, so the increasing-sequence test in Theorem 3 fails or, if it accidentally passes, attributes a wrong generator. Hence every BZMap identification in Table 3 and the 28.5% headline are conditioned on an unverified historical blacklist match. This is a validation gap in the empirical claim, not an internal inconsistency of the cryptanalytic construction.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes two methods to identify ZMap scans from short sequences of observed IPv4 addresses by recovering the generator g of ZMap's modular iterator. Det1 applies when the observation network contains the whole scanned set and uses three consecutive observed addresses; Det2 applies to Internet-wide scans and uses discrete logarithms combined with a precomputed offset. The authors prove (or sketch) four theorems, validate Det2 on synthetic ZMap output, and apply it to network telescope data (June 2014–January 2015) and MAWI backbone data (April 2017), reporting identification of 28.5% of ZMap-fingerprinted scans with at least 20 packets (11,302 of 39,750 in Table 3). They also characterize targeted prefixes, packet rates, visibility, progress, and generator reuse.","tokens_in":20824,"tokens_out":7334,"duration_ms":71383,"significance":"The core idea is novel and potentially valuable: unlike prior IP-ID-based detection, Det2 works from the address sequence alone and can recover the internal generator state, enabling scan prediction and characterization. Theorem 1, which shows that, under a subnet-containment condition, ZMap's mapping function reduces to an affine offset on the observed subnet, is clean and useful. The synthetic evaluation is thorough and shows perfect detection in the single-threaded, correct-offset case. If the real-world results survive scrutiny, the characterization results (e.g., blacklist usage, sharding, packet-rate estimates) would be a useful addition to the scanning literature. However, the central empirical claim rests on an unverified historical blacklist match and a heuristic false-positive bound, so the significance is conditional on those points being resolved.","major_comments":[{"comment":"The abstract's claim \"we manage to identify 28.5% of the ZMap scans in real-world traffic\" is unqualified. The 28.5% figure is 11,302 of 39,750 scans that (i) have at least 20 observed packets and (ii) carry the ZMap IP-ID fingerprint (Table 3). Scans with fewer than 20 packets, which the paper itself excludes from Det2, are not in the denominator. The claim should be restated as \"28.5% of ZMap-fingerprinted scans with at least 20 observed packets,\" or the paper should report a properly qualified detection rate over all candidate scans. As written, the headline overstates the method's reach.","section":"Abstract; Section 5.2.3, Table 3"},{"comment":"The offset values fed to Det2 are precomputed from the default ZMap blacklist archived in 2019 (reference [7]), yet they are applied to telescope data from June 2014 to January 2015 and backbone data from April 2017. The default blacklist is not versioned in the paper, and the related work section (and reference [16]) documents that the blacklist grew substantially over time (thousands of /24 exclusions, 5.4 million addresses). Because the offset is the difference between the observed prefix's host-byte position and the number of non-blacklisted addresses before it, any blacklist change before the observed subnet changes the offset. If the offset is wrong, the affine relation f(x)=x+offset collapses and the discrete-log search in Det2 cannot recover the generator. The paper never verifies that the 2019-archived blacklist matches the blacklists actually in force for these historical scans, nor does it test sensitivity to blacklist variations. This is load-bearing: every identification in Table 3 and the BZMap versus /0 attribution depends on this match. The authors should validate the offsets against scans from the same periods with known blacklists, or use date-appropriate blacklist snapshots, or at least quantify how much the offset changes with plausible blacklist differences.","section":"Section 4.4, Section 5.2.1, Section 5.2.3"},{"comment":"The false-positive bound of Theorem 3 rests on two unproven assumptions: (i) that for any k, the sequence (e_j) defined by e_j = log((h_j-offset)/(h_1-offset)) * k^{-1} mod (p-1) is equidistributed, and (ii) that the events that the sequence is not increasing are independent across different k. These assumptions are not established; for fixed observed values, the events for different k are deterministic functions of the same set of discrete logs and are generally correlated. The independence assumption in particular is used multiplicatively to obtain theta(20, p_4) = 9.3e-9, which the paper cites to justify m=20 and to argue that false positives are negligible across hundreds of thousands of tested scans. As written, this is a heuristic, not a proof. The authors should either provide a rigorous proof of the bound or validate the false-positive rate empirically on non-ZMap traffic (e.g., random address sequences and traffic from other scanners).","section":"Section 4.3, Theorem 3"},{"comment":"The statement \"when the offset value is known, the false negative rate is equal to 0\" is unqualified and is contradicted by the paper's own experiments: Section 5.1.2 and Figure 3 show success rates below 100% for T=4 and T=10 threads even with known offsets, and Section 5.2.5 demonstrates that packet reordering can defeat detection. The zero false-negative claim holds only for a single-threaded scanner with no packet reordering. It should be reworded to specify these conditions, or the paper should acknowledge that arrival-order perturbations introduce nonzero false negatives.","section":"Section 4.3, paragraph after Algorithm 5"}],"minor_comments":[{"comment":"The probability that a /16 observation network satisfies the no-blacklisted-address hypothesis is given as 72% in Section 4.1 and as 77% in Section 6. These numbers are inconsistent and should be reconciled.","section":"Section 4.1 and Section 6"},{"comment":"The manuscript contains several typographical errors and misspellings, including \"exteremely\" and \"phenomenom\" (Section 2), \"probality\" (Theorem 3 proof), and \"paralellized\" (Section 5.2.4). A careful proofreading pass is needed.","section":"Throughout"},{"comment":"The text says red curves show scans only identified with the sampled sequence and black curves show scans identified with or without sampling, but the figure caption describes \"Black (resp. red) curves\" in the opposite order. Please make the color convention consistent between the caption and the text.","section":"Section 5.2.9, Figure 7"},{"comment":"The offset brute-forcing method assumes ZMap supports the radix table, but the paper does not state clearly which ZMap versions this covers. Since the datasets are from 2014-2017 and the radix table was introduced in v1.1.0 (November 2013), the assumption is likely satisfied, but it should be stated explicitly.","section":"Section 4.5"},{"comment":"The three backbone scans without the ZMap IP-ID fingerprint that are identified as BZMap are interesting but could be false positives from the heuristic bound in Theorem 3. A brief discussion of why these are not attributed to the heuristic's failure would strengthen the paper.","section":"Section 5.2.3, Table 3"}],"recommendation":"major_revision","confidential_remarks":"The paper has a genuinely interesting core idea, but the abstract overclaims the real-world detection rate, and the 28.5% headline depends on an unverified historical blacklist match that is load-bearing for all of Table 3. The Theorem 3 false-positive bound is also heuristic and should not be presented as a proven bound. These issues are fixable with additional validation or careful rewording, so I recommend major revision rather than rejection. If the authors cannot access historical blacklist snapshots, they should at least quantify the offset sensitivity and report the detection result as conditional on blacklist assumptions."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Here's my take on Mazel and Strullu's ZMap cryptanalysis paper. The technique is genuinely new: recovering ZMap's LCG generator and offset from a short sequence of observed addresses via discrete logarithms, with a neat affine mapping result (Theorem 1) over a contained subnet. That's a real step beyond Doerr et al.'s GPU brute force and the IP-ID heuristics of prior work. The synthetic evaluation is clean, and the real-world characterization (targeted prefix, progress, visibility, packet rate, generator reuse) is useful, even if some parts are openly exploratory.\n\nThe soft spots are real but addressable. Theorem 3's false-positive bound rests on an unstated independence and equidistribution assumption about discrete logs; the bound looks fine for m=20, but it isn't a proven theorem. The bigger issue is blacklist versioning. Section 4.4 precomputes offsets from the 2019-archived default blacklist and applies them to telescope data from 2014–2015 and backbone data from April 2017. The paper never checks that the blacklist version matches those periods, and [16] documents that the default list grew by thousands of /24 exclusions. A wrong offset shifts the discrete-log ratios, so detection fails or, worse, attributes a spurious generator. That makes the 28.5% headline and the BZMap-vs-/0 attribution in Table 3 conditional on an unverified historical match. The abstract also drops the qualifiers the body states (at least 20 packets, IP-ID labeled, default or empty blacklist).\n\nNone of this kills the method. Theorems 1 and 2 hold on their own; the synthetic results show the machinery works when the offset premise holds. The real-world numbers stay credible as estimates of what is detectable under those assumptions. I'd want the authors to re-run with a version-matched blacklist or state clearly that the results are contingent, and I'd want the false-positive bound labeled as an assumption rather than a proven guarantee.\n\nWho's this for? Security analysts and network measurement researchers working on scan detection and attribution. I'd cite it, and I'd send it to a serious referee. The contribution deserves space in a good security venue, provided the empirical claim gets cleaned up.","headline":"Genuinely new cryptanalytic detector for ZMap scans, but the headline real-world result depends on an unverified historical blacklist match and the abstract overstates the unqualified success rate.","tokens_in":21382,"tokens_out":1890,"would_cite":true,"duration_ms":18695,"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":"A handful of observed probe addresses reveals the multiplicative generator driving a ZMap scan, allowing identification and characterization even when the scanner masks its IP-ID fingerprint.","keywords":["ZMap detection","Internet-wide scanning","cryptanalysis","discrete logarithm","scan characterization","network telescope","backbone traffic","generator recovery"],"falsifier":"Generate a ZMap scan with a known seed and a custom blacklist over a /24 observation network, record the 20 addresses, and run Det2 with the true offset: it should recover exactly the generator $g$ that ZMap derives from the seed. Then run it with the paper's 2019-archived default-blacklist offsets; if that blacklist version contains an address inside the observed subnet, the affine relation fails and Det2 should return 'not a ZMap scan' or a wrong $g$. Repeating this across the historical datasets with operator-known blacklist versions would settle whether the reported 28.5% is a method limit or an artifact of mismatched offsets.","tokens_in":1875,"feed_emoji":"🔍","tokens_out":2320,"duration_ms":104382,"temperature":0.7,"pith_summary":"This paper tries to establish that a ZMap scan can be identified and dissected from very few observed destination addresses, by treating the scanner's address order as a cryptographic sequence and inverting it. The authors show that whenever the observer's subnet lies wholly inside the scanned set, ZMap's mapping reduces to adding a fixed offset, so the observed addresses reveal the multiplicative generator $g$ that drives the scan. That lets Det2 recover $g$ from 20 packets (or Det1 from three consecutive packets) without relying on ZMap's well-known IP ID value of 54321. On network telescope and backbone traffic from 2014–2017 the method identifies 11,302 of 39,750 scans that carry ZMap's IP ID, and even catches three scans that masked it. If the method holds, operators gain a practical way to predict upcoming probes, identify targeted prefixes, and characterize probing speed and coordination.","feed_headline":"Twenty packets unmask a ZMap scan's generator","feed_subtitle":"Even without the IP-ID fingerprint, recovered addresses show target, speed and progress; 28.5% of scans identified.","key_machinery":"The load-bearing object is ZMap's multiplicative iterator in the finite field $\\mathbb{F}_p$: a random primitive root $g$ and a starting state $s_0$ generate each scanned state via $s_i = g\\,s_{i-1} \\bmod p$, and the actual probe address is $f(s_i)$. The argument lives in Theorem 1's affine collapse: if the observed subnet $O$ lies inside a scanned subnet $I\\subseteq S$, then for every observed address $f(x) = x + \\mathrm{offset}$ (after host-byte conversion), whether ZMap uses its radix table or its tree mapping. That collapse converts address observations into linear equations in the state sequence, so the generator $g$ can be solved from three consecutive addresses (Det1) or found by a discrete-log search over coprime multipliers (Det2). The machinery is completed by baby-step giant-step or Pohlig–Hellman algorithms to compute logarithms in $\\mathbb{F}_p$ with $p\\le 2^{32}+15$.","core_discovery":"The central discovery is that ZMap's IPv4 iteration is cryptanalytic: each probed address is the output of a deterministic permutation over the finite field $\\mathbb{F}_p$ whose internal state advances by $s_i = g\\cdot s_{i-1} \\bmod p$, and under the paper's observation-network hypothesis the mapping collapses to $f(x) = x + \\mathrm{offset}$. Theorems 1–3 turn this into an identification procedure: three consecutive packets yield $g$ by $g = (h_3-h_1)/(h_2-h_1) - 1 \\bmod p$ (Det1), and for Internet-wide scans, 20 packets yield $g$ by testing values $k$ coprime with $p-1$ for monotonicity of the discrete-log-derived sequence $e_j = \\log_a\\!\\left((h_j-\\mathrm{offset})/(h_1-\\mathrm{offset})\\right) \\cdot k^{-1} \\bmod (p-1)$ (Det2). With the correct offset Det2 has false-negative rate 0; with $m=20$ the false-positive bound is $9.3\\times10^{-9}$. The same recovered generator lets the authors reorder observed packets into scan order and measure progress, visibility, packet rate, targeted prefix, blacklist use (default vs none), and sharding or generator reuse. In real traffic, 28.5% of IP-ID-tagged ZMap scans are identified: 11,302 of 39,750, mostly with the default blacklist.","pith_inferences":["Because the method's only requirement is a few destination addresses in arrival order, the same inversion template could be applied to any scanner whose iteration is an affine-masked multiplicative generator; the paper studies ZMap, but the cryptanalytic idea is transportable to similar deterministic permutations.","The reported 28.5% identification rate is a lower bound under the paper's strongest assumption; if blacklist offsets reconstructed for the actual 2014–2017 time periods were used, the identified share should rise, and scans currently attributed to custom blacklists could be re-tested.","A live deployment could turn the recovered generator into early warning: predict which addresses in the observed prefix will be probed next and raise alerts per scanner, since the paper provides the state-index machinery but does not design the alerting system.","If multiple vantage points each recover the same generator and offset, the gap between expected and observed probes at each site localizes packet loss, offering a possible network health probe; the paper only notes this possibility in discussion."],"forward_implications":["A network operator who sees 20 packets from a single source can decide whether the source is running ZMap and, if so, recover the generator and offset, which identifies the scan even when the IP ID is not 54321.","With $g$ known, addresses that the scanner will probe next inside the observed subnet can be computed in advance, enabling proactive blocking rather than post-hoc detection.","The method attributes a targeted prefix to each identified scan from the precomputed offsets, letting administrators separate indiscriminate /0 probing from scans aimed at their network.","Recovered generators expose coordination: identical $g$ across source IPs indicates sharding or shared seeds, and the paper reports groups of 2–39 IPs sharing a generator, mostly within the same /24.","The characterization metrics (progress, visibility, emitted packet rate) reveal operational choices, including scanning above upstream capacity and probing private or reserved addresses with a blacklist-less sweep."],"supporting_citations":[{"why":"Defines the ZMap tool and its address-generation design that the paper inverts.","marker":"[17]"},{"why":"Documents the original sharding scheme whose state-update formulas are recovered by the detection methods.","marker":"[9]"},{"why":"Introduces the newer pizza-like sharding variant and the September 2017 date that bounds the datasets used.","marker":"[5]"},{"why":"Supplies the default ZMap blacklist used to precompute the offsets on which Det2 depends.","marker":"[7]"},{"why":"Documents exclusion requests and telescope observations of ZMap scans, grounding the observation-network hypothesis and the dataset construction.","marker":"[16]"},{"why":"Threshold Random Walk scan detection is used to extract candidate scanning source IPs from real traffic.","marker":"[24]"},{"why":"Baby-step giant-step discrete logarithm computation is one of the two algorithms that make Det2 feasible over $\\mathbb{F}_p$.","marker":"[35]"},{"why":"Pohlig–Hellman discrete logarithm computation is the other algorithm used to keep Det2's cost near $2^{10}$ operations.","marker":"[33]"},{"why":"Equidistribution of discrete logarithms underpins the false-positive probability bound in Theorem 3.","marker":"[20]"}],"fun_headline_variants":["Cryptanalysis of ZMap's permutation flags scans","Three packets recover ZMap's scan generator","ZMap's IPv4 walk is a cryptanalytic giveaway","Few packets reveal ZMap's probe pattern","20 packets enough to fingerprint a ZMap scan"],"cache_read_input_tokens":23424,"weakest_assumption_plain":"The central claim collapses if the affine relation $f(x)=x+\\mathrm{offset}$ used by Det2 is wrong for a scan, which happens whenever the observation network contains a blacklisted address or the archived default blacklist does not match the scan's actual blacklist.","fun_headline_variants_meta":{"raw":{"variants":["Cryptanalysis of ZMap's permutation flags scans","Three packets recover ZMap's scan generator","ZMap's IPv4 walk is a cryptanalytic giveaway","Few packets reveal ZMap's probe pattern","20 packets enough to fingerprint a ZMap scan"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000757,"raw_usage":{"total_tokens":3384,"prompt_tokens":981,"completion_tokens":2403,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":597,"completion_tokens_details":{"reasoning_tokens":2332}},"tokens_in":597,"tokens_out":2403,"duration_ms":20325,"temperature":1.0,"reasoning_tokens":2332,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T13:51:09.453129+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Generate a ZMap scan with a known seed and a custom blacklist over a /24 observation network, record the 20 addresses, and run Det2 with the true offset: it should recover exactly the generator $g$ that ZMap derives from the seed. Then run it with the paper's 2019-archived default-blacklist offsets; if that blacklist version contains an address inside the observed subnet, the affine relation fails and Det2 should return 'not a ZMap scan' or a wrong $g$. Repeating this across the historical datasets with operator-known blacklist versions would settle whether the reported 28.5% is a method limit or an artifact of mismatched offsets.","supporting_citations":[{"cited_title":"Zmap: Fast internet-wide scanning and its security ap- plications","cited_arxiv_id":null,"evidence_quote":"Defines the ZMap tool and its address-generation design that the paper inverts."},{"cited_title":"Zippier zmap: Internet-wide scan- ning at 10 gbps","cited_arxiv_id":null,"evidence_quote":"Documents the original sharding scheme whose state-update formulas are recovered by the detection methods."},{"cited_title":"https: //web.archive.org/web/20190122170448/ https://github.com/zmap/zmap/commit/ 0bb01d879ebef2c28f038dd032745c72ad5789e9","cited_arxiv_id":null,"evidence_quote":"Introduces the newer pizza-like sharding variant and the September 2017 date that bounds the datasets used."},{"cited_title":"Alex Halder- man","cited_arxiv_id":null,"evidence_quote":"Documents exclusion requests and telescope observations of ZMap scans, grounding the observation-network hypothesis and the dataset construction."},{"cited_title":"Paxson, AW","cited_arxiv_id":null,"evidence_quote":"Threshold Random Walk scan detection is used to extract candidate scanning source IPs from real traffic."},{"cited_title":"Class number, a theory of factorization and genera","cited_arxiv_id":null,"evidence_quote":"Baby-step giant-step discrete logarithm computation is one of the two algorithms that make Det2 feasible over $\\mathbb{F}_p$."},{"cited_title":"An improved al- gorithm for computing logarithms over gf (p) and its cryptographic significance (corresp.)","cited_arxiv_id":null,"evidence_quote":"Pohlig–Hellman discrete logarithm computation is the other algorithm used to keep Det2's cost near $2^{10}$ operations."},{"cited_title":"Discrete logarithms and their equidis- tribution","cited_arxiv_id":null,"evidence_quote":"Equidistribution of discrete logarithms underpins the false-positive probability bound in Theorem 3."}],"review_version":1}