If I want to ensure that my secret keys and plaintext never get written out
to disk, I know that I should lock certain pages into memory. Certainly
doing a mlockall[1] will prevent plaintext from being paged to disk, but it
also locks my entire call stack and any libraries I use. For a
long-running process this could be very bad. mlock is more fine-grained,
and is the solution used by, e.g., GnuPG.

More specifically, I can construct an object which holds all my sensitive
cryptographic data (keys and plaintext) and mlock its contents. I also
need to mlock any scratch space I may need, say if I need to copy the
plaintext into another buffer before encrypting it.

But:
The encryption implementation I use (rijndael-alg-fst.c, for example) uses
a bunch of temporary variables (s0, s1, s2, s3, t0, t1, t2, t3) to contain
--- something. Initially the si contain plaintext xored with key material.
These are local, temporary variables, which means that they may be
allocated on the stack, and almost certainly means that they are not
allocated out of secure memory.

So:
Should I worry? Should I try to lock the appropriate hunk of stack?
Should I try to rewrite the algorithm so that it instead uses hunks of
secure storage? Or is the possibility that these temporary variables get
written out while containing useful data so negligible that I don't care?

Thanks,
Andrew

[1]All my examples are on Linux and other unix-like systems. Similar
approaches work for other systems with virtual memory. mlock locks a
region of memory into physical RAM; mlockall locks all the memory the
process uses into physical RAM.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]