> On 20 Jan 2017, at 12:53, Yann Ylavic <[email protected]> wrote:
>
> On Fri, Jan 20, 2017 at 9:22 AM, Dirk-Willem van Gulik
> <[email protected]> wrote:
>>
>> As to the selection of the hash - I can see three strategies
>>
>> A) current approach (we do this I think only for sha256):
>>
>> apr_crypto_hash_t * ctx = apr_crypto_sha256_new(pool);
>>
>> followed by a hash neutral/generic
>>
>> apr_hash(sha256_ctx, &buf, &len, plain, plainlen, pool);
>
> Probably apr_crypto_hash() since apr_hash() is non-crypto hashtable in APR.
> Would be nice to have init/update/finish versions too.
Agreed. And a len/size function - so we can make the whole thing opaque.
>>
>> and then create the the corresponding
>>
>> apr_crypto_md4_new(apr_pool_t *);
>> apr_crypto_md5_new(apr_pool_t *);
>> apr_crypto_sha1_new(apr_pool_t *);
>> apr_crypto_sha256_new(apr_pool_t *);
>>
>> and create new ones (eg. SHA512 etc, etc) as we go along.
>
> I like C) more since you propose ;)
>
>>
>> B) more of the ENUM approach as used elsewhere in APR:
>>
>> enum {
>> APR_CRYPTO_SANE_DEFAULT = APR_CRYPTO_SHA256, //
>> whatever the report of Ecrypt/NIST recommended in the year of the release.
>> APR_CRYPTO_MD4,
>> APR_CRYPTO_MD5,
>> ....
>>
>> apr_crypto_hash_t * ctx = apr_crypto_hash_new(pool,
>> APR_CRYPTO_MD4);
>>
>> with the goal of deprectating the apr_crypto_sha256_new soon. Which
>> has
>> the downside that this ultimately means numbers rather than symbols
>> and limiting what you can spot at link time.
>
> Quite the same as A) from an evolutivity perspective, with the
> mentioned downside.
>
>>
>> C) something more akin to what I use now (as the code I am trying
>> to get under long term maintenance control fudges things a bit
>> to deal with hardware base crypto (network HSMs and cheap
>> USB chipcards/SIMS):
>>
>> #define APR_CRYPTO_MD4 "MD4"
>> apr_crypto_hash_t * ctx = apr_crypto_hash_new(pool,
>> APR_CRYPTO_MD4);
>>
>> where the strings are picked so that they work with the existing
>> char* based pickers of openssl and nss (EVP_get_digestbyname et.al.).
>
> I like it, quite agile wrt APR release cycle.
> Maybe return an apr_status_t somehow for things like APR_ENOTIMPL.
>
>>
>> Does anyone have any strong opinions ?
>
> Not strong, but C) if no objection raises.
>
> Anyway, thanks for this work, authenticated encryption (AES-GCM,
> Chacha20-poly, caesar upcoming portfolio, ...) would be nice too.
Grin :)
Dw.
