> On 19 Jan 2017, at 19:50, Graham Leggett <minf...@sharp.fm> wrote: > > On 19 Jan 2017, at 18:29, Dirk-Willem van Gulik <di...@webweaving.org> wrote: > >> Am wondering now it if makes sense to create a new directory with: >> >> hash/* >> >> section (or something in crypto) where I cull things/move out of the current >> apr_random, sha256_glue and apr_md4/5 and apr_sha1 - and >> then all give them below treatment. >> >> It would make wiring them up to OS specific things or to >> nss/openssl/CommonCrypto also a bit easier. >> >> And then perhaps come up with a few extra apr_hash things that do a subset >> of what we currently do in the various apr_sha/md’s. >> >> Or is that not worth it - as mid to long term md4/md5 and sha1 will >> evaporate. > > I've always been keen to create an apr_crypto_hash_*() set of functions that > do hashing, but guaranteed to be implemented by crypto libraries (OpenSSL et > al) and therefore secure.
So I guess we could move them in one place - platform neutral (right now sha256 is unix only). And then rely on our own md4/5/sha1/256 when APU_HAVE_CRYPTO is not defined; and when it is - allow a driver to be specified - but if none is yet specified or loaded - we use the same order as in configure (CommonCrypto, openssl, nss) -- but refuse to fall back to our 'own'. And rework the innards of our existing hash functions to that apr_hash_ ctx form; so they can stay as 'legacy' bridges. Would that work ? A slight fly in the ointment may be that CommonCrypto does not yet have public APIs for this - I need to use a https://opensource.apple.com/source/CommonCrypto/ more complete than the one that seems to be the default for Sierra/Xcode to get things like RSA. Dw.
