Hello Kasra and thanks for your interest in the crypto library,
I have looked at the current state of the crypto namespace. The current code is not really modular so I propose the following new/modified features:
I contest that statement, it is in fact quite modular, you are merely adding abstract base classes to impose an interface for the different models which is not necessary when using templates to compose objects.
wipe algorithms that are used to wipe streams/buffers with specified patterns i.e. Gutmann wipe algorithm secure allocator would use a default wipe algorithm i.e. all zero for wipe of buffers.
Okay, wipe algorithms are interesting but I don't see added value in clearing memory to zeros vs clearing the memory with some other pattern or random data. For current RAM technologies the original data is destroyed with a simple memset to zero.
namespace boost { namespace crypto {
template < ... > class block_cipher // abstract class for ALL block ciphers to inherit from { public: virtual void setkey(...) = 0; virtual void encrypt(...) = 0; virtual void decrypt(...) = 0; };
How is that better than template<class Cipher, class Mode, class Padding> struct block_cipher; ?
template < class cipher > class basic_crypto_stream : public std::basic_ios <...>
I think that's a good idea.
the AES (Rijndael) uses a very slow code, the speed could be increases by up to a factor of 5 if pre-computed s-box tables are used, this would cause for an increase of ~4KB in the class size, however, i think the speed penalties are to high for the current implementation.
I am interested in that optimization, I have deliberately chosen the 'slower' variant as it follows the original paper more closely and made it a little easier for me to implement. I would like to see benchmarks of this variant. Btw, I don't remember if the version in the vault has copyright tags but it is available as public domain code from me. Kevin