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.
seems like aeron does not care to zero out buffers, instead they rely on buffer reuse to overwrite the content on the next message: https://github.com/real-logic/aeron/issues/203#issuecomment-193467456
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.