Need to use SHA1 implementation in boost
Greetings everyone, I'm new to the boost development mailing list. I'm preparing a library for boost review, and it needs a SHA1 implementation. I have my own header only version I took from the net, based on https://github.com/vog/sha1. I see that there's already a SHA1 implementation already in the boost, its part of UUID: https://github.com/boostorg/uuid/blob/develop/include/boost/uuid/sha1.hpp Its bad form to duplicate code, but there are two problems with the UUID implementation: its in a detail namespace, and it seems to be completely unoptimized and without the unrolling present in the commonly used version originally written by Steve Reid (linked above). What should I do? I'm guessing, some combination of the following: 1. Use UUID SHA1 as-is, even though its in a detail namespace. 2. Submit a pull request to UUID to make the SHA1 class a public interface. The problem here is the bar for public interfaces is quite high. I envision endless bike shedding (is "processs_bytes" the right name?) 3. Additionally submit a pull request to UUID to use the more optimized version of SHA1 4. Use my own version in my library submission, make it a detail class. Thanks
On 18 April 2016 at 12:43, Vinnie Falco <vinnie.falco@gmail.com> wrote:
Greetings everyone, I'm new to the boost development mailing list.
I'm preparing a library for boost review, and it needs a SHA1 implementation. I have my own header only version I took from the net, based on https://github.com/vog/sha1.
I see that there's already a SHA1 implementation already in the boost, its part of UUID: https://github.com/boostorg/uuid/blob/develop/include/boost/uuid/sha1.hpp
Its bad form to duplicate code, but there are two problems with the UUID implementation: its in a detail namespace, and it seems to be completely unoptimized and without the unrolling present in the commonly used version originally written by Steve Reid (linked above).
What should I do? I'm guessing, some combination of the following:
1. Use UUID SHA1 as-is, even though its in a detail namespace.
2. Submit a pull request to UUID to make the SHA1 class a public interface. The problem here is the bar for public interfaces is quite high. I envision endless bike shedding (is "processs_bytes" the right name?)
3. Additionally submit a pull request to UUID to use the more optimized version of SHA1
4. Use my own version in my library submission, make it a detail class.
Thanks
I think you can't do 1) because detail is allowed to change (like you suggest in 3). Maybe it's a good idea to release you version using the std::hash (or boost:hash) interface, although a separte library of common predefined hash function would be a more natural place for it?
On Mon, Apr 18, 2016 at 6:55 AM, Thijs van den Berg <thijs@sitmo.com> wrote:
Maybe it's a good idea to release you version using the std::hash (or boost:hash) interface, although a separte library of common predefined hash function would be a more natural place for it?
We've got a proposal winding its way through the C++ standard process which provides a new interface to computing hashes on objects suitable for use with unordered containers: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3980.html The problem is that while these interfaces are great for the purposes of generating 32-bit or 64-bit digests for hash tables, they are deficient for cryptographic purposes (i.e. producing a message authentication code). For example, regular std::hash doesn't deal with endiannes. But computing a cryptographic digest must yield the same results on all platforms, and therefore cares about endianness.
On 18 April 2016 at 13:03, Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Mon, Apr 18, 2016 at 6:55 AM, Thijs van den Berg <thijs@sitmo.com> wrote:
Maybe it's a good idea to release you version using the std::hash (or boost:hash) interface, although a separte library of common predefined hash function would be a more natural place for it?
We've got a proposal winding its way through the C++ standard process which provides a new interface to computing hashes on objects suitable for use with unordered containers: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3980.html
The problem is that while these interfaces are great for the purposes of generating 32-bit or 64-bit digests for hash tables, they are deficient for cryptographic purposes (i.e. producing a message authentication code). For example, regular std::hash doesn't deal with endiannes. But computing a cryptographic digest must yield the same results on all platforms, and therefore cares about endianness.
maybe that could also belong in a generic function that converting native integers to some endian specific digests? Whatever the answer, I think the most pragmatic way forward for you would be to put it in your personal detail and postpone this side discussion of a widening the scope of your library (proving a public SHA1) to later?
On Mon, 18 Apr 2016 07:03:03 -0400 Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Mon, Apr 18, 2016 at 6:55 AM, Thijs van den Berg <thijs@sitmo.com> wrote:
Maybe it's a good idea to release you version using the std::hash (or boost:hash) interface, although a separte library of common predefined hash function would be a more natural place for it?
We've got a proposal winding its way through the C++ standard process which provides a new interface to computing hashes on objects suitable for use with unordered containers: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3980.html
The problem is that while these interfaces are great for the purposes of generating 32-bit or 64-bit digests for hash tables, they are deficient for cryptographic purposes (i.e. producing a message authentication code). For example, regular std::hash doesn't deal with endiannes. But computing a cryptographic digest must yield the same results on all platforms, and therefore cares about endianness.
The hash function could return a machine independent value like `std::array<std::uint8_t, sha1_length>`. From the document listed above: template <class HashAlgorithm> struct uhash { using result_type = typename HashAlgorithm::result_type; template <class T> result_type operator()(T const& t) const noexcept { HashAlgorithm h; using std::hash_append; hash_append(h, t); return static_cast<result_type>(h); } }; Lee
On 2016-04-18 13:43, Vinnie Falco wrote:
Greetings everyone, I'm new to the boost development mailing list.
I'm preparing a library for boost review, and it needs a SHA1 implementation. I have my own header only version I took from the net, based on https://github.com/vog/sha1.
I see that there's already a SHA1 implementation already in the boost, its part of UUID: https://github.com/boostorg/uuid/blob/develop/include/boost/uuid/sha1.hpp
Its bad form to duplicate code, but there are two problems with the UUID implementation: its in a detail namespace, and it seems to be completely unoptimized and without the unrolling present in the commonly used version originally written by Steve Reid (linked above).
What should I do? I'm guessing, some combination of the following:
1. Use UUID SHA1 as-is, even though its in a detail namespace.
2. Submit a pull request to UUID to make the SHA1 class a public interface. The problem here is the bar for public interfaces is quite high. I envision endless bike shedding (is "processs_bytes" the right name?)
3. Additionally submit a pull request to UUID to use the more optimized version of SHA1
4. Use my own version in my library submission, make it a detail class.
IMHO, SHA1 should not be a public part of Boost.UUID. I would rather have a separate library with cryprographic hash functions (and maybe not only them). Regarding your library, I would recommend using your own implementation in the detail namespace or decompose your submission into two libraries - one with cryptographic functions that are generally useful and the other one with the rest. The latter will probably be more difficult to bring into Boost because it will mean two libraries have to pass the review and I expect crypto library to have a very rigorous attention. You might also want to submit a PR to Boost.UUID to use an optimized version of SHA1. Either through your new library with crypto algorithms (after it's accepted) or internally (can be done at any time). That will be of no use for your submission but may be useful for Boost.UUID users. I would strongly recommend against using implementation details of other libraries.
participants (4)
-
Andrey Semashev -
Lee Clagett -
Thijs van den Berg -
Vinnie Falco