Skip to content
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

vartime Safety - guardrails & static analysis by design #592

Open
pinkforest opened this issue Apr 6, 2024 · 1 comment
Open

vartime Safety - guardrails & static analysis by design #592

pinkforest opened this issue Apr 6, 2024 · 1 comment

Comments

@pinkforest
Copy link

pinkforest commented Apr 6, 2024

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:

#[vartime(public)]
pub struct PublicData {
  pub(crate) public_field: SomeOtherData,
}

Then in functions guard input to vartime functions via the generated wrapper VarTime<PublicData> type

/// VARTIME SAFETY: PublicData is not secret
#[vartime_guard]
pub fn some_vartime_thing(VarTime<PublicData>, SecretData) { .. }

This 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

Prior art

Dudect requires carefully crafted datasets (I adapted rozbb's vec eq example to ct/vartime memcmp) to illustrate.

@tarcieri
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants