I forgot to mention I don't want to say that we will have base classes with virtual stuff, because that is expensive, however, what I wanted to point is that there must be an interface "template" so when one wants to add more block_cipher, ciphers and etc, one should know which functions should be available as public. The base class code is merely for documentation purposes only!
The constraints the type must satisfy to work as template parameter for some template is called the model. All models should be described in the documentation.
Check this one out: http://citp.princeton.edu/memory/
I knew about this one. The link seems to be down right now. Dumping the memory to disk after a reboot isn't going to be helped with complex wipe algorithms. Clearing the memory with zeros will protect against that, unless you are able to shutdown the machine right before that function is called.
But when we have wipe algorithms we could hook them to fstreams and there is it! We will wipe a file which as you know is quiet important when you want to get rid of the data!
It doesn't really make sense to hook this up to an fstream. Such a remove_file_securely() functionality should be implemented as free function.
I told you about the idea of "cipher". So a block_cipher only encrypt/decrypts blocks and that is as far as it stretches (including key schedules etc). However, a cipher would encrypt any arbitary length of message. The modes of operation would have some thing like:
template < class block_cipher, class padding > class mode_of_operation { . . . };
which turns a block_cipher concept into a "cipher"; that could encrypt any arbitary message length. So that is why I thought we could changed it.
Well there are two classes of ciphers, block ciphers and stream ciphers. Block ciphers encrypt data by working on x bytes at a time. Stream ciphers on the other hand (like RC4) encrypt data continuously and don't need a padding parameter because they don't need to pad data to a multiple of some block size. So what you call a cipher is a stream cipher. I see now where you're going with this and I will think about it.
"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."
I am NOT going to write this variant since "Paulo Barreto"; which is THE EXPERT, he has written the optimized version (http://www.iaik.tugraz.at/Research/krypto/AES/old/~rijmen/rijndael/rijndael-...). So I would only create a wrapper for the functions :D.
I remember that table lookups generally are susceptible to cache timing attacks. That does not mean we shouldn't use the optimized rijndael version though.
Since I have been active in the field I know of most of the optimized implementations, so we only need to write wrappers for them.
However I am rather busy for two weeks, so this is probably the last e-mail which I will sent in two weeks time :(
no problem. Kevin