[Botan-devel] RFC: memory locking

[Jack Lloyd]

On Tue, Nov 13, 2007 at 08:32:19AM +0000, Nathaniel Smith wrote:

> Arguably, "any time crypto code actually handles valuable secrets".
> Data exposure via swap is a very plausible attack, though not one that
> most of us have to worry about in practice, esp. since our "secrets"
> are pretty lame.  Of course, the people who do care about this
> probably should use encrypted swap, but hey, crypto's effectiveness or
> lack thereof is completely invisible to most users most of the time,
> so it's sort of our job as developers to worry about the stupid edge
> cases for them...
>
> The other reason, of course, is that people will look at Botan, see it
> doesn't have this feature which they consider critical, and sigh and
> decide they'll just have to use Crypto++ instead, warts and all.
> Whether that's a sane reason or not doesn't necessarily matter.

The problem is that this memory locking doesn't really do what is
advertised or what a naive user might think. For instance, we do
absolutely nothing to lock I/O buffers in memory (and since typically
we are just passed iostreams opened by the application, the library
would have a pretty hard time doing that anyway).

I'm not sure if it's better to do a half-assed job that seems to be OK
(but maybe isn't) or explicitly tell people the library does not
protect them against this and that they will have to take other
countermeasures if it is a concern for their system. VFS caps+mlockall
and/or encrypted swap seem to be a much more effective solution than
any locking scheme I have seen or can think of, but, of course, pushes
some of the implementation cost onto application developers and/or
users.

FWIW Crypto++ does not seem to support any locking, just zeroization;
and I'm not suggesting that functionality be removed from Botan.

-Jack