On 7/21/06, Richard Salz <[EMAIL PROTECTED]> wrote:
> I guess I'm trying to look at this from a "guarantee-of-parameter",
> "operation", "guarantee of output integrity" contract-based
> programming view.
It might make more sense to do this with C++ classes built on top of the C
API. If you had a common base class with void*,size_t, and then defined
all the appropriate subclasses, the calls to openssl would be inlined and
close to zero runtime cost.
Considering that it's not the C++ class that's relying on nor
generating the data, it's not particularly appropriate for the C++
class to be able to manage the contract of data exported by the
OpenSSL API when that data could already be corrupted by something
that occurred inside OpenSSL.
> (Among other things, this could allow blobs of data
> to flow freely into and out of the FIPS core, given structure magic
> numbers and such.)
How so?
As an example, if the FIPS core only exports APIs that guarantee that
keys are encrypted when any data about them is exported, then it would
be a software mechanism to prevent a violation of the security policy
(exportation and importation of unencrypted secret/private keying
material). If a key blob is marked unencrypted, it goes through an
encryption process before it's exported, period.
If OpenSSL kept track of the data it was being asked to manipulate [as
it already does, to an extent, with the ALLOW_MOVING_WRITE_BUFFER], it
would make it a lot easier to ensure that assumptions made in the
design and development of OpenSSL would not be violated by someone
trying to use the library in a manner that hasn't been tested and
isn't supported.
Cheers,
-Kyle H
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
