On 19 January 2017 at 19:50, Dirk-Willem van Gulik <[email protected]> wrote: > >> On 19 Jan 2017, at 19:50, Graham Leggett <[email protected]> wrote: >> >> On 19 Jan 2017, at 18:29, Dirk-Willem van Gulik <[email protected]> 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
Why do you need the obsolete hash functions? > 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. > >
