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

curve: use subtle::BlackBox optimization barrier #662

Merged
merged 1 commit into from
Jun 24, 2024
Merged

Commits on Jun 24, 2024

  1. curve: use subtle::BlackBox optimization barrier

    Replaces the security mitigation added in #659 and #661 for
    masking-related timing variability which used an inline `black_box`
    using the recently added `subtle::BlackBox` newtype (see
    dalek-cryptography/subtle#123)
    
    Internally `BlackBox` uses a volatile read by default (i.e. same
    strategy which was used before) or when the `core_hint_black_box`
    feature of `subtle` is enabled, it uses `core::hint::black_box`
    (whose documentation was recently updated to reflect the nuances of
    potential cryptographic use, see rust-lang/rust#126703)
    
    This PR goes ahead and uses `BlackBox` for both `mask` and
    `underflow_mask` where previously it was only used on `underflow_mask`.
    The general pattern of bitwise masking inside a loop seems worrisome for
    the optimizer potentially inserting branches in the future.
    
    Below are godbolt inspections of the generated assembly, which are free
    of the `jns` instructions originally spotted in #659/#661:
    
    - 32-bit (read_volatile): https://godbolt.org/z/TKo9fqza4
    - 32-bit (hint::black_box): https://godbolt.org/z/caoMxYbET
    - 64-bit (read_volatile): https://godbolt.org/z/PM6zKjj1f
    - 64-bit (hint::black_box): https://godbolt.org/z/nseaPvdWv
    tarcieri committed Jun 24, 2024
    Configuration menu
    Copy the full SHA
    b4a374c View commit details
    Browse the repository at this point in the history