On Friday, Feb 28, 2003, at 00:50 US/Eastern, Jeroen C. van Gelderen wrote:You are going trough a lot of trouble. What is your threat model?
Incidentally, the correct and portable (modulo compiler bugs) approach at the language level is to mark the array volatile. This means that stores to the array cannot be optimized out and neither can function calls to functions in which a volatile variable is manipulated (this is transitive).
Now see, I've known about volatile since about 1985. It's just that all these cryptography books make such a big show and hoopla about zeroing out memory. Even the GnuPG code does the 'burn_stack' thing, which was shown on the DBS list to be vulnerable.
So I figured the volatile feature must be horribly unreliable. I guess I'll just have to check the assembler output from gcc to make sure.
You will still have to disable caching and swapping at the OS (and maybe the hardware) level to make sure no copies linger around.
Yes, I do intend to use mlock and munlock for that.
As for my threat model, I'm just thinking I need to make it as reliable as possible even without a dedicated server. I only need the ability to lock, use, wash, and unlock a single memory page.
Today is my day to spend a few hours on the "washing" part. :-)
And in some cases (again, what is your threat model?), you will want to overwrite your data with random bytes because overwriting with zeroes makes offline forensics easier.
This thought did cross my mind, and I considered running Rijndael itself to wash out the memory.
In one implementation, I have written the three routines (keysched, encrypt, and decrypt) so they declare NO internal stack variables whatsoever. Any scratchpad memory must be declared outside and a pointer passed into the routine.
So after doing my primary crypto operation using Rijndael, I would then wash out the key and key schedule memory using an application of Rijndael itself. I would perhaps seed this process occasionally and chain it.
So do you think I should use Rijndael itself to wash out this data?
Regards, Patrick
