Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It's a good security practice to wipe out sensitive data from memory once it's no longer needed. Straightforward approach to this is to call
memset(data, 0, size)
before freeing the keys or something. However, compilers often optimize memset() implementation and end up optimizing out that call completely since they see that the data is freed. We can prevent that.Add a utility function to securely wipe memory region. We have quite a few places in our code where this can be useful, and it's a good function to export for the users (of Soter).
It's implemented via
OPENSSL_cleanse()
function on both OpenSSL and BoringSSL. That's an old function available since OpenSSL 1.0.2 so we should not run into any compatibility issues (and we do recommend using latest OpenSSL anyway).Note that it intentionally accepts
void*
, notuint8_t*
(just like free() does). Implicit cast is expected here and allow wiping any object without warnings from compiler.Replace ad-hoc memset() calls with soter_wipe(). This ensures that these calls will not be optimized out by the compiler in release build mode.