Ron Teitelbaum made a clever solution to resisting memory-scanning attacks when using private keys in an image.�� Upon asking��KeyHolder holdKey: yourPrivateKey, it forks off a while loop which generates a random sequence of bytes (ByteArray) to encrypt yourPrivateKey with it.�� It then delays 100ms, decrypts the key and immediately re-encrypts it with a new set of random bytes (two new memory locations), and wiping the old random and old key ByteArray's.�� Repeat.

The result: a memory-scanner attack needs to find both pieces of information (the random number and the encrypted key) in the image memory within 100ms.�� Obviously this consumes some processing power and garbage collection, but it's not noticeable.�� On shutdown, all instances are automatically wiped,��saved images are clean of private keys.

It's part of the CryptographyCore package on SqueakSource.

http://www.squeaksource.com/Cryptography/CryptographyCore-cmm.9.mcz

On Tue, Sep 20, 2022 at 9:59 AM <sean@clipperadams.com> wrote:

I feel compelled to revive this old (almost 10 years!) thread because I���m faced with a similar problem and certain points seem unresolved.

Assuming that one needs the actual password in the image (in my case to authenticate via IMAP), Norbert���s suggestion to have a helper app that runs with elevated privileges makes sense, but I���m wondering about a few other comments:

As I was thinking through my use case, I was considering, for example, storing the password in a non-string collection e.g. ByteArray, so that I could use the password and zero it out in memory right afterward.