|
Boost : |
Subject: Re: [boost] [xint] Boost.XInt formal review
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2011-03-10 20:05:56
On Thu, Mar 10, 2011 at 16:24, Chad Nelson <chad.thecomfychair_at_[hidden]> wrote:
> On Thu, 10 Mar 2011 09:15:28 -0800
> Scott McMurray <me22.ca+boost_at_[hidden]> wrote:
>>
>> Can you elaborate on why someone would want to clear the memory, but
>> not want to actually be secure?
>>
>
> Barring extremely sensitive information like government-level secrets,
> there are generally only two things that a developer needs to worry
> about: that sensitive data might be written to disk by the OS, and that
> it might be retrieved from memory, either by malware while the machine
> is running or by physical means immediately after removing power.
>
I think that makes a flawed assumption that the secret information
will only reside in the one place in memory, and never be copied
elsewhere.
Clearing the memory from the bigint doesn't help when iostream cached
the bytes of the file from which it was read, nor does it protect the
information that the NIH implementation of RSA was used to decrypt.
Any useful attempt at security will involve more than a single number,
so any number that wants to be used securely should have a way to hook
into an existing system. An allocator might be a reasonable way to do
this, since it could handle clearing, telling the OS not to swap the
memory, or whatever the user decides is important enough, and be
applied to the xint, to the vector used in a custom streambuf, etc.
Still, I think that the idea of even implying that doing home-grown
security is an acceptable idea is a terrible one. Even if someone
doesn't need NSA-resistent security, why would doing custom RSA with a
big number library ever be a better idea than using a proper crypto
toolkit?
~ Scott
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk