On Thu, Jan 19, 2017 at 1:50 PM, Dirk-Willem van Gulik <di...@webweaving.org> wrote: > >> 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 ?
Yes. This allows us to have either crypto-authored implementations, or even FIPS validated implementations, if we will simply be dispatching.
