You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should have a naming convention for function arguments that are considered secret by the function (w.r.t to the side channels). This could for example be a prefix, a suffix, or uppercase.
This will be helpful as documentation for the API functions at least.
I'm not sure if it's worth the hassle for the internal functions. Clearer docs certainly won't hurt, but our constant-time tests should catch any violation of secrecy constraints (if nicely documented or not).
The text was updated successfully, but these errors were encountered:
This seems like a good idea, as we do have both internal and external API functions that are only constant-time in some subset of the inputs.
One perhaps rather small point: functions can be constant-time or non-constant-time in their output too. E.g. an ECDH function that first computes a point multiplication (constant time in both its point and scalar argument) and then applies a variable-time hashing algorithm on its output. This may or may not be fine if the output of the function is not used as a secret-to-be-protected. Should that too be encoded in the naming somehow?
We should have a naming convention for function arguments that are considered secret by the function (w.r.t to the side channels). This could for example be a prefix, a suffix, or uppercase.
This will be helpful as documentation for the API functions at least.
I'm not sure if it's worth the hassle for the internal functions. Clearer docs certainly won't hurt, but our constant-time tests should catch any violation of secrecy constraints (if nicely documented or not).
The text was updated successfully, but these errors were encountered: