Closed jadephilipoom closed 3 years ago
Cool!
Did you consider an alternative definition of ceiling
like this one?
Definition ceiling (a b : nat) := (a + b - 1) / b.
Regarding sha256_padder_invariant
, could I also think of it as a simulation relation between the low-level state (state : denote_type (Bit ** sha_word ** Bit ** BitVec 4 ** BitVec 61 ** BitVec 16))
and the high-level state (msg : list Byte.byte) (msg_complete padder_done : bool) (index : nat)
?
Did you consider an alternative definition of
ceiling
like this one?Definition ceiling (a b : nat) := (a + b - 1) / b.
Yes, I'm not sure which will be easier to work with -- but most of the proofs about ceiling
are unproven and I don't think I ever unfold it, so changing the definition as is convenient for its proofs should be easy.
Regarding
sha256_padder_invariant
, could I also think of it as a simulation relation between the low-level state(state : denote_type (Bit ** sha_word ** Bit ** BitVec 4 ** BitVec 61 ** BitVec 16))
and the high-level state(msg : list Byte.byte) (msg_complete padder_done : bool) (index : nat)
?
Yes! Like you can see with padder_done
, in some cases it's just directly lifting low-level state variables up to the high-level state; then the precondition and output spec are stated relative to the high-level state.
I'm refining this strategy a bit as I go, but it seems to work well so far for reducing complexity in proofs; you can reason about the circuit with whatever high-level representation makes sense instead of unfolding its entire step function.
On top of #925 (will be marked draft until #925 is merged).
Padder proofs are now done except for a few lemmas that are not padder-specific (they're only about
N
,bytes
,nat
, etc). The full output fromPrint Assumptions
is:I'm pretty confident that all these lemmas are true and not too terrible to prove.