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.

Sign up for GitHub

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

Jump to bottom

Clear sensitive memory without getting optimized out (revival of #636) #1579

Open
wants to merge 8 commits into
base: master
Choose a base branch
from
Open

Clear sensitive memory without getting optimized out (revival of #636) #1579

wants to merge 8 commits into from

Commits on Aug 20, 2024

  1. Don't clear secrets in pippenger implementation 

    This code is not supposed to handle secret data.
    @real-or-random @theStack
    real-or-random authored and theStack committed Aug 20, 2024
    Configuration menu
    Copy the full SHA
    412a82f View commit details
    Browse the repository at this point in the history

  2. Add secp256k1_memclear() for clearing secret data 

    We rely on memset() and an __asm__ memory barrier where it's available or
on SecureZeroMemory() on Windows. The fallback implementation uses a
volatile function pointer to memset which the compiler is not clever
enough to optimize.
    @real-or-random @theStack
    real-or-random authored and theStack committed Aug 20, 2024
    Configuration menu
    Copy the full SHA
    3818a68 View commit details
    Browse the repository at this point in the history

  3. Separate secp256k1_fe_set_int( . , 0 ) from secp256k1_fe_clear() 

    There are two uses of the secp256k1_fe_clear() function that are now separated
into these two functions in order to reflect the intent:

1) initializing the memory prior to being used -> converted to fe_set_int( . , 0 )
2) zeroing the memory after being used such that no sensitive data remains. ->
    remains as fe_clear()

In the latter case, 'magnitude' and 'normalized' need to be overwritten when
VERIFY is enabled.

Co-Authored-By: isle2983 <isle2983@yahoo.com>
    @real-or-random @isle2983 @theStack
    2 people authored and theStack committed Aug 20, 2024
    Configuration menu
    Copy the full SHA
    7a59878 View commit details
    Browse the repository at this point in the history

  4. Separate between clearing memory and setting to zero in tests 

    Co-Authored-By: isle2983 <isle2983@yahoo.com>
Co-Authored-By: Pieter Wuille <pieter.wuille@gmail.com>
    @real-or-random @isle2983
    @sipa @theStack
    3 people authored and theStack committed Aug 20, 2024
    Configuration menu
    Copy the full SHA
    15e8cdd View commit details
    Browse the repository at this point in the history

  5. Use secp256k1_memclear() to clear stack memory instead of memset() 

    All of the invocations of secp256k1_memclear() operate on stack
memory and happen after the function is done with the memory object.
This commit replaces existing memset() invocations and also adds
secp256k1_memclear() to code locations where clearing was missing;
there is no guarantee that this commit covers all code locations
where clearing is necessary.

Co-Authored-By: isle2983 <isle2983@yahoo.com>
    @real-or-random @isle2983 @theStack
    2 people authored and theStack committed Aug 20, 2024
    Configuration menu
    Copy the full SHA
    6fcbae9 View commit details
    Browse the repository at this point in the history

  6. Implement various _clear() functions with secp256k1_memclear()

    @real-or-random @theStack
    real-or-random authored and theStack committed Aug 20, 2024
    Configuration menu
    Copy the full SHA
    c65befc View commit details
    Browse the repository at this point in the history

  7. Don't rely on memset to set signed integers to 0

    @real-or-random @theStack
    real-or-random authored and theStack committed Aug 20, 2024
    Configuration menu
    Copy the full SHA
    9afa068 View commit details
    Browse the repository at this point in the history

  8. Introduce separate _clear functions for hash module 

    This gives the caller more control about whether the state should
be cleaned (= should be considered secret), which will be useful
for example for Schnorr signature verification in the future.
Moreover, it gives the caller the possibility to clean a hash struct
without finalizing it.
    @real-or-random @theStack
    real-or-random authored and theStack committed Aug 20, 2024
    Configuration menu
    Copy the full SHA
    ac0e41b View commit details
    Browse the repository at this point in the history