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
seems like aeron does not care to zero out buffers, instead they rely on buffer reuse to overwrite the content on the next message: real-logic/aeron#203 (comment)
Though it could be possible to ensure this when using direct buffers. For server side we might not care about zeroing because we restrict access to the process/machine. For client side software it would be best to not store secrets that compromise the system anywhere. So attaching to the process or causing core dumps will not reveal any secrets. This can be done by using session keys only and techniques like SRP6 for passwordless key exchange.
Though we could still implement a mode into invesdwin-context-crypto where it can be opted in to zero buffers where keys were stored. So this can become a deployment decision (though the user could also manipulate the process to either disable this again or fetch the secrets via some other mechanism; e.g. jar manipulation or aspectj).
So currently it does not seem to be worth the effort and would cause a performance penalty if we zeroed everything after use.
The text was updated successfully, but these errors were encountered:
subes
changed the title
maybe zero our keys after use in buffers
maybe zero out keys after use in buffers
Aug 6, 2022
subes
changed the title
maybe zero out keys after use in buffers
maybe zero out buffers after use with keys
Aug 7, 2022
seems like aeron does not care to zero out buffers, instead they rely on buffer reuse to overwrite the content on the next message:
real-logic/aeron#203 (comment)
some concerns of this being wasted effort because the JVM copies around memory anyhow:
https://stackoverflow.com/questions/6473352/java-security-how-to-clear-zero-out-memory-associated-with-an-object-and-or-e
Though it could be possible to ensure this when using direct buffers. For server side we might not care about zeroing because we restrict access to the process/machine. For client side software it would be best to not store secrets that compromise the system anywhere. So attaching to the process or causing core dumps will not reveal any secrets. This can be done by using session keys only and techniques like SRP6 for passwordless key exchange.
Though we could still implement a mode into invesdwin-context-crypto where it can be opted in to zero buffers where keys were stored. So this can become a deployment decision (though the user could also manipulate the process to either disable this again or fetch the secrets via some other mechanism; e.g. jar manipulation or aspectj).
So currently it does not seem to be worth the effort and would cause a performance penalty if we zeroed everything after use.
The text was updated successfully, but these errors were encountered: