You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have some questions and comments about the hashlib module.
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.
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.
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.
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?
The text was updated successfully, but these errors were encountered:
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.
I have some questions and comments about the
hashlib
module.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 inuhashlib
, and so IMHOhashlib
should use those versions since they are both faster and smaller than anything we can do in pure python. It looks to me likesha256
is guaranteed to be there (ifuhashlib
exists) and SHA1 may exist ifMICROPY_PY_UHASHLIB_SHA1
is set.It pains me that
lib/axtls/crypto
contains lots of hash functions that could be part ofuhashlib
, plus AES and other primitives. That belongs as an issue against axtls though.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.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?
The text was updated successfully, but these errors were encountered: