SPARKNaCl
SPARKNaCl copied to clipboard
rod-chapman
Added SHA384
Added SHA-384 to get closer to enabling yet another TLS 1.3 cipher suite. Essentially identical to SHA-512 but with smaller digest size, different IVs and truncated output. Tested against FIPS 180-4 test vectors in SHA384ShortMsg.rsp (added to expected test results)
Code which is common to all hash algorithms (including RFSB) should go in the private part of SPARKNaCl.Hashing (like the TS64 function, for example.). Code that is common to all variants of SHA2 should go in SPARKNaCl.Hashing.SHA2_Common. Does that make sense?
I also agree and think that if we are already moving subprograms, like TS64, we should perhaps give them a names that summarise what they do. For instance, when implementing RFSB I found those names to be quite cryptic at first and generally cumbersome to work with.
I agree - I think those short names came from TweetNaCl, so aren't really appropriate here, so please rename them as you see fit.
I won't be able to look at it this week, if you have bandwidth and would like to take a look at the refactor sooner I'd welcome the help!
I might be able to get to it this week… I would suggest creating a new branch where we do the refactoring, merging that one (after PR ofc), rebasing this branch and then closing this PR. Or do you want to have refactoring done in this branch?
I am currently working on DL64 and noticed that its implementation is tailored for 32bit machines. Shall I view 32bit machines as the default target in this refactoring?
I think the default is "portable and should work on any 32 or 64 bit machine (but favour 32-bit if and where you can...)" Does that make sense?
Quick update: I am still working on the refactoring. I currently stuck on a loop invariant but hope to finish the refactoring soon.
Unfortunately, I am currently forced to focus my attention on other things than the refactoring. I do not know when that situation will change significantly. Thus, I see two options; either I continue to work on this branch, which might take quite some time or I hand this effort over to someone else. What do you guys think is the most sensible option?
If you can push your commits to this PR branch I'm happy to continue working on it where you left off.
That is wonderful. But I do not have the rights to push to your branch (docandrew:master)
I still need to run proofs but took @MxAR 's work a little bit further. Rather than introduce a new SHA2 package I went ahead and placed it in the private part of sparknacl-hashing. I figured since all the hashing in SPARKNaCl is SHA2 maybe this was OK, but I thought I'd have you take a look and get your thoughts.
At a first glance it looks quite good. I think it would be better to have a separate SHA2 module for two reasons. The first one is that although the functions of the SHA2 family are the main CHFs implemented in SPARKNaCl, SPARKNaCl also contains an implementation of RFSB509. RFSB509 is by no means as important as members of the SHA2 family but it is still a CHF. Beyond that I think it would be beneficial to have a separate module in case a contributor decides to implement a CHF that is not a member of the SHA2 family like SHA3 or SM3.
But then again I should not be making suggestions that lead to more work after I excused myself from the refactoring because I do not have enough time…
I think I agree with Max - we already have more than one "family" of hash functions in the library - SHA2 and RFSB, so the package structure should reflect that.