Re: [boost] [hash] Is there any interest in cryptographic hash functions?

Subject: Re: [boost] [hash] Is there any interest in cryptographic hash functions?
From: Kasra \(Math & ComSci\) (kasra_n500_at_[hidden])
Date: 2008-09-11 22:18:29

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