[CI test, dontmerge] PR #1579 with secp256k1_memclear using volatile_memset #1622

1. 
   theStack commented at 4:43 pm on October 22, 2024: contributor

   As suggested in #1579 (review).
2. Don't clear secrets in pippenger implementation

   This code is not supposed to handle secret data.

   e7d384488e
3. 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.

   e1b377f028
4. 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>

   3e5ecf55ca
5. 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>

   7c4152c0b2
6. 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>

   5665f086f9
7. Implement various _clear() functions with secp256k1_memclear() 6507958b8a
8. Don't rely on memset to set signed integers to 0 68142a71b9
9. Introduce separate _clear functions for hash module

   This gives the caller more control about whether the state should
   be cleaned (= should be considered secret). Moreover, it gives the
   caller the possibility to clean a hash struct without finalizing it.

   c5299e91fd
10. Clear _gej instances after point multiplication to avoid potential leaks

    Quoting sipa (see https://github.com/bitcoin-core/secp256k1/pull/1479#discussion_r1790079414):
    "When performing an EC multiplication A = aG for secret a, the resulting
     _affine_ coordinates of A are presumed to not leak information about a (ECDLP),
      but the same is not necessarily true for the Jacobian coordinates that come
      out of our multiplication algorithm."
    
    For the ECDH point multiplication result, the result in Jacobi coordinates should be
    cleared not only to avoid leaking the scalar, but even more so as it's a representation
    of the resulting shared secret.

    b942b9f70a
11. secp256k1_memclear: enforce variant using volatile_memset (for CI testing) dfb5f397e6
12. 
    real-or-random commented at 8:08 pm on October 22, 2024: contributor

    Okay, awesome CI seems to like this. Let me close this PR, I think this is a sufficient test for this #if branch, even if further small changes will be made to #1579.
13. real-or-random closed this on Oct 22, 2024

    ---

Contributors
theStack real-or-random