[Owasp-esapi-c++] ESAPI and Secure storage, allocation, and deletion

[Jeffrey Walton]

Hi All,

https://code.google.com/p/owasp-esapi-cplusplus/source/browse/trunk/esapi/crypto/SecureRandom.h
https://code.google.com/p/owasp-esapi-cplusplus/source/browse/trunk/src/crypto/SecureRandom.cpp
https://code.google.com/p/owasp-esapi-cplusplus/source/browse/trunk/esapi/crypto/SecretKey.h

********************

 The C++ dialect of Java's constructors are:

    // Create an instance PRNG with a seed.
    explicit SecureRandom(const byte* seed, size_t size);

    // Create an instance PRNG with a seed.
    explicit SecureRandom(const std::vector<byte>& seed);

Neither method accepts a container with secure storage. I believe we
need the byte* variant for accepting 'raw' data from users. But the
safe version using a vector does not provide a secure allocation which
zeroizes on deletion. So when the user's vector is destroyed, secret
values might linger in memory. Its not secure, and not FIPS compliant
(zeorization must occur even at FIPS level 1).

The problem is highlighted with SecureRandom's nextBytes():

    // Generates a user-specified number of random bytes.
    void nextBytes(std::vector<byte>& bytes);

In nextBytes(), we have pigeon-holed the user into using an insecure
container when using STL for safety.

A nastier problem exists in SecretKey and friends. The user must
accept a bye array only - not {byte,len} - from getEncoded():

    /**
     * Returns the key in its primary encoding format, or nullptr
     * if this key does not support encoding.
     */
    virtual const byte* getEncoded() const;

********************

I believe the project needs to provide a secure, random access,
sequence container with copy semantics. I believe we can build upon
the STL containers, since they allow us to provide an allocator:
  * string (basic_string): http://www.sgi.com/tech/stl/basic_string.html
  * vector: http://www.sgi.com/tech/stl/Vector.html

Conceptually, I think vector is closest to what we need. However,
vector does not allow for copying out of the box. basic_string is
copyable, but it carries excess baggage due to locales and facets for
language functionality such as searching.

Any thoughts?

Jeff