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
One problem is we use *_vartime if any of the parameters lead to variable-time behavior, however often in practice we will call these *_vartime methods on a secret input but where they're variable-time only with respect to an rhs parameter which is fixed/constant, generally noting the overall result is constant-time with a comment.
Some algorithms have vartime components on non-secret data requiring associated use of vartime functionality.
e.g. where the vartime use is associated with non-secret dependant data.
This could be treated similarly to Rust borrow checker and
unsafe { .. }
Marking data as VarTime safe - e.g. hinting it's public could be done via a macro:
Then in functions guard input to vartime functions via the generated wrapper
VarTime<PublicData>
typeThis would enable borrow check type static analysis - ctgrind but in static - so that secret data does not end up in vartime.
I've also looked into doing static analysis off MIR for CI check but having type-level guardrails could help safety.
Also we can enable check to ensure no use of "vartime safety undocumented" vartime gets undocumented.
Relevant Cryptography
Even
modulus #590 with RSA Even GCD where Even mod-1 is usedPrior art
Dudect requires carefully crafted datasets (I adapted rozbb's vec eq example to ct/vartime memcmp) to illustrate.
The text was updated successfully, but these errors were encountered: