Re: Wash the key, don't clear it

[gabriel rosenkoetter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Feb 28, 2003 at 01:49:34AM -0500, Patrick Chkoreff wrote:
 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.

volatile must, by definition work correctly, and it really does mean
don't touch this code you bastard optimizer.

As Perry Metzger pointed out over on his cryptography list when this
came up several months ago, the basic device drivers running your
computer wouldn't work if volatile wouldn't work because there are
situations where you MUST read something from a hardware address
and discard the output in order to trigger the device to take some
certain action. That device's specs are completely outside the ken
of the compiler, which is why we have volatile.

If it doesn't work in your compiler, your compiler is broken by
design.

- -- 
gabriel rosenkoetter
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (NetBSD)

iD8DBQE+X23D9ehacAz5CRoRAnI4AJ9PtTpOxRXyN2MvJgnrj+MoSmMYKwCfXWhf
fSB9Kqh1hjBiCUC6euQOz9U=
=QgBZ
-END PGP SIGNATURE-

Wash the key, don't clear it

[Patrick Chkoreff]

On Friday, February 28, 2003, at 01:03 AM, Jeroen C. van Gelderen wrote:

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