Skip to content

Commit 98a7049

Browse files
committed
add comments to keccak (#878)
clarify the correctness / soundness of the approach i'm using
1 parent c0d9bde commit 98a7049

File tree

1 file changed

+21
-1
lines changed
  • crates/frontend/src/circuits/keccak

1 file changed

+21
-1
lines changed

crates/frontend/src/circuits/keccak/mod.rs

Lines changed: 21 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -158,11 +158,31 @@ impl Keccak {
158158
// last word in the block
159159
let must_check_delimiter = b.band(is_end_block, is_not_last_column);
160160
b.assert_eq_cond("delim", padded_word, msb_one, must_check_delimiter);
161-
// if the word in which 0x01 must reside is NOT the last word in the block,
161+
// the case we need to deal with: we're in end block but `is_not_last_column`.
162+
// this means that the `boundary_message_word` is not the last word in its block
162163
// then the presence of the 0x80 delimiter is NOT treated with the boundary word
163164
// thus we must separately check that the ACTUAL last word in the block has it
165+
166+
// if `is_end_block` is true but NOT `is_not_last_column`, then we're fine.
167+
// indeed: if `!is_not_last_column`, boundary message word IS in last column,
168+
// so we already handled the validity of that word, and there is nothing to do.
169+
170+
// if NOT in end block, then again i claim there is nothing we need to check.
171+
// if we're in the last column but strictly before the end block, then we're
172+
// still in the message, by definition of `end_block`. indeed, the `0x80` byte
173+
// happens in the soonest possible block after the message ends, and no later.
174+
// thus we already checked the validity of this word above (a `message_word`).
175+
// the other case is that we're strictly after the end block. in this case,
176+
// we can just leave the `padded_word` completely unconstrained. after all,
177+
// said word will have no effect on `digest` whatsoever, so we just leave it.
164178
} else {
165179
b.assert_eq_cond("after-message padding", padded_word, zero, is_past_message);
180+
// we're strictly after the word w/ the 0x01 byte and not in the last column.
181+
// there are two cases: either we're within the end block or strictly after it.
182+
// if the former, we're after the boundary word but before the word w/ 0x80.
183+
// in that case, we must for the sake of correctness assert that this word is 0.
184+
// if strictly after the end block, this word will have no effect on `digest`;
185+
// thus we're free to assert that it's 0, but it's not necessary for soundness.
166186
}
167187
}
168188
}

0 commit comments

Comments
 (0)