You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Merge #1579: Clear sensitive memory without getting optimized out (revival of #636)
765ef53 Clear _gej instances after point multiplication to avoid potential leaks (Sebastian Falbesoner)
349e6ab Introduce separate _clear functions for hash module (Tim Ruffing)
99cc9fd Don't rely on memset to set signed integers to 0 (Tim Ruffing)
97c57f4 Implement various _clear() functions with secp256k1_memclear() (Tim Ruffing)
9bb368d Use secp256k1_memclear() to clear stack memory instead of memset() (Tim Ruffing)
e3497bb Separate between clearing memory and setting to zero in tests (Tim Ruffing)
d79a6cc Separate secp256k1_fe_set_int( . , 0 ) from secp256k1_fe_clear() (Tim Ruffing)
1c08126 Add secp256k1_memclear() for clearing secret data (Tim Ruffing)
e7d3844 Don't clear secrets in pippenger implementation (Tim Ruffing)
Pull request description:
This PR picks up #636 (which in turn picked up #448, so this is take number three) and is essentially a rebase on master.
Some changes to the original PR:
* the clearing function now has the `secp256k1_` prefix again, since the related helper `_memczero` got it as well (see PR #835 / commit e89278f)
* the original commit b17a7df ("Make _set_fe_int( . , 0 ) set magnitude to 0") is not needed anymore, since it was already applied in PR #943 (commit d49011f)
* clearing of stack memory with `secp256k1_memclear` is now also done on modules that have been newly introduced since then, i.e. schnorr and ellswift (of course, there is still no guarantee that all places where clearing is necessary are covered)
So far I haven't looked at any disassembly and possible performance implications yet (there were some concerns expressed in #636 (comment)), happy to go deeper there if this gets Concept ACKed.
The proposed method of using a memory barrier to prevent optimizating away the memset is still used in BoringSSL (where it was originally picked up from) and in the Linux Kernel, see e.g. https://github.com/google/boringssl/blob/5af122c3dfc163b5d1859f1f450756e8e320a142/crypto/mem.c#L335 and https://github.com/torvalds/linux/blob/d4560686726f7a357922f300fc81f5964be8df04/include/linux/string.h#L348 / https://github.com/torvalds/linux/blob/d4560686726f7a357922f300fc81f5964be8df04/include/linux/compiler.h#L102Fixes#185.
ACKs for top commit:
sipa:
reACK 765ef53
real-or-random:
ACK 765ef53
Tree-SHA512: 5a034d5ad14178c06928022459f3d4f0877d06f576b24ab07b86b3608b0b3e9273217b8309a1db606f024f3032731f13013114b1e0828964b578814d1efb2959
0 commit comments