{"id":"834207e4-5410-4e75-b584-ac9fb13c6cde","arxiv_id":"2411.14394","paper_version":2,"verdict":"REJECT","confidence":"HIGH","novelty_score":4.0,"correctness_risk":"high","formal_verification":"none","parameter_count":0,"one_line_summary":"ACRIC claims to authenticate legacy industrial messages by encrypting a CRC computed with a secret vector, but the CRC's linear structure lets an attacker forge valid tags without knowing any secret.","lead":"This paper proposes ACRIC, a scheme that repurposes the CRC field in legacy industrial protocols as an authentication tag using a secret initialization vector and one-time-pad encryption. The authors claim this secures legacy networks without changing message formats or adding hardware, but the scheme is forgeable by a simple bit-flip attack that the paper's own equations reveal.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Section 6.1's dismissal of affine forgery is wrong: a public CRC difference term lets an attacker flip bits in any intercepted frame without knowing InitVec or the OTP key.","rationale":"The paper's stated goal is authentication and integrity with no format changes. The load-bearing premise is that a secret InitVec plus OTP-encrypted CRC prevents forgery. The paper itself considers the linearity attack in Section 6.1 but rejects it on the grounds that InitVec is unknown. That reasoning is wrong: CRC is affine in the message, and the message-difference term is independent of InitVec and publicly computable. The OTP key cancels in the XOR, so secrecy of h does not help. This is not a disagreement with cryptographic convention; it is an internal algebraic error visible in the paper's own equations. Because a single observed tuple permits substituting an arbitrary same-length bit-flipped message with a valid tag, the central authentication/integrity claim is unsupported. The performance and coexistence measurements may be sound, but they do not rescue the security claim. I agree with the reader's weakest_assumption and the REJECT verdict.","tokens_in":14700,"tokens_out":7250,"duration_ms":73014,"concrete_test":"Using one of the crcmod CRC functions evaluated in Section 6.1 (e.g., CRC-16/MODBUS), pick random secret InitVec I and hash h. Compute C = F(I, M) XOR h for a test message M. For a chosen bit flip X, compute P(X) = F(0, X) XOR O, where O is the publicly known final-XOR constant (O = 0 if the implementation has none), and set C' = C XOR P(X). Verify whether C' equals F(I, M XOR X) XOR h. Repeat for all 41 CRC functions from the paper. If the equality holds, the Section 6.1 forgery is confirmed and ACRIC's integrity guarantee fails.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 6.1's 'Beyond collisions' paragraph dismisses the linearity attack because the attacker 'still needs to first learn the InitVec used.' That dismissal is false. For any standard CRC, the function is affine in the message for every fixed initialization vector: F(I, M XOR X) = F(I, M) XOR P(X), where P(X) is independent of I and can be computed from public parameters as P(X) = F(0, X) XOR O, with O the (public) final-XOR constant. Hence, from one intercepted tuple (M, ACRIC_i = F(I, M) XOR h_i), an attacker can replace M by M' = M XOR X and set ACRIC_i' = ACRIC_i XOR P(X). The unknown h_i cancels, and the receiver's verification F(I, M') XOR h_i = ACRIC_i' passes. The paper's experimental observation that nonzero InitVec 'loses linearity' only shows F(I, M1) XOR F(I, M2) != F(I, M1 XOR M2); the affine offset is still present and usable. Injectivity in the InitVec is irrelevant to this deterministic forgery. This directly contradicts the claimed authentication and integrity guarantees.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes ACRIC, a retrofit message authentication mechanism for legacy industrial protocols. ACRIC is defined in Eq. (1) as ACRIC_i = F_CRC(InitVec, M_i) XOR h_i, where InitVec is a secret CRC initialization vector and h_i is a single-use value from a hash chain. The authors claim that this construction provides message authentication, integrity protection, and replay resistance without modifying frame formats or requiring additional hardware, and they report an average computational overhead of about 4 microseconds on commercial Modbus devices. The paper contains a probabilistic security analysis based on InitVec-injectivity and CRC collision probabilities, an experimental evaluation on CAREL hardware, and a discussion of key and hash-chain management.","tokens_in":14921,"tokens_out":8527,"duration_ms":83226,"significance":"If the central security claim were sound, ACRIC would be a practically valuable contribution: it targets a genuine deployment problem, preserves frame formats, requires no hardware changes, supports coexistence with non-secured devices, and ships reproducible experimental code. The interoperability test with mixed secured and unsecured Modbus devices and the low reported overhead are genuine strengths. However, the central security claim is invalid: the proposed tag is an affine function of the message for any fixed initialization vector, so an attacker who observes one valid message/tag pair can forge a valid tag for any bit-flipped message using only public CRC parameters. The reported performance and backward compatibility cannot compensate for the absence of the claimed authentication and integrity guarantees.","major_comments":[{"comment":"The 'Beyond collisions' paragraph dismisses the linearity attack by claiming that a nonzero secret InitVec makes CRC lose linearity and that the attacker 'still needs to first learn the InitVec used.' This is incorrect. For any standard CRC, F_CRC(I, M) is an affine function of M for every fixed initialization vector I: F_CRC(I, M XOR X) = F_CRC(I, M) XOR D(X), where D(X) is a public difference term computable from the CRC parameters alone (specifically D(X) = F_CRC(0, X) XOR O, with O the public final-XOR constant) and is independent of I. Given one intercepted tuple (M, ACRIC_i = F_CRC(I, M) XOR h_i), an attacker can choose any bit-flip pattern X, set M' = M XOR X, and compute ACRIC'_i = ACRIC_i XOR D(X). The receiver then verifies F_CRC(I, M') XOR h_i = ACRIC'_i, so the forgery succeeds. The unknown hash value h_i cancels, and neither the InitVec nor the hash chain is needed. This deterministic forgery defeats the claimed authentication and integrity guarantees under the Dolev-Yao threat model stated in Section 4.2. The experimental observation that F(I, M1) XOR F(I, M2) differs from F(I, M1 XOR M2) is irrelevant: the affine offset is still present and usable, and injectivity of F in the InitVec does not prevent the attack.","section":"Section 6.1, Eq. (1)"},{"comment":"The replay-resistance claim in Section 6.1 assumes that the OTP hash value changes with every message, but Section 5.3 explicitly recommends that reusing the same hash value for retransmissions 'generally poses minimal risk.' Under that recommended configuration, an attacker who captures a valid (M, ACRIC) tuple and replays it during the retransmission window produces exactly what a legitimate retransmission looks like, so the receiver will accept it. The claimed 'zero probability' of replay success is therefore only valid under a stricter per-message hash-consumption policy that the paper itself presents as optional. The paper should either remove the replay-protection claim for the hash-reuse mode or explain how the receiver distinguishes a malicious replay from a legitimate retransmission.","section":"Section 5.3 vs Section 6.1"}],"minor_comments":[{"comment":"The text contains a typo: 'safety-critial' should be 'safety-critical.'","section":"Section 1"},{"comment":"The sentence 'A matching CRC thus confirms the authenticity and integrity of the message' should refer to a matching ACRIC value, since the plain CRC is not secret and the authentication relies on the OTP-encrypted value.","section":"Section 5.2"},{"comment":"The phrase 'This allows to effectively balance' is ungrammatical; it should be 'This allows one to effectively balance' or 'This effectively balances.'","section":"Section 5.3"},{"comment":"The table contains a typo: 'Synchornization' should be 'Synchronization.'","section":"Table 1"},{"comment":"Reference [10] has a typo: 'Cybsersecurity' should be 'Cybersecurity.'","section":"References"},{"comment":"The figure caption or inline text uses lowercase 'acric' in one place; it should be 'ACRIC' for consistency.","section":"Figure 2"},{"comment":"Equation (6) is introduced as a 'collision probability,' but the paper does not specify the probability space or the adversarial strategy over which P1, P2, and P3 are taken; clarifying that these are probabilities over uniformly random choices of A2 and B2 would make the analysis easier to interpret.","section":"Section 6.1, Eq. (6)"},{"comment":"The performance evaluation reports an average overhead of about 4 microseconds but does not state the number of trials, the variance, or the statistical significance of the comparison with HMAC; adding this information would improve reproducibility.","section":"Section 6.2"}],"recommendation":"reject","confidential_remarks":"The central flaw is elementary: CRC is affine in the message, and the paper's own 'Beyond collisions' paragraph sketches the correct attack before incorrectly dismissing it. The affine forgery cannot be repaired within the proposed design without replacing the core mechanism with a keyed cryptographic primitive, which would change the paper's central contribution. I see no path to acceptance without a fundamental redesign and a re-evaluation of the security claims."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: the paper has a good practical instinct and a clean experimental setup, but the central security claim collapses under an affine forgery attack that the authors dismiss on incorrect grounds.\n\nWhat's new: the specific combination of a secret InitVec for CRC computation plus OTP encryption of the CRC via a hash chain is a legitimate twist on prior secret-polynomial CRC work. The paper is honest about the need to break linearity and tries to address it, and the deployment-oriented thinking (hash chain management, retransmission behavior, coexistence with non-secure devices) is thoughtful. The experimental evaluation on real hardware with ~4us overhead and interoperability with plain Modbus devices is real evidence; they also ship code.\n\nWhere it goes wrong: the security analysis in Section 6.1 is wrong. Because CRC is affine in the message for any fixed InitVec, an attacker who sees one valid tuple (M, C = F(I,M) XOR h) can forge a tag for M' = M XOR X as C' = C XOR P(X), where P(X) is a public function of X and the CRC parameters. The unknown h cancels. The paper's claim that the attacker still needs to learn the InitVec is false; the difference term is independent of I. Their experimental observation that nonzero InitVec makes the function 'lose linearity' is irrelevant: what matters is affinity, and the offset is still present. This is a deterministic forgery, not a probabilistic collision. The collision probability analysis (Pc ~ 1/2^n) addresses a different question: guessing the tag with wrong parameters. It doesn't cover an attacker who has seen a valid pair and flips bits.\n\nI also want to note the brute-force discussion: using a fresh hash per message does help against brute force, but that doesn't fix the forgery, and the frame already carries the forgery. The paper's own equations contain the attack; it's not a subtle implementation issue.\n\nWho it's for: anyone working on lightweight authentication for legacy fieldbuses will find the practical framing useful, but this version should not be published as a secure scheme. It's a cautionary example of why CRC's affine structure must be destroyed, not just hidden. I'd send it back for major revision only if the authors can either change the construction to break affinity or reposition the paper as an attack/contrastive study. As is, rejecting is right, but it deserves a full referee process, not a desk reject, because the flaw is instructive and the material is non-trivial.\n\nRecommendation: send it to peer review if it crosses your desk; the right call after review is likely rejection, but the paper is worth refereeing.","headline":"A practical retrofit idea with a real security flaw: CRC's affine structure lets an attacker forge tags without knowing the secret.","tokens_in":15465,"tokens_out":1874,"would_cite":false,"duration_ms":17610,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper claims that a cryptographically computed CRC field—using a secret initialization vector and one-time-pad encryption—authenticates legacy industrial messages without changing frame formats or adding hardware.","keywords":["ACRIC","legacy industrial protocols","message authentication","integrity protection","cryptographic CRC","one-time pad","backward compatibility","retrofit security"],"falsifier":"Observe one valid pair $(M, C)$, compute $F_{CRC}(0, X)$ for any difference $X$ using the public CRC polynomial, and send $M' = M \\oplus X$ with tag $C' = C \\oplus F_{CRC}(0, X)$; the verifier's recomputation matches $C'$, so the forged message is accepted, settling that the claimed authentication does not hold.","tokens_in":14453,"feed_emoji":"🛡️","tokens_out":10473,"duration_ms":89236,"temperature":0.7,"pith_summary":"ACRIC repurposes the CRC field that already exists in most industrial protocols as an authentication tag. The sender computes the CRC with a secret initialization vector and XOR-encrypts the result with a single-use value from a hash chain, giving $ACRIC_i = F_{CRC}(InitVec, M_i) \\oplus h_i$; the receiver accepts a message only if recomputation with the same secrets matches. The paper argues that this provides authentication, integrity, and replay resistance while preserving the original frame format, coexisting with non-secured devices, and adding only about $4 \\,\\mu s$ per message. The point is practical: legacy industrial systems can be retrofitted with message authentication by a software-only change, with no additional hardware and no data-throughput loss.","feed_headline":"Encrypting the CRC field authenticates legacy traffic in ~4 µs","feed_subtitle":"No new hardware or frame changes: a software-only retrofit for industrial control networks.","key_machinery":"The machinery is the ACRIC tag $ACRIC_i = F_{CRC}(InitVec, M_i) \\oplus h_i$, a standard CRC computation modified in two ways: the initialization vector is a secret value derived from the session key, and the resulting CRC is XORed with a single-use hash-chain value $h_i$ (one-time-pad encryption). Two properties carry the security argument: injectivity of $F_{CRC}$ in the initialization vector, which the paper verifies experimentally for 41 CRC variants and uses to claim that a wrong tag is as likely as a random guess; and absence of linearity under a non-zero InitVec, which the paper claims blocks additive forgeries. The hash chain supplies fresh keys so that a replayed message carries the wrong $h_i$ and is rejected with probability 1 within a session.","core_discovery":"The paper's central claim is that a CRC value, computed with a secret initialization vector and encrypted with a hash-chain one-time pad, can serve as a message-authentication tag. In symbols, the tag is $ACRIC_i = F_{CRC}(InitVec, M_i) \\oplus h_i$, where $F_{CRC}$ is the standard CRC function, $InitVec$ is a secret value derived from a session key, and $h_i$ is the $i$-th value of a hash chain. The paper asserts that a matching tag confirms both the authenticity and the integrity of the message, that the one-time-pad layer preserves the secrecy of $InitVec$, and that injectivity of the CRC function in the initialization vector makes the successful-forgery probability roughly $2^{-n}$ for an $n$-bit CRC. The claimed advantage over earlier proposals is that all of this happens inside the existing CRC field, so neither the wire format nor the hardware needs to change.","pith_inferences":["A consequence the paper does not draw: observing one valid pair $(M, C)$ is enough to forge a tag for $M \\oplus X$, namely $C \\oplus F_{CRC}(0, X)$, without ever learning the secret InitVec or the hash value, because CRC is affine over $GF(2)$.","The one-time-pad layer protects the confidentiality of the transmitted CRC but does not prevent this deterministic forgery once a single valid reference pair is available.","A testable extension would be to key the CRC polynomial itself or apply a keyed nonlinear transformation to the message before the CRC, since keeping the polynomial and the XOR-out value public leaves the additive relation exploitable."],"forward_implications":["If ACRIC works as claimed, a software update can add message authentication to Modbus, CAN, Profibus, and DNP3 devices without changing frame layouts or replacing hardware.","Secured and unsecured devices could interoperate on the same network, allowing staged upgrades of legacy installations.","The measured overhead of about $4 \\,\\mu s$ per message is small enough for real-time industrial loops that cannot tolerate the roughly $371 \\,\\mu s$ of SHA-1 HMAC.","Because the tag space is limited to the CRC length of 8 to 64 bits, the scheme's brute-force resistance depends on enforcing failure thresholds and on consuming a fresh hash value per message.","Both point-to-point and broadcast traffic can be protected by using pair-based or group-based session keys."],"supporting_citations":[{"why":"Supplies the standard CRC definition and notation that ACRIC modifies with a secret initialization vector.","marker":"[44]"},{"why":"Justifies the one-time-pad perfect secrecy the scheme relies on to hide the transmitted CRC value.","marker":"[46]"},{"why":"Defines the Dolev-Yao attacker model with full network access but no key material, which the security assessment assumes.","marker":"[11]"},{"why":"Establishes Kerckhoffs' principle that security rests on key secrecy rather than on hiding the protocol.","marker":"[41]"},{"why":"Provides prior CRC-based authentication methods that ACRIC extends by choosing a secret InitVec instead of a secret generator polynomial.","marker":"[13]"},{"why":"Documents the industrial practice of suspending devices after repeated failed messages, which the paper relies on to resist brute-force attacks.","marker":"[35]"}],"fun_headline_variants":["CRC field becomes a one-time-pad authentication tag for legacy networks","Software-only fix turns CRC into an authenticity check for OT systems","Authenticate legacy traffic with a one-time-padded CRC, no new hardware","Use the existing CRC check to authenticate industrial messages in 4 µs","No format change: CRC field becomes a one-time pad for message authentication"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the affine structure of CRC cannot be exploited without knowing the secret initialization vector; if an attacker can combine one observed message/tag pair with the public CRC formula to forge another valid tag, the authentication guarantee collapses.","fun_headline_variants_meta":{"raw":{"variants":["CRC field becomes a one-time-pad authentication tag for legacy networks","Software-only fix turns CRC into an authenticity check for OT systems","Authenticate legacy traffic with a one-time-padded CRC, no new hardware","Use the existing CRC check to authenticate industrial messages in 4 µs","No format change: CRC field becomes a one-time pad for message authentication"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000526,"raw_usage":{"total_tokens":2565,"prompt_tokens":998,"completion_tokens":1567,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":614,"completion_tokens_details":{"reasoning_tokens":1487}},"tokens_in":614,"tokens_out":1567,"duration_ms":10687,"temperature":1.0,"reasoning_tokens":1487,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T15:14:09.152571+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Observe one valid pair $(M, C)$, compute $F_{CRC}(0, X)$ for any difference $X$ using the public CRC polynomial, and send $M' = M \\oplus X$ with tag $C' = C \\oplus F_{CRC}(0, X)$; the verifier's recomputation matches $C'$, so the forged message is accepted, settling that the claimed authentication does not hold.","supporting_citations":[{"cited_title":"IEEE Micro8(4), 62–75 (1988)","cited_arxiv_id":null,"evidence_quote":"Supplies the standard CRC definition and notation that ACRIC modifies with a secret initialization vector."},{"cited_title":"In: Encyclopedia of Cryptography, Security and Privacy, pp","cited_arxiv_id":null,"evidence_quote":"Establishes Kerckhoffs' principle that security rests on key secrecy rather than on hiding the protocol."},{"cited_title":"In: Proceedings of the 11th ACM Confer- ence on Security & Privacy in Wireless and Mobile Networks","cited_arxiv_id":null,"evidence_quote":"Provides prior CRC-based authentication methods that ACRIC extends by choosing a secret InitVec instead of a secret generator polynomial."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Documents the industrial practice of suspending devices after repeated failed messages, which the paper relies on to resist brute-force attacks."}],"review_version":1}