Just says "See MyHush/SilentDragon#144" which brings us to further explanation of this issue.
Ported from [issue #4 on GitHub](https://github.com/MyHush/SilentDragonWormhole/issues/4)
Just says "See [MyHush/SilentDragon#144](https://github.com/MyHush/SilentDragon/issues/144)" which brings us to further explanation of this issue.
This is hard issue, that likely requires many changes. But it's important and worthwhile to reduce our attack surface. In general, whenever we are done with any type of sensitive information (public keys, private keys, hex codes for websocket encryption, etc), we should set the memory to zero.
This defensive programming will help in a situation where some type of memory corruption or Virtual Machine exploit is being used, and potentially one user on a physical server is trying to read the memory from another user on the same physical server (but maybe different VM).
Since our full node would also need to do this to be really effective, this is a nice-to-have but is not critical for SD. This task is more valuable for SilentDragonLite + SilentDragonAndroid, since no full node is running on the same computer there, and these security practices actually have a large improvement in safety. /cc @DenioD
In case Github goes away, here is the full details of the issue:
TOB-ZEC-022 from https://github.com/trailofbits/publications/blob/master/reviews/zecwallet.pdf
This is hard issue, that likely requires many changes. But it's important and worthwhile to reduce our attack surface. In general, whenever we are done with any type of sensitive information (public keys, private keys, hex codes for websocket encryption, etc), we should set the memory to zero.
This defensive programming will help in a situation where some type of memory corruption or Virtual Machine exploit is being used, and potentially one user on a physical server is trying to read the memory from another user on the same physical server (but maybe different VM).
Since our full node would also need to do this to be really effective, this is a nice-to-have but is not critical for SD. This task is more valuable for SilentDragonLite + SilentDragonAndroid, since no full node is running on the same computer there, and these security practices actually have a large improvement in safety. /cc @DenioD
Ported from issue #4 on GitHub
Just says "See MyHush/SilentDragon#144" which brings us to further explanation of this issue.
In case Github goes away, here is the full details of the issue:
TOB-ZEC-022 from https://github.com/trailofbits/publications/blob/master/reviews/zecwallet.pdf
This is hard issue, that likely requires many changes. But it's important and worthwhile to reduce our attack surface. In general, whenever we are done with any type of sensitive information (public keys, private keys, hex codes for websocket encryption, etc), we should set the memory to zero.
This defensive programming will help in a situation where some type of memory corruption or Virtual Machine exploit is being used, and potentially one user on a physical server is trying to read the memory from another user on the same physical server (but maybe different VM).
Since our full node would also need to do this to be really effective, this is a nice-to-have but is not critical for SD. This task is more valuable for SilentDragonLite + SilentDragonAndroid, since no full node is running on the same computer there, and these security practices actually have a large improvement in safety. /cc @DenioD