apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: SHA256 and friends.
Date Fri, 20 Jan 2017 11:53:01 GMT
On Fri, Jan 20, 2017 at 9:22 AM, Dirk-Willem van Gulik
<dirkx@webweaving.org> 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.

>
>         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.

Regards,
Yann.

Mime
View raw message