[CI test, dontmerge] PR #1579 with secp256k1_memclear using volatile_memset #1622
pull theStack wants to merge 10 commits into bitcoin-core:master from theStack:revival_of_pr636_cleanse_CIRUN changing 22 files +106 −109-
theStack commented at 4:43 pm on October 22, 2024: contributorAs suggested in #1579 (review).
-
Don't clear secrets in pippenger implementation
This code is not supposed to handle secret data.
-
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.
-
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>
-
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>
-
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>
-
Implement various _clear() functions with secp256k1_memclear() 6507958b8a
-
Don't rely on memset to set signed integers to 0 68142a71b9
-
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.
-
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.
-
secp256k1_memclear: enforce variant using volatile_memset (for CI testing) dfb5f397e6
-
real-or-random commented at 8:08 pm on October 22, 2024: contributorOkay, 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.
-
real-or-random closed this on Oct 22, 2024
github-metadata-mirror
This is a metadata mirror of the GitHub repository bitcoin-core/secp256k1. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-03 19:15 UTC
This is a metadata mirror of the GitHub repository bitcoin-core/secp256k1. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-03 19:15 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me
More mirrored repositories can be found on mirror.b10c.me