AI Crisis: Smart Contract Bug Hunting & Breaking Encryption Executive Summary AI’s impact on digital asset security has moved beyond generating audit assessments to discovering vulnerabilities, constructing attacks, and validating their outcomes. Smart contracts are particularly exposed to this shift: contract code and historical transactions are typically public, execution results can be reproduced, and financial losses can be measured directly through state changes. Attackers need only one viable path to succeed. Defenders must identify and close every gap. Traditional, one-off audits struggle to address this asymmetry. Developments in cryptanalysis also demand a reassessment. Describing AI as capable of “only finding implementation bugs” no longer accounts for the research published in 2026. New structural key-recovery attacks have emerged against the HAWK signature scheme, alongside new algebraic methods and improvements in attack complexity against seven-round AES. However, the HAWK results do not break lattice-based cryptography as a whole, and the seven-round AES results do not break full-round AES. [5–9] This review reaches six key conclusions: Automated smart contract exploitation now has empirical support. SCONE and EVMbench demonstrate AI’s ability to validate vulnerabilities that cause financial losses through end-to-end exploitation in controlled environments. Benchmark success rates, however, cannot be read as the proportion of all mainnet contracts that could be successfully attacked. The AI arms race in smart contract security is underway, and defenders still have an opportunity to respond. [1–4] AI-assisted original cryptanalysis now has cases that warrant serious attention. HAWK, reduced-round AES, and certain design flaws examined in CryptanalysisBench show that AI is beginning to make substantive contributions to the analysis and breaking of cryptographic algorithms. These developments demand close attention and internal reviews of potentially affected systems. [5–9] Mainstream cryptographic systems have not been broken as a whole. No research has yet demonstrated that AI can break correctly implemented, appropriately parameterized full-round AES, RSA-2048, secp256k1, or standard ML-KEM. The most immediate losses remain concentrated in contract logic flaws, poor private-key custody, phishing, and randomness vulnerabilities. Exploiting these weaknesses generally does not require solving the underlying mathematical problems. AI’s research speed will amplify gaps in validation capacity. Producing findings is not the same as identifying valid vulnerabilities, much less managing the associated risks. Vulnerability discoveries, theoretical attacks, and patches still require human review and validation. This poses a major challenge for security teams. The security paradigm needs to evolve quickly. Integrate AI into continuous auditing, runtime monitoring, and response. Keep weak points—such as private-key management and fund-management permissions—under effective controls outside the AI system. Build an inventory of cryptographic assets and the ability to migrate algorithms as soon as possible. I. Why Smart Contracts Are Particularly Exposed to AI-Driven Vulnerability Discovery 1.1 Observable, Reproducible, with Quantifiable Losses The openness of smart contracts makes them well suited to AI-driven vulnerability discovery. AI can typically access contract code and state without restriction, formulate testable hypotheses, reconstruct execution conditions locally, and evaluate outcomes through transaction traces and balance changes. This environment provides clear feedback and lends itself to automated iteration. Openness does not make the process cost-free. Contracts without publicly available source code, proxy implementations, compiler settings, external protocol state, onchain time, and asset liquidity can all determine whether an attack is viable. AI’s advantage lies in making these conditions faster to understand and explore. 1.2 Contract Security Depends on Code, Economics, and Permissions A system can contain vulnerabilities in asset pricing, cross-contract state, or governance workflows even when no individual function has an obvious coding error. The price used to value collateral may be temporarily distorted. A router trusted by multiple vaults may fail to enforce distinct permissions for each vault. A legitimate upgrade may introduce an incompatible storage layout. Investigating these issues requires understanding three things at once: what the code permits, what the application is intended to permit, and what an attacker can control. Advances in AI’s ability to search large codebases and explore combinations of hypotheses make investigations that once demanded extensive manual effort easier to scale. 1.3 Lower Discovery Costs Expand the Pool of Economically Viable Targets As analysis costs fall, smaller protocols, forks of older versions, and long-unmaintained contracts may become economically viable targets. Repeated deployments of the same underlying code amplify the impact: a single vulnerability may affect instances across multiple projects. These economies of scale make AI-driven vulnerability discovery a highly cost-effective approach for attackers in the smart contract ecosystem. II. Smart Contract Vulnerability Discovery: What Public Research Has Demonstrated 2.1 SCONE: Retesting Historical Exploits In the SCONE study published in 2025, Anthropic and collaborating researchers used 405 contract tasks drawn from real attacks between 2020 and 2025, covering Ethereum, BNB Smart Chain, and Base. All experiments ran in simulators or on local chain forks. [1] The study evaluated 10 models. Across all models and attempts, 207 tasks were solved—51.11% of the total—with aggregate simulated profits of approximately $550.1 million. A May 2026 research update selected another 12 tasks based on historical attacks reported after January 1, 2026. The researchers reported that Mythos Preview found successful exploits for all 12, generating approximately $35 million in simulated profits. [2] 2.2 EVMbench: Finding, Patching, and Exploiting Are Different Tasks The arXiv v1 paper for EVMbench was published in March 2026 and included 117 high-severity vulnerabilities from 40 code repositories. This version evaluated vulnerability discovery, patching, and exploit execution separately, with different task counts across the three modes. [3] The researchers also found that providing business descriptions significantly improved results on some patching and exploitation tasks. The same model could also perform differently under different agent frameworks. These findings show that identifying problems in large codebases, using tools, and organizing tasks are all important variables in AI-driven vulnerability discovery and exploitation. 2.3 GoPlus AI Auditing Benchmark: From Real-Time Incident Tracking to Unknown Vulnerability Discovery Released by GoPlus in May 2026, the AI Auditing Benchmark is a dataset built specifically to evaluate AI-powered smart contract auditing. It is grounded entirely in real-world attacks, covering both major incidents with substantial impact and losses, and smaller incidents with limited losses that are technically representative. It curates the source code of vulnerable contracts from attacked projects to systematically assess AI’s capabilities in vulnerability identification, attack-path comprehension, contextual reasoning, and audit consistency. The project incorporates security incidents as they occur each week and is continuously updated. It preserves the complete source tree of the attacked contracts, including application contracts, dependencies, and interfaces. This makes it suitable for evaluating AI auditing across complex call relationships, cross-module state flows, and the full context. More details: https://github.com/GoPlusSecurity/ai-auditing-benchmark 2.4 What These Benchmark Results Tell Us Together, these datasets and results demonstrate AI’s ability to validate vulnerabilities that cause financial losses through end-to-end exploitation in controlled environments. Benchmark success rates, however, cannot be read as the proportion of all mainnet contracts that could be successfully attacked. The AI arms race in smart contract security is underway, and defenders still have an opportunity to respond. III. How AI Is Changing Smart Contract Vulnerability Research 3.1 High-Value Vulnerability Classes and Validation Priorities 3.2 Refine Business and Security Descriptions Instead of Relying on Broad Vulnerability Keywords AI’s most valuable role is to turn code, deployment information, and business descriptions into testable questions, then use the appropriate tools to validate them. The following closed-loop workflow is recommended: Model assets and permissions → Define security properties → Analyze candidate mechanisms → Perform independent testing and solving → Inspect transaction traces → Confirm impact through human review → Apply fixes and run regression checks. Useful business and security knowledge should capture the protocol’s own commitments and key risks. For example: Ordinary users must not be able to change the administrator, implementation address, or protocol fee recipient. A one-time authorization must not be successfully reused within the same authorization domain after it is first successfully consumed. With fixed valuations, no external yield, and an explicit rounding policy, a round-trip exchange must not create additional redeemable assets out of thin air. Reprocessing a cross-chain message that has already been successfully processed must not increase the spendable balance again. When the contract is paused, fund operations that the documentation specifies should be paused must actually be unreachable. Even a property such as “assets exceed liabilities” requires explicit valuation and market assumptions. Market risk inherent in the intended design must not be misreported as a software vulnerability. Formal tools can prove only the properties written into the specification; they cannot replace judgment about whether the specification itself is correct. IV. Breaking Cryptographic Algorithms: What Needs Reassessment in 2026 4.1 HAWK: A Structural Attack with Consequences for Scheme Design In July 2026, Anthropic published research on key recovery against HAWK, a post-quantum signature candidate based on the lattice isomorphism problem. The research exploits nontrivial automorphisms in a particular lattice structure to reduce key recovery to lower-dimensional instances of the exact Shortest Vector Problem (SVP). It does not exploit a conditional branch that a programmer implemented incorrectly. [5–6] The technical paper gives a more precise result than headlines claiming that “key strength has been halved”: key recovery for HAWK-n can be reduced to a polynomial number of calls to an exact SVP oracle in dimension n/2 + 1. A polynomial-time reduction does not make the complete attack polynomial-time; the SVP oracle itself remains computationally expensive. On July 29, 2026, the HAWK authors announced their withdrawal from NIST’s additional digital signature standardization process, explicitly stating that the scheme was insecure and should not be used. The announcement noted that fixes such as simply increasing the parameters would leave it uncompetitive. [7] This is an algorithm-design result with substantive consequences. Its scope is also clear: the failure of HAWK’s particular structure does not mean that LWE, ML-KEM, or all lattice-based signatures have been broken. The paper also explicitly analyzes why the attack does not transfer directly to Falcon. As for AI’s contribution, the researchers describe work conducted in an agent environment equipped with tools, supported by computational experiments and intermittent human guidance. The work took approximately 60 hours and incurred about $100,000 in API costs. The algorithmic result and the scheme’s withdrawal can be independently verified. Precise attribution of how much AI completed independently still depends on the researchers’ process records. 4.2 Reduced-Round AES: Major Complexity Improvements, Still Far from a Practical Break Another 2026 paper examines the seven-round version of AES-128. Standard AES-128 uses 10 rounds; AES-192 and AES-256 use 12 and 14 rounds, respectively. [8][22] The paper builds on a meet-in-the-middle attack approach, using the algebraic structure of the AES S-box to construct a new fingerprinting method. This removes the need to guess one key byte. Together with computational optimizations, the method reduces attack costs. The authors report that, at a data complexity of approximately 2^105 chosen plaintexts, time complexity falls from roughly 2^99 to 2^89.3–2^91.4—a speedup of about 200–800 times, depending on the cost-accounting method. [8] The result has research value: it shows that AI-assisted research can produce new algebraic attack constructions against a long-studied target. It does not, however, constitute a practical break of AES as deployed in production: The target is a seven-round variant. The attack cannot be applied directly to full, 10-round AES-128. The required number of chosen plaintexts is enormous. This is not an attack that becomes usable after intercepting a small amount of TLS traffic. A time cost on the order of 2^89 or higher remains impractical. The original paper explicitly states that the complete attack was not run end to end; its components were validated through mathematical analysis and smaller-scale experiments. A “hundreds-fold speedup” describes a complexity improvement within a particular attack model, not the speed of decrypting arbitrary real-world ciphertexts. The paper and accompanying research overview also expose a validation bottleneck: generating a candidate breakthrough may take less time than humans need to establish its correctness and full cost. For future cryptanalysis review, this has greater long-term significance than this particular speedup. 4.3 CryptanalysisBench: Distinguishing Design, Specification, and Code Flaws The July 2026 v2 paper for CryptanalysisBench includes 191 tasks spanning six classes of cryptographic primitives: block ciphers, hashes, authenticated encryption, KEMs, public-key encryption, and digital signatures. The tasks range from schemes with known practical attacks to schemes without known practical attacks and their reduced versions, extending to a more difficult challenge set. [9] The study uses an isolated security controller to hold secrets, allowing AI to interact only through permitted queries. Final scripts are rerun on fresh random instances. This provides stronger validation than asking a model to guess a key that is already public. The paper reports that five models achieved solve rates of approximately 65%–86% on Tier 1 schemes with known practical attacks. In Tier 2, results aggregated across models showed that 14 distinct schemes were broken in their full configurations. The authors further distinguish: Two schemes with genuine design or security-proof flaws: SpoC and KINDI. Two schemes with specification gaps that lead to insecure implementations. Ten schemes with errors in their reference implementations. For SpoC, the result concerns a design flaw in how the authenticated encryption mode handles boundary-case messages. For KINDI, it exposes an error in the scheme’s CCA security argument. These are substantive advances in the study of candidate schemes. They must not be presented as “AI breaking 14 mainstream standardized cryptographic algorithms.” The paper also explicitly acknowledges limitations: many attacks can be recalled from existing knowledge, reference-code errors affect overall scores, reduced parameters do not always produce a smooth difficulty gradient, and probabilistic security games introduce issues involving statistical errors and resource budgets. V. Why Insecure Implementations and Key Leakage Remain the Most Immediate Risks 5.1 Attackers Use Information Beyond the Ciphertext A cryptographic algorithm may be secure within its mathematical model, while its implementation on a device still leaks secrets through power consumption, electromagnetic emissions, timing, or cache behavior. ASCAD studies masked AES implementations and publishes measurement data and model configurations to improve the reproducibility of deep-learning side-channel research. [12] It demonstrates that mathematically correct AES implementations still need protection against leakage. It does not show that supplying a ciphertext remotely is enough to recover an arbitrary AES key. Evaluating this research requires explicit assumptions: Can the attacker access the target device? Can they obtain a comparable device whose keys they control? Are training and attacks performed on the same device? Does the attack transfer across devices? How many measurements are required, and under what noise conditions? Constant-time implementations primarily limit timing-related leakage; they do not replace dedicated defenses against power, electromagnetic, and other side channels. 5.2 Password Guessing: Learning Human Preferences, Not Eliminating Random-Key Entropy Research such as PassGAN learns human password distributions to improve candidate generation. [13] For some password distributions, a better ordering of guesses does increase the hit rate within a fixed budget. But password-hash verification, online login attempts, and searches for random cryptographic keys are three different problems. Offline password attacks are constrained by KDF costs. Online attacks also face rate limits and authentication policies. Learning common human passwords offers no equivalent advantage against independently and uniformly generated keys. Salts prevent direct reuse of the same precomputed results across accounts, but they do not make weak passwords strong. Memory-hard KDFs such as Argon2id help defenders by increasing the cost of each guess. They still need to be combined with sufficiently strong passwords, parameters appropriate to the device, and sound authentication design. [21] 5.3 Randomness and Nonces: Different Protocols, Different Requirements Reused, biased, or leaked ECDSA signing nonces can turn private-key recovery into an algebraic or lattice-analysis problem. AI can help identify errors, organize observations, and invoke analysis tools. The root cause of the failure is a violation of nonce requirements—not a solution to the general elliptic-curve discrete logarithm problem. RFC 6979 specifies deterministic nonce generation for DSA and ECDSA, an established mitigation for certain risks associated with dependence on randomness. [15] It does not mean that any custom deterministic nonce implementation is secure, nor does it eliminate side-channel attacks, fault injection, or poor key management. Nonces in AEAD have different semantics. For example, reusing a nonce under the same key in GCM can compromise confidentiality and authentication. Signing nonces, encryption nonces, and contract-authorization nonces must not be treated as the same mechanism. 5.4 Key Extraction, Unintended Signing, and Misuse If an agent can directly read seed phrases or invoke a signer without restrictions, attackers may influence its behavior through prompt injection, malicious dependencies, or tool outputs. Funds can still be transferred using valid signatures even when the underlying cryptography remains entirely sound. HSMs, MPC-based systems, and hardware wallets can reduce certain key-leakage risks. But if their policies allow arbitrary transactions to be signed blindly, they cannot fully prevent authorization abuse. The target contract, assets, amount limits, validity period, and transaction semantics must be validated outside the model. VI. Key Risks at the Intersection of Smart Contracts and Cryptographic Systems 6.1 Cryptographic Validity Does Not Guarantee Correct Business Authorization A signature can be mathematically valid without being bound to the chain, contract address, action, amount, recipient, or expiry. The verifier confirms that the signature corresponds to a particular key but does not establish whether that authorization applies to the current operation. EIP-712 provides structured signing and domain separation, but the specification explicitly states that it does not itself include replay protection. [14] One-time authorizations still require application logic to maintain nonces or usage records and verify that the fields covered by the signature exactly match the parameters used in execution. For bridges, proving that a message genuinely exists on a particular chain does not establish that the current contract should execute it. Requirements for message origin, destination domain, sender, uniqueness, and finality must all be satisfied. 6.2 A Correct Proof System Can Still Prove Too Little Successful verification of a zero-knowledge proof establishes only that a defined relation has been satisfied. If the circuit omits range constraints, fails to bind critical public inputs, or the verifier uses an incorrect verification key or verification context, application security can still fail. AI can help compare circuits, specifications, and onchain execution paths to identify gaps where “A was proved, but B was required.” Reports must specify whether the issue lies in circuit constraints, protocol binding, or the proof system itself. Such findings must not be indiscriminately presented as “zero-knowledge cryptography has been broken.” 6.3 AI Security Tools Introduce New Trust Boundaries Repositories under audit, dependency packages, error logs, and web content may contain malicious instructions targeting the agent. If that content influences its use of privileged tools, the research system itself may be induced to leak secrets, modify the validation environment, or invoke a live signing service. OpenAI’s documentation discusses prompt injection, untrusted input, data leakage, tool permissions, and structured-data boundaries, reflecting these general risks. [20] Specific protections should be enforced by the runtime environment and policies, rather than relying solely on prompts telling the model to be cautious. Keep the analysis environment, evidence-validation environment, and live signing environment separate. The analyzer can propose transactions or patches; an independent system checks their properties; the signer signs only as permitted by explicit policies. Sensitive actions must not be approved solely because “AI judged them safe.” VII. The Economics of Attack and Defense: How Falling Attack Costs Translate into Real Risk 7.1 Cost Model A simplified expression for the expected return from vulnerability discovery and exploitation is: The probabilities and values depend on protocol state, target selection, and resource budgets, and are generally interrelated. The expression provides a framework for analysis; it cannot predict theft amounts without supporting data. AI may reduce the cost of understanding code and constructing attacks. Better target selection may also reduce time spent analyzing unviable targets. Competition, slippage, and capital constraints, however, may offset some of those gains. Model invocation costs do not represent the full cost of an attack. 7.2 Attackers Need One Success; Defenders Bear the Burden of Coverage Attackers may need to find only one path that can be monetized. Defenders remain responsible for permissions, security specifications, deployment configurations, third-party dependencies, and emergency response. A single AI audit that finds no issues is no reason to stop checking. Defenders also have advantages: early access to code, design intent, deployment plans, and monitoring permissions. They can eliminate issues before launch and maintain continuous auditing and security monitoring afterward. Turning that information and time advantage into an ongoing validation process matters more than purchasing any particular model. 7.3 Validation and Remediation May Become Bottlenecks As AI increases the volume of candidate findings, security teams may be overwhelmed by low-quality reports unless they have deduplication, evidence grading, and counterexample reproduction in place. In cryptographic research, cost estimates and the scope of theoretical results also require more rigorous specialist review. Improving defensive capability requires speeding up all three stages: finding problems, confirming them, and fixing them safely. Simply counting reports, lines of code scanned, or model calls can obscure the real risks. VIII. Security Hardening Roadmap 8.1 Move from One-Off Audits to Continuous Auditing Project teams and developers should use specialized AI auditing tools for regular and continuous smart contract audits. These audits should provide greater depth and efficiency than traditional manual audits while remaining cost-effective. AI should analyze contract source code, permission management, and business logic in depth, systematically scan for common security issues—including syntax-level and business-logic vulnerabilities—and produce structured audit reports. Projects already in production should adopt continuous security monitoring and risk-response services. These services should closely track emerging vulnerability intelligence, newly reported attacks, and risks involving external dependencies, including vulnerable contracts, oracles, cross-chain bridges, and third-party protocols. AI should continuously assess whether the project is affected and provide targeted security-check plugins. This establishes ongoing security monitoring and risk response, addressing the limitations of traditional audits that treat the audit itself as the finish line. More details: https://deepscan.gopluslabs.io/ 8.2 Cryptographic Engineering: Close Directly Exploitable Gaps First Use established cryptographic libraries and standard cryptographic constructions. Avoid inventing custom combinations of encryption and signatures. Verify the correctness of randomness sources, nonce lifecycles, error handling, domain separation, and key derivation. For hardware and embedded deployments, assess the actual leakage channels. Build an inventory of cryptographic assets that records, at a minimum, algorithms, parameters, protocol uses, key locations, responsible owners, required data-confidentiality lifetimes, and replacement difficulty. Plan post-quantum migration for data that must remain confidential over the long term. For hybrid schemes, validate the composition, negotiation binding, and downgrade protection. Simply invoking two algorithms side by side is not enough. For schemes such as HAWK that their authors have explicitly declared insecure, review actual deployments and act according to the published advisory. For standard algorithms without evidence of an applicable attack, do not rush to replace them with untested designs based solely on headlines. 8.3 Agentic Security: Strict Controls over Funds and Private Data By default, AI analysis environments should hold no real seed phrases or production keys and should have no access to unrestricted signing interfaces. Scope AI tool access to the task. Restrict network egress and access to sensitive directories and blockchain endpoints. Treat untrusted code and logs strictly as data. Text within them must not change tool permissions. Validate the target, amount, asset, expiry, and permitted call semantics of every signing request. Set limits on amounts, frequency, and cumulative losses, along with stop conditions, for automated actions involving funds. Retain necessary records of inputs, tool calls, and validation while keeping secrets out of logs. Human review should focus on decisions with material consequences. Reviewers should be given clear explanations of transaction semantics and supporting evidence. Adding a confirmation box for users to click, without explaining the actual asset changes, does not create a reliable security boundary. Summary and Recommendations The most concerning aspect of the “AI crisis” is the efficiency gap between vulnerability discovery, attack implementation, and security hardening. Smart contracts offer a short path from vulnerability to financial loss, so this gap can quickly translate into asset risk. Cryptographic research and migration operate on longer cycles. When a critical security assumption changes, the consequences can span multiple systems and the foundations of business operations. The reality of AI-driven vulnerability discovery demands that defenders take AI’s end-to-end vulnerability discovery and exploitation capabilities, as well as its cryptanalysis capabilities, seriously. Using AI to counter AI may be the only way to address this crisis. We should move quickly to establish AI-powered continuous auditing, security monitoring, and incident response. References The links below point to the original papers, specifications, and official materials consulted or checked for this report. Dynamic webpages and repositories were accessed on October 26, 2026; paper versions are specified in the individual entries. Experiments described by the researchers were not independently rerun for this report. [1] Anthropic / MATS / Anthropic Fellows. AI agents find smart contract exploits, December 2025. https://www.anthropic.com/research/smart-contracts Supports the figures for SCONE’s 405 tasks, Best@8, simulated profits, and the screening experiment involving 2,849 new contracts. [2] Anthropic. Measuring LLMs’ ability to develop exploits, May 22, 2026. https://www.anthropic.com/research/exploit-evals Supports the 12 updated tasks, Best@8, and approximately $35 million in simulated profits. [3] Wang et al. EVMbench: Evaluating AI Agents on Smart Contract Security, arXiv:2603.04915v1, March 5, 2026. https://arxiv.org/html/2603.04915v1 All EVMbench figures in this report use this version. [4] Anthropic. scone-bench, repository documentation, accessed October 26, 2026. https://github.com/anthropics/scone-bench Explains the difference between the 417-task dataset and the earlier 405-task snapshot. Content on the main branch may continue to change. [5] Anthropic. Discovering cryptographic weaknesses with Claude, July 28, 2026; the page records an edit on July 29. https://www.anthropic.com/research/discovering-cryptographic-weaknesses Provides the researchers’ account of HAWK, reduced-round AES, and the discovery process. [6] Straznickas & Weis. HAWK-n Key Recovery Reduces to SVP in Dimension n/2 + 1, 2026. https://www.anthropic.com/document/hawk_key_recovery.pdf Supports the reduction structure, gate-count costs, and HAWK-256 experiments. See the abstract and Section 6. [7] HAWK Design Team. Hawk official website and withdrawal announcement dated July 29, 2026. https://hawk-sign.info/ Confirms the scheme authors’ formal response to the new attack and their withdrawal, independently of the model vendor’s account. [8] Nasr & Carlini. Cryptanalysis of 7-Round AES via the Algebraic Structure of its S-box, 2026. https://www.anthropic.com/document/aes_mobius_bridge.pdf Supports the seven-round scope, data complexity of 2^105, time complexity of 2^89.3–2^91.4, and the statement that the attack was not executed end to end. [9] Fluri et al. CryptanalysisBench: Can LLMs do Cryptanalysis?, arXiv:2607.18538v2, July 29, 2026. https://arxiv.org/html/2607.18538v2 Supports the 191 tasks, validation through security games, and classification of design, specification, and implementation flaws. See especially Sections 3, 4, and 5.4. [10] Gohr. Improving Attacks on Round-Reduced Speck32/64 using Deep Learning, CRYPTO 2019. https://eprint.iacr.org/2019/037 Documents earlier advances in neural distinguishers and attacks on an 11-round reduced variant. [11] Wenger et al. SALSA: Attacking Lattice Cryptography with Transformers, arXiv:2207.04785v2, revised in 2023. https://arxiv.org/html/2207.04785v2 Supports machine-learning analysis of LWE instances with sparse binary secrets and the associated parameter limitations. [12] Prouff et al. Study of Deep Learning Techniques for Side-Channel Analysis and Introduction to ASCAD Database, 2018, with subsequent revisions. https://eprint.iacr.org/2018/053 Supports research on deep-learning side-channel attacks against masked AES and reproducible experiments. [13] Hitaj et al. PassGAN: A Deep Learning Approach for Password Guessing, arXiv:1709.00440v3, 2019. https://arxiv.org/abs/1709.00440v3 Supports candidate-generation methods that learn human password distributions. [14] Ethereum. EIP-712: Typed structured data hashing and signing. https://eips.ethereum.org/EIPS/eip-712 The specification explicitly states that it does not itself include replay protection. [15] Pornin. RFC 6979: Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA), 2013. https://www.rfc-editor.org/rfc/rfc6979.html Supports the standard method for deterministic signing nonce generation. [16] NIST. SP 800-57 Part 1 Revision 5: Recommendation for Key Management, 2020. https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final Provides the baseline framework for key management and security-strength comparisons. [17] NIST. FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard, August 13, 2024. https://csrc.nist.gov/pubs/fips/203/final The ML-KEM standard. Official errata should also be checked during deployment. [18] NIST. FIPS 204: Module-Lattice-Based Digital Signature Standard, August 13, 2024. https://csrc.nist.gov/pubs/fips/204/final The ML-DSA standard. [19] NIST. FIPS 205: Stateless Hash-Based Digital Signature Standard, August 13, 2024. https://csrc.nist.gov/pubs/fips/205/final The SLH-DSA standard. [20] OpenAI Docs. Safety in building agents, accessed October 26, 2026. https://developers.openai.com/api/docs/guides/agent-builder-safety Provides general guidance on prompt injection, untrusted input, and tool-permission risks. This report does not rely on the page’s product-specific configuration recommendations. [21] Biryukov et al. RFC 9106: Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications, 2021. https://www.rfc-editor.org/rfc/rfc9106.html Supports memory-hard password derivation and the need to assess implementation parameters for the intended use case. [22] NIST. FIPS 197: Advanced Encryption Standard (AES), updated in 2023. https://csrc.nist.gov/pubs/fips/197/final Supports AES parameters and standard round counts. [23] Shor. Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer. https://arxiv.org/abs/quant-ph/9508027 Provides theoretical background on quantum algorithms for factoring and discrete logarithms. [24] Grover. A fast quantum mechanical algorithm for database search. https://arxiv.org/abs/quant-ph/9605043 Provides theoretical background on quantum unstructured search.(Consensus expectations: Consensus for 2026Q3 expects EPS of -0.99 on revenue of USD 8.128 million.)