-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CBMC: Proof of poly_ntt()
#371
Conversation
2ecb068
to
d6fcd2a
Compare
5db404b
to
fb46e4e
Compare
d0ec687
to
62fd65f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lovely work.
2e16096
to
04e453c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Thanks @hanno-becker - this is as readable as it gets now I think. The splitting makes sense.
Small nits.
04e453c
to
4bf8a98
Compare
4bf8a98
to
898c46d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - thanks @hanno-becker for integrating my suggestions.
898c46d
to
c246ad4
Compare
This commit adds a spec and proof for the MLKEM forward NTT. The main difficulty in proving the forward NTT type-safe is to formalize the bounds reasoning showing that the additions and subtractions in the butterflies do not overflow. Luckily, very basic layer-to-layer bounds reasoning is sufficient to achieve an output bound of 8*q, which is enough for reason about the calling code: When moving from layer N to layer N+1, every coefficient is replaced by the addition or subtractio or a layer N coefficient with the result of a Barrett multiplication with a signed canonical twiddle factor. Since such Barrett multiplication always has absolute value < q (this could be improved significantly if we needed to), the absolute bounds increase by at most q. Spelling out the invariants in CBMC is cumbersome and rather verbose. To facilitate, and to keep runtimes down, this commit splits the NTT original NTT code into three functions, one per NTT loop: - The top-level poly_ntt() iterates over the layers, calling ntt_layer() - ntt_layer computes one NTT layer, calling ntt_butterfly_block() for each block of butterflies. - ntt_butterfly_block() actually does the modular arithmetic. While this makes the loop-and-feel of the NTT rather different from what it was, structurally it is almost the same as in the reference implementation. Previously, the NTT code included a runtime check for the tighter bound 5*q for the output of the NTT. The bound and the check are removed in this commit: While they are still true, it is confusing to runtime check for a different value than what we are proving. Instead, a comment is left. Signed-off-by: Hanno Becker <[email protected]>
c246ad4
to
77ac5bc
Compare
#371 introduced a new macro ARRAY_ABS_BOUND for bounds that are centered around zero. This commit makes use of that macro everywhere. Resolves #379 Signed-off-by: Matthias J. Kannwischer <[email protected]>
#371 introduced a new ARRAY_ABS_BOUND macro which now has inconsistent naming with ARRAY_IN_BOUNDS. I propose to rename ARRAY_IN_BOUNDS to just ARRAY_BOUND for consistency. This commit renames the function and also moves the array that it operates on to be the first argument Signed-off-by: Matthias J. Kannwischer <[email protected]>
#371 introduced a new macro ARRAY_ABS_BOUND for bounds that are centered around zero. This commit makes use of that macro everywhere. Resolves #379 Signed-off-by: Matthias J. Kannwischer <[email protected]>
#371 introduced a new ARRAY_ABS_BOUND macro which now has inconsistent naming with ARRAY_IN_BOUNDS. I propose to rename ARRAY_IN_BOUNDS to just ARRAY_BOUND for consistency. This commit renames the function and also moves the array that it operates on to be the first argument Signed-off-by: Matthias J. Kannwischer <[email protected]>
#371 introduced a new ARRAY_ABS_BOUND macro which now has inconsistent naming with ARRAY_IN_BOUNDS. I propose to rename ARRAY_IN_BOUNDS to just ARRAY_BOUND for consistency. This commit renames the function and also moves the array that it operates on to be the first argument Signed-off-by: Matthias J. Kannwischer <[email protected]>
#371 introduced a new macro ARRAY_ABS_BOUND for bounds that are centered around zero. This commit makes use of that macro everywhere. Resolves #379 Signed-off-by: Matthias J. Kannwischer <[email protected]>
#371 introduced a new ARRAY_ABS_BOUND macro which now has inconsistent naming with ARRAY_IN_BOUNDS. I propose to rename ARRAY_IN_BOUNDS to just ARRAY_BOUND for consistency. This commit renames the function and also moves the array that it operates on to be the first argument Signed-off-by: Matthias J. Kannwischer <[email protected]>
#371 introduced a new ARRAY_ABS_BOUND macro which now has inconsistent naming with ARRAY_IN_BOUNDS. I propose to rename ARRAY_IN_BOUNDS to just ARRAY_BOUND for consistency. This commit renames the function and also moves the array that it operates on to be the first argument Signed-off-by: Matthias J. Kannwischer <[email protected]>
#371 introduced a new macro ARRAY_ABS_BOUND for bounds that are centered around zero. This commit makes use of that macro everywhere. Resolves #379 Signed-off-by: Matthias J. Kannwischer <[email protected]>
#371 introduced a new ARRAY_ABS_BOUND macro which now has inconsistent naming with ARRAY_IN_BOUNDS. I propose to rename ARRAY_IN_BOUNDS to just ARRAY_BOUND for consistency. This commit renames the function and also moves the array that it operates on to be the first argument Signed-off-by: Matthias J. Kannwischer <[email protected]>
#371 introduced a new macro ARRAY_ABS_BOUND for bounds that are centered around zero. This commit makes use of that macro everywhere. Resolves #379 Signed-off-by: Matthias J. Kannwischer <[email protected]>
#371 introduced a new ARRAY_ABS_BOUND macro which now has inconsistent naming with ARRAY_IN_BOUNDS. I propose to rename ARRAY_IN_BOUNDS to just ARRAY_BOUND for consistency. This commit renames the function and also moves the array that it operates on to be the first argument Signed-off-by: Matthias J. Kannwischer <[email protected]>
#371 introduced a new ARRAY_ABS_BOUND macro which now has inconsistent naming with ARRAY_IN_BOUNDS. I propose to rename ARRAY_IN_BOUNDS to just ARRAY_BOUND for consistency. This commit renames the function and also moves the array that it operates on to be the first argument Signed-off-by: Matthias J. Kannwischer <[email protected]>
#371 introduced a new macro ARRAY_ABS_BOUND for bounds that are centered around zero. This commit makes use of that macro everywhere. Resolves #379 Signed-off-by: Matthias J. Kannwischer <[email protected]>
#371 introduced a new ARRAY_ABS_BOUND macro which now has inconsistent naming with ARRAY_IN_BOUNDS. I propose to rename ARRAY_IN_BOUNDS to just ARRAY_BOUND for consistency. This commit renames the function and also moves the array that it operates on to be the first argument Signed-off-by: Matthias J. Kannwischer <[email protected]>
No description provided.