On 04/04/2010 09:40 AM, Daniel Trebbien wrote:
Hi Scott,
I, too, think that option 1 is best. Several other streaming message digest libraries use this pattern whereby the hash calculation can be updated with a given string of bytes as many times as required and a finalization routine produces the hash. Java's `MessageDigest` interface (http://java.sun.com/javase/6/docs/api/java/security/MessageDigest.html), for example, calls its "update" routines `update` and finalization routines `digest`.
Using option 1 would probably make the library more intuitive for those who are used to this scheme and you can still accommodate users who would like to compute hashes at several points along the stream by ensuring that the copy constructor clones the state.
This is also the scheme used by crypto++ (C++), the Perl API, PyCrypto (Python) and openssl (C). I think the Boost crypto hash API should more closely mimic the existing de facto standard interfaces as much as possible. This will make it easier for those that program in multiple languages to make use of the Boost library. The MessageDigest interface (adapted for C++ & Boost) is the one I recommend be targeted for crypto hash functions rather than Boost CRC. The CRC interface is not robust enough to properly handle cryptographic hashes without a lot of extension in any case. References: http://www.dlitz.net/software/pycrypto/doc/#crypto-hash-hash-functions https://www.hasustorm.com/books/English/OReilly.Secure.Programming.Cookbook.... http://www.cryptopp.com/docs/ref/class_s_h_a1.html Rob