fix(sim): eqobs_in must not assume an abstract call preserves glob A for distinct oracles - #1143
Open
namasikanam wants to merge 1 commit into
Open
namasikanam wants to merge 1 commit into
namasikanam wants to merge 1 commit into
Conversation
… distinct oracles
`f_eqobs_in` (FBabs case, ecPhlEqobs.ml) unconditionally added `={glob A}` to
the invariant inferred for an abstract call `A(O_l) ~ A(O_r)` (`Mpv2.add_glob
top top eqi`), asserting the call preserves the adversary's globals without
checking the oracle pair. With two distinct oracles where the right one writes
a global belonging to `glob A`, `={glob A}` is not actually preserved, so `sim`
inferred a false
equiv[ A(O1).main ~ A(O2).main : ={glob A} ==> ={res} ]
(turned into a proof of `false` via byequiv). This is the eqobs_in analogue of
the equivF_abs oracle-footprint bug.
Only add `={glob top}` when, for every oracle pair, the two oracles are the
same procedure (same code => mirrored writes to `glob top`) or neither
modifies `glob top`; otherwise the simulation cannot be inferred and eqobs_in
falls back to requiring a user-supplied specification.
Regression: tests/eqobs-abs-oracle-glob.ec (the `proc*; sim` proof must fail).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
sim(viaf_eqobs_in) infers a false equivalence between two abstract-function callsA(O1).main ~ A(O2).mainwhen the two oracles differ and one of them writes a global thatbelongs to
glob A. This yields a proof offalsewith no axioms/admits/clones. It is theeqobs_inanalogue of theequivF_absglob-A oracle-footprint bug fixed in #1099, but in aseparate file and tactic (
ecPhlEqobs.ml/sim, notecPhlFun.ml/proc), so #1099does not cover it.
Proof of
falseon currentmainInstantiating
AwithC(which returnsShared.g) and running fromShared.g = 5, the leftside returns 5 and the right returns 6, so the results genuinely differ; the false
equivequates their probabilities, giving
1 = 0.Root cause
In
f_eqobs_in'sFBabscase, the inferred invariant unconditionally gets={glob top}added(
Mpv2.add_glob env top top eqi), asserting the abstract call preserves the adversary's globals— without checking the oracle pair (
(* TODO check that inv contain only global *)). Withdistinct oracles where the right one writes a global in
glob A, that equality is not actuallypreserved.
Fix
Only add
={glob top}when, for every oracle pair, the two oracles are the same procedure(same code ⇒ mirrored writes to
glob top) or neither modifiesglob top; otherwise thesimulation cannot be inferred and
eqobs_infalls back to requiring a user-suppliedspecification. The common identical-oracle case is unaffected.
Validation
main, rejected after the fix.simproof regresses).tests/eqobs-abs-oracle-glob.ec.