|
Boost : |
From: Kevin Sopp (baraclese_at_[hidden])
Date: 2008-06-20 06:15:57
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk