Hashlib questions (use of uhashlib, native code otherwise present, ripemd160)

[doc-hex]

I have some questions and comments about the hashlib module.

1. Some boards/ports have sha256, sha1 and others, as part of the binary already (particularly when SSL is being used). Some of these are made available in uhashlib, and so IMHO hashlib should use those versions since they are both faster and smaller than anything we can do in pure python. It looks to me like sha256 is guaranteed to be there (if uhashlib exists) and SHA1 may exist if MICROPY_PY_UHASHLIB_SHA1 is set.

2. It pains me that lib/axtls/crypto contains lots of hash functions that could be part of uhashlib, plus AES and other primitives. That belongs as an issue against axtls though.

3. hashlib.new() seems like a useful addition to implement, since that would allow pruning of algorithms that aren't needed on today's project, and if this module is rewritten in C, it becomes a great place to extend with native versions, when available.

4. I need to have ripemd160 but I don't think it's common enough to bother weighing-down this module for everyone.

I'm going to follow-up with pull requests for 1 and 3, and maybe 4 if there is interest.

Any thoughts?

[dpgeorge]

Point 1 should be fixed by da5ddfc

Point 3 (addition of new()) was done a while ago in 175634b

For point 4, hashlib is now implemented as a set of components and you only need to install what your program will use. So adding hashlib-ripemd160 (or any other algo) is relatively easy.