-
Notifications
You must be signed in to change notification settings - Fork 147
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
Pipe through carry_add function #1635
Conversation
Hm. Tried to reproduce the failed CI checks locally by running
which I could reproduce on my main branch without these changes (see issue #1636). |
Try |
@@ -758,6 +758,7 @@ Definition field_parameters_prefixed | |||
M_pos a24 | |||
(prefix ++ "mul") | |||
(prefix ++ "add") | |||
(prefix ++ "carry_add_dontuse") |
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.
Why "dontuse"?
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.
I think this is because there isn't a particularly satisfying implementation of this function in montgomery domain. Having it be an alias for add would be fine, though. (We could consider calling this function "add", and the other one "add_limbwise" or "unreduced_add" or "unsafe_add"...)
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.
Correct, there's no existing implementation; and in fact, the existing add
function in Montgomery already guarantees tight_bounds
, so it doesn't look like there would be any benefit to the carry_add
function.
However, as an unfortunate consequence of the way FieldParameters is defined right now, any function in the spec must be defined (or "defined" by just providing an arbitrary string) everywhere that uses the spec, even if it's not needed.
(See for example fe1305_scmul1_dontuse
in RupicolaCrypto/Low.v.)
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.
What I said about Montgomery add
guaranteeing tight_bounds
isn't really accurate; I was misremembering. But it guarantees montgomery_domain_bounds
, i.e. that the result is in the Montgomery domain, which I think is analogous?
fiat-crypto/src/PushButtonSynthesis/WordByWordMontgomery.v
Lines 319 to 326 in 63a6ba4
Definition add | |
:= Pipeline.BoundsPipeline | |
true (* subst01 *) | |
possible_values | |
(reified_add_gen | |
@ GallinaReify.Reify (machine_wordsize:Z) @ GallinaReify.Reify n @ GallinaReify.Reify m) | |
(Some montgomery_domain_bounds, (Some montgomery_domain_bounds, tt)) | |
(Some montgomery_domain_bounds). |
Head branch was pushed to by a user without write access
That worked :) I was able to reproduce the failed CI and pushed a couple fixes. Re-running CI now 🤞 |
carry_add
has tighter bounds on the results than the basicadd
function. The source already exists in PushButtonSynthesis. This defines & specs the function in Field.v, proves the correctness of the existing source relative to that spec, and then derives the Field25519 and Field1305 versions.A later PR will replace the mul-by-2 in #1622 with
carry_add
instead.