> All internal exports: Zeroize XMM registers that may contain secret > data before returning. (At 4x pxors per cycle, the overhead is > negligible.) > > _ctr32: Zeroize $key0 and $ctr.
Question is why just aesni module? Why not everywhere? Why not demand that compiler does it too? Why just registers, and not stack too? The answer is that it doesn't make much sense, because the code you are trying to "protect" against resides in same process context and can read all the secrets from memory much more reliably than from registers or stack. I'm not saying that it makes no sense to clean up, only that *if* we do choose to do it, then it should be done for right reason and consistently. > (By the way, is OPENSSL_wipe_cpu used or tested anywhere?) No. For reference, the original idea was to seek opportunity to deploy it on border to libcrypto shared library, i.e. not upon return from some specific subroutines, but automatically upon any return from within libcrypto to application code. The idea was never realized though. The only case when it makes sense is when some other code called afterwards refers to register or ex-local variable used in libcrypto as uninitialized and unintentionally sends that data to another process or over network. Even then one can argue that it's that code vulnerability that should be fixed. It might make sense to use OPENSSL_wipe_cpu in specialized cases, when OpenSSL components are used in non-multi-task environment, but that would be something for specific developer to reason around and do. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
