Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Remove @ types from Sha1 implementation, create Digest trait, and implement most of the SHA-2 functions #7207
This pull request contains an unoptimized implementation of most of the SHA-2 functions (everything but the variable output size versions). I also created a common trait (Digest) for all of the interesting methods for working with digests and updated the existing SHA-1 code to use it. Finally, while working with the SHA-1 code, I got rid of the use of @ types and type objects.
I've tested all functions against the Wikipedia test vectors. Additionally, I tested the SHA-512, 384, and 256 variants against the Java implementations of those digests.
I did my best to try to follow Rust conventions, but, there are so many different conventions in the code base right now that I'm not sure if I'm following the correct one or not. Anyway, I'm happy to rework if I didn't get the coding convention right (or if there are bugs!).
This looks really good! ... But I've got a few nitpicks:
There are several instances of
(Also, the convention is for static constants to be uppercase.)
I've implemented almost all of the changes mentioned by reviewers above and also modified the Digest trait to so that its possible to calculate a digest value without any heap allocation. The only change I didn't implement was to use default methods. When I tried to do that, I ended up getting the error:
rust/src/libextra/workcache.rs:253:4: 253:37 error: internal compiler error: method not found in AST map?!
which makes me think that there might still be some bugs remaining in the default methods implementation. I don't have a simple test case for that issue, but I can make a branch available that triggers it if desired.
I think there is some room for extracting out the common code for the SHA-256 and SHA-512 implementations into a some sort of generic structure. It would be even better if that generic structure could support other block based digests. However, I tried to do this a couple of times and kept running into the same issue: although the algorithms are very similar they contain enough small differences that its harder to do this than I'd thought it would be. My thinking is that it might be easier to try to handle this as part of an MD-5, SHA-3, or some other digest implementation since I don't know enough about how those digests work to feel all that confident that I'd be able to create a generic structure that would handle them right now. Anyway, as long as the Digest trait's definition is solid, changing the implementation shouldn't end up breaking any code.