weidai11 / cryptopp

free C++ class library of cryptographic schemes
https://cryptopp.com
Other
4.89k stars 1.51k forks source link

Custom allocators for VectorSink/VectorSource #953

Open mjmacleod opened 4 years ago

mjmacleod commented 4 years ago

VectorSource and/or VectorSink cannot compile when passed a vector that takes a custom allocator. In my case I have a codebase that uses a secure allocator for all sensitive information and have to re-implement parts of the cryptopp codebase due to VectorSource/VectorSink not taking an allocator.

VectorSink is just a typedef so this is easily worked around in user code by just using CryptoPP::StringSinkTemplate<MyType>

VectorSource is an actual class (though quite a simple one) so has to be 'duplicated' into my codebase e.g.:

template <typename T> class CryptoVectorSource : public CryptoPP::SourceTemplate<CryptoPP::StringStore>
{
public:
    CryptoVectorSource(BufferedTransformation *attachment = NULLPTR)
        : SourceTemplate<CryptoPP::StringStore>(attachment) {}
    CryptoVectorSource(const T &vec, bool pumpAll, BufferedTransformation *attachment = NULLPTR)
        : SourceTemplate<CryptoPP::StringStore>(attachment) {SourceInitialize(pumpAll, MakeParameters("InputBuffer", CryptoPP::ConstByteArrayParameter(vec)));}
};

This is not ideal, because I then have to check that this doesn't break for every library upgrade. It would be preferable if VectorSource were just templated inside cryptopp itself such that it can take any allocator. It would also be nice (but not as important) if VectorSink could do the same.

noloader commented 4 years ago

VectorSource and/or VectorSink cannot compile when passed a vector that takes a custom allocator. In my case I have a codebase that uses a secure allocator for all sensitive information...

In your use case, you should probably use a SecBlock<MyType>. The SecBlock<T> class uses a secure allocator and provides the cleanup.

mjmacleod commented 4 years ago

I'm not really sure there is much to gain on my side from switching to SecBlock it behaves essentially the same as the codebases existing securely allocated vector/string classes and would only serve to make the codebase more tightly coupled to cryptopp instead if the dependency being smaller. The codebases securely allocated classes are also used in various other places that otherwise have absolutely no relation to cryptopp... However I will think about it some more, thanks.

That aside, I still think it would be ideal (and a very small change) to modify VectorSource/VectorSink to alllow for custom allocators.