Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <C54ED910-317D-43D3-8BF9-F18B5D427405@webweaving.org>
References: <EB050EBB-EA5E-4908-9B6A-031E5B6F5E0E@webweaving.org>
 <BCC8F08D-6B96-4137-98A7-DC748F2B7A9A@webweaving.org> <DCD529CE-6AFC-4606-98ED-189CF51FB511@sharp.fm>
 <493F36A5-3620-4603-BFB2-6C16E77D243B@webweaving.org> <CACsi253GuONTZv5J7oCu-_Y2ryvbvC8JQ41AK3e--OZfzEKXsA@mail.gmail.com>
 <C54ED910-317D-43D3-8BF9-F18B5D427405@webweaving.org>
From: Yann Ylavic <ylavic.dev@gmail.com>
Date: Fri, 20 Jan 2017 12:53:01 +0100
Message-ID: <CAKQ1sVN+uHb11TSSsdyQVn2nVNZ-YwEq3zH9q9etVLjS0hY+qQ@mail.gmail.com>
Subject: Re: SHA256 and friends.
To: Dirk-Willem van Gulik <dirkx@webweaving.org>
Cc: APR Developer List <dev@apr.apache.org>
Content-Type: text/plain; charset=UTF-8
archived-at: Fri, 20 Jan 2017 11:53:10 -0000

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.