I am back from being busy => I am free. I have thought about the design decisions: "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 disagree, say you have a file 'x' which you don't want the local police to be able to recover, and you have a 'xx' file which you don't want the FBI to be able to recover (a little too hard to achieve). Here the security differs, and thus the wipe method ought to be different. secure_wipe< aStream, onePassAlgorithm > x; // single overwrite secure_wipe< aStream, gutmannAlgorithm > xx; // 35 x overwrite "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. " In general blocks cipher is an element of stream cipher which in turn is an element of cipher set. So I guess the terminology doesn't bother me much. But I think you know where I am coming from now. "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." I totally agree with you, the cache-timing attack is believed to be impossible on more than 1 network loop. I have written the wrapper class for the optimised implementation. Conclusion: All of us like: * basic_crypto_stream. * optimised implementations Haven't agreed on yet but are thinking in the same lines: * block_cipher, stream_cipher, cipher thing Disagree on: * secure_wipe I agree 'secure_wipe' is not very useful for a memory buffer. A secure allocator works fine (i.e. memset() ). But on the other hand when it comes to files 'secure_wipe' is very useful. So we need to agree on the interface which the 'secure_wipe' task is achieved. With best regards, kasra