cryptopp icon indicating copy to clipboard operation
cryptopp copied to clipboard

Custom allocators for VectorSink/VectorSource

Open mjmacleod opened this issue 4 years ago • 2 comments

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.

mjmacleod avatar Jun 08 '20 10:06 mjmacleod

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.

noloader avatar Jul 12 '20 10:07 noloader

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.

mjmacleod avatar Jul 12 '20 10:07 mjmacleod