Technical notes — July 2026
AI and AES inversion: technical FAQ
This companion to Can you train AI to invert AES? states the proposal's assumptions more precisely and separates an experimental optimization program from a claim of practical cryptanalysis.
Does expressing AES inversion as SAT imply that AES is vulnerable?
No. A polynomial-size Boolean circuit for AES gives a polynomial-size SAT encoding, but this is a representation result, not an efficient inversion algorithm. Every efficiently computable function admits such a circuit encoding. The security question concerns the average-case cost of solving instances drawn from the cryptographic distribution, whereas NP-completeness is a worst-case statement about an entire language.
The worst-case-to-average-case barriers discussed by Bogdanov and Trevisan and by Akavia, Goldreich, Goldwasser, and Moshkovitz therefore cut in the opposite direction from a vulnerability claim: generic NP-hardness does not supply a reduction proving that typical AES instances are hard, but neither does the absence of such a reduction make them easy. Any successful attack must exploit structure specific to the AES key schedule, S-box, linear layer, mode, or data distribution and must be evaluated directly.
What inversion problem is actually being posed for AES-XTS?
The experiment observes ciphertext blocks together with their public sector and block indices and searches over the two AES-256 keys and, where appropriate, plaintext or internal wire variables. For a block at index j, XTS computes a tweak from the second key and encrypts the tweaked plaintext under the first key. The lowered encoding introduces explicit variables for intermediate AES operations; the opaque encoding evaluates the cipher as one operation.
This must not be confused with ordinary decryption, where the key is known. It is a joint key-recovery and plaintext-recovery problem under side information. The ASCII restriction is not a property of AES-XTS and should be treated as an explicit prior on the message distribution.
Is the plaintext and key pair identifiable from a ciphertext block?
Not in general. For any candidate key pair, decryption determines a corresponding plaintext, so one ciphertext block alone does not identify the true keys. A language prior can rank candidate plaintexts, but it does not turn the cryptographic mapping into a uniquely determined inverse and may admit many false positives.
A meaningful key-recovery benchmark therefore needs enough ciphertext produced under the same keys, a clearly specified plaintext distribution, and an independent verification condition. Success should mean recovery of the planted key or correct decryption of held-out blocks, not merely finding one low-energy assignment or one printable plaintext. This distinction is essential when interpreting optimization results.
What does the augmented-Lagrangian energy change about the problem?
It changes the search geometry, not the feasible set. Residuals assign partial credit to violated local constraints, while multipliers and quadratic penalties adapt the relative cost of persistent violations. A zero-residual state remains an exact satisfying assignment, assuming the circuit encoding is correct.
There is no theorem that this energy removes cryptographic hardness. Lowering can create useful locality, but it also introduces many auxiliary variables, symmetries, plateaus, and metastable states. Hamming distance on intermediate wires may correlate with local consistency without correlating with distance to the planted key. The empirical question is whether the shaped landscape yields scaling behavior better than established SAT, SMT, mixed-integer, algebraic, and stochastic-search baselines.
What role does reinforcement learning play?
The proposed policy does not select individual key-bit flips. It emits or edits a complete solver program. An external environment compiles that program, runs it under fixed resource limits, and returns deterministic measurements such as build status, minimum residual energy, the number of consecutive consistent rounds, held-out recovery, and wall-clock cost.
Reinforcement learning is therefore a method for search over solver implementations and algorithmic choices. Any cryptanalytic capability resides in the synthesized solver and its measured generalization, not in the label AI itself. Comparisons should control for total compute spent on policy training, candidate evaluation, hyperparameter search, and final solving.
Why use reduced-round AES, and what would transfer to full-round AES require?
Reduced-round instances provide a curriculum with nonzero success rates and are standard diagnostic objects in cryptanalysis. They can reveal whether a method exploits round-local structure and can support controlled scaling studies over rounds, blocks, and key sizes.
Transfer is not guaranteed. Additional rounds amplify diffusion and may change the landscape qualitatively rather than merely increasing its size. Evidence for transfer would require preregistered scaling curves, held-out random keys and messages, comparison at equal compute, ablations of every side constraint, and extrapolations that remain accurate as the round count increases. Solving toy or reduced-round variants alone is not evidence that full AES-256 is practically invertible.
What result would count as a cryptanalytic break?
The strongest result would recover a uniformly sampled secret key for standard full-round AES or AES-XTS from a precisely stated amount of data, with success probability and total time-memory-data complexity substantially below the best generic attack. The evaluation must include independent reproduction and verification on instances not used during solver or policy development.
Weaker results may still be scientifically useful but should be named accurately: improved reduced-round cryptanalysis, better solving of a particular circuit encoding, recovery under a strong plaintext prior, or automated discovery of heuristics. Energy reduction, printable output, or success on training instances is not by itself a break.
Does this proposal change current guidance for using AES?
No. The article presents a research hypothesis and an experimental environment, not a working attack on standard AES. There is currently no result here that changes the accepted security margin of correctly implemented AES-128, AES-256, or AES-XTS.
Operational security continues to depend on correct mode selection, nonce and tweak handling, key generation and storage, authentication, implementation resistance to side channels, and appropriate protocol design. Practical failures in those areas are distinct from mathematical inversion of the block cipher and remain far more immediate concerns.