Add blake2b-256 algorithm

[jku]

Fixes: #282

Description of the changes being introduced by the pull request:

Add 'blake2b-256' as a new supported algorithm: it is really the same algorithm as blake2b, just half the digest size.

Refactors hash tests a little to ensure that blake2* gets tested but that they do not get tested on pyca_crypto (which does not support them).

I've manually verified that we now get same results as Warehouse :)

Please verify and check that the pull request fulfils the following requirements:

• The code follows the Code Style Guidelines
• Tests have been added for the bug fix or new feature
• Docs have been added for the bug fix or new feature

[coveralls]

Coverage increased (+0.001%) to 98.879% when pulling 800dad3 on jku:add-blake2b-256 into 0ec854b on secure-systems-lab:master.

[trishankatdatadog]

LGTM, I can't think of weaknesses. Thanks!

[jku]

Huh, blake2* is only supported in hashlib from python3.6 apparently

[jku]

I think test rig looks ok now: it should test every algorithm if the library and python version allow.
What I don't like is that it's not very easy to see that he correct algorithms did get tested -- but I think it's better than before.

[joshuagl]

Should we be throwing some kind of error if a caller is trying to generate blake2* digests with Python < 3.6 or pyca?

[jku]

It does throw an error... and yes: if the tests checked for that, they would be much easier to reason about

[jku]

I can squash the commits into two: but did not do it yet in case Joshua wants to see diff vs the previously reviewed version.

Notes for reviewers:

• ended up refactoring the _do_{algorithm}_update() functions into a single function, and modifying all _do_*() functions to take a algorithm as parameter: this makes the next item possible ⬇️
• the supported algorithms for a test are still not listed in every test but now it's pretty easy to reason and verify what is expected to fail and what is expected to succeed: _run_with_all_hash_libraries() decides that and can easily be made to print out those decisions if they need to be checked
• found an inconsistency in my new code: see the TypeError handling in hash.py (yay for testing)

[joshuagl]

This looks much better, thanks @jku!

I wonder if it would be clearer or not if we were using the unittest.skip* decorators to explicitly skip test cases where we don't expect them to work. That might lead to fewer unexpected errors than only accepting failures if it's an UnsupportedAlgorithmError, though does require explicit tests for the UnsupportedAlgorithmError on configurations which don't support it.

Let me know what you think.

[jku]

I wonder if it would be clearer or not if we were using the unittest.skip* decorators to explicitly skip test cases where we don't expect them to work.

I like the fact that we now test every combination and actually verify the correct Error so skip doesn't sound right. A @ExpectedFailureIf(condition, error, reason) might be useful but that does not exist out of the box.

Even with that, I don't think we can make it work since the tests are not "unique": a single test case tests all libraries so we can't condition the skip/expectedfailure on the library argument. Parameterizing 'library' (and maybe 'algorithm') would enable that but that means an additional test dependency on something like https://github.com/wolever/parameterized -- I think that's too much.

TL;DR: we should keep parameterizing in mind as an option in future, but for now the decorations are IMO not helpful

[joshuagl]

Thanks for taking the time to reason through that and discuss with me! Merging as is with a plan to look at parameterising tests in future.