You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Dirk-Willem van Gulik <di...@webweaving.org> on 2017/01/19 14:20:05 UTC
SHA256 and friends.
Where can I find the proper version of below — to do things like
apr_crypto_hash_t * sha256_ctx = apr_crypto_sha256_new(pool);
apr_hash(sha256_ctx, …...
? Or was this abstracting in apr_random of the hash something which was never completed (nor had its MD2, MD5 and friends folded in) ?
Dw.
Index: apr_random.c
===================================================================
--- apr_random.c (revision 1779018)
+++ apr_random.c (working copy)
@@ -53,6 +53,36 @@
#define crypt_setkey(c,k) (c)->set_key((c)->data,k)
#define crypt_crypt(c,out,in) (c)->crypt((c)->date,out,in)
+APR_DECLARE(apr_status_t) apr_hash_init(apr_crypto_hash_t *key_hash) {
+ hash_init(key_hash);
+ return APR_SUCCESS;
+}
+
+APR_DECLARE(apr_status_t) apr_hash_add(apr_crypto_hash_t * key_hash, const void * addvuff, apr_size_t addbytes) {
+ hash_add(key_hash, addvuff, addbytes);
+ return APR_SUCCESS;
+}
+
+APR_DECLARE(apr_status_t) apr_hash_finish(apr_crypto_hash_t * key_hash, void ** resultp, apr_size_t *resultlenp, apr_pool_t * pool) {
+ if (*resultp == NULL)
+ *resultp = apr_palloc(pool, key_hash->size);
+ else if (*resultlenp < key_hash->size)
+ return APR_EINVAL;
+
+ hash_finish(key_hash, *resultp);
+ *resultlenp = key_hash->size;
+
+ return APR_SUCCESS;
+}
+
+APR_DECLARE(apr_status_t) apr_hash(apr_crypto_hash_t * key_hash, void ** resultp, apr_size_t *resultlenp, const void * inbuff, apr_size_t inbytes, apr_pool_t * pool) {
+ hash_init(key_hash);
+ hash_add(key_hash, inbuff, inbytes);
+
+ return apr_hash_finish(key_hash, resultp, resultlenp, pool);
+}
Re: SHA256 and friends.
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 20 Jan 2017, at 20:57, Ruediger Pluem <rp...@apache.org> wrote:
> On 01/20/2017 05:01 PM, Eric Covener wrote:
>> On Fri, Jan 20, 2017 at 10:52 AM, Yann Ylavic <yl...@gmail.com> wrote:
>>> On Fri, Jan 20, 2017 at 4:19 PM, Dirk-Willem van Gulik
>>> <di...@webweaving.org> wrote:
>>>>
>>>> Ok so if we had a special #ifdef for 'TRUE_MD5 and would manually tweak/mark up the 2 or 3 places
>>>> that we know we need a real MD5 - we could have a 'fiddle' mode where we silently return a better 'md5'
>>>> in the places where we would like to use a SHA256 but it is just too much hassle to adjust things.
>>>
>>> MD5 *is* MD5, preferably used (and not recommended) for
>>> non-cryptographic purpose, but still I think apr_md5()'s result
>>> shouldn't differ from whatelse_md5()'s.
>>>
>>> We can't break users silently, if they use MD5, well they have it.
>>
>> +1
>>
> +1
Darn - I thought I would not get away with this - but had to try :). Will preserve - and am now on a path of
considering a 32/128/256 bit digest which is not crypto secure and which we use for digest purposes
and ones which are for interoperability & actual security (unguessable, unsyntisizable) reasons.
Dw.
Re: SHA256 and friends.
Posted by Ruediger Pluem <rp...@apache.org>.
On 01/20/2017 05:01 PM, Eric Covener wrote:
> On Fri, Jan 20, 2017 at 10:52 AM, Yann Ylavic <yl...@gmail.com> wrote:
>> On Fri, Jan 20, 2017 at 4:19 PM, Dirk-Willem van Gulik
>> <di...@webweaving.org> wrote:
>>>
>>> Ok so if we had a special #ifdef for 'TRUE_MD5 and would manually tweak/mark up the 2 or 3 places
>>> that we know we need a real MD5 - we could have a 'fiddle' mode where we silently return a better 'md5'
>>> in the places where we would like to use a SHA256 but it is just too much hassle to adjust things.
>>
>> MD5 *is* MD5, preferably used (and not recommended) for
>> non-cryptographic purpose, but still I think apr_md5()'s result
>> shouldn't differ from whatelse_md5()'s.
>>
>> We can't break users silently, if they use MD5, well they have it.
>
> +1
>
+1
Regards
R�diger
Re: SHA256 and friends.
Posted by Eric Covener <co...@gmail.com>.
On Fri, Jan 20, 2017 at 10:52 AM, Yann Ylavic <yl...@gmail.com> wrote:
> On Fri, Jan 20, 2017 at 4:19 PM, Dirk-Willem van Gulik
> <di...@webweaving.org> wrote:
>>
>> Ok so if we had a special #ifdef for 'TRUE_MD5 and would manually tweak/mark up the 2 or 3 places
>> that we know we need a real MD5 - we could have a 'fiddle' mode where we silently return a better 'md5'
>> in the places where we would like to use a SHA256 but it is just too much hassle to adjust things.
>
> MD5 *is* MD5, preferably used (and not recommended) for
> non-cryptographic purpose, but still I think apr_md5()'s result
> shouldn't differ from whatelse_md5()'s.
>
> We can't break users silently, if they use MD5, well they have it.
+1
Re: SHA256 and friends.
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Jan 20, 2017 at 4:19 PM, Dirk-Willem van Gulik
<di...@webweaving.org> wrote:
>
> Ok so if we had a special #ifdef for 'TRUE_MD5 and would manually tweak/mark up the 2 or 3 places
> that we know we need a real MD5 - we could have a 'fiddle' mode where we silently return a better 'md5'
> in the places where we would like to use a SHA256 but it is just too much hassle to adjust things.
MD5 *is* MD5, preferably used (and not recommended) for
non-cryptographic purpose, but still I think apr_md5()'s result
shouldn't differ from whatelse_md5()'s.
We can't break users silently, if they use MD5, well they have it.
Regards,
Yann.
Re: SHA256 and friends.
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> On 20 Jan 2017, at 16:02, Ben Laurie <be...@links.org> wrote:
>
> On 20 January 2017 at 14:52, Dirk-Willem van Gulik <di...@webweaving.org> wrote:
>>
>>> On 20 Jan 2017, at 15:46, Ben Laurie <be...@links.org> wrote:
>>>
>>> On 20 January 2017 at 14:36, Dirk-Willem van Gulik <di...@webweaving.org> wrote:
>>>> On 20 Jan 2017, at 13:00, Ben Laurie <be...@links.org> wrote:
>>>>
>>>>> Why do you need the obsolete hash functions?
>>>>
>>>> I am still in the middle of some inventory work with the help of a few friendly enterprise & cloud folks.
>>>>
>>>> But it is nog looking good -- so far its seems that:
>>>>
>>>> - md4 is rarely used (i,e.a actually called).
>>>>
>>>> - md5 is very often used for
>>>> - salted password
>>>> - creating all sorts of unguessable IDs.
>>>> - generation of a randomish token/digest
>>>> - creating/protecting session cookies
>>>> - creating 12/23/34/1221231.txt file trees or similar equal wear file / tmp file fanout.
>>>> - checksumming a file along the lines of taking an fstat() snapshot.
>>>> - commonly used UUID gen.
>>>> - content-digest generation for things like cache headers, imap/sieve breakout.
>>>> - file integrity.
>>>>
>>>> - sha1 is used a factor 10x less. Mostly:
>>>> - salted password
>>>> - creating/protecting session cookies
>>>>
>>>> - sha256 && 512 seems to be used about as often md4.
>>>>
>>>> Though nothing stopping us from having a snotty warning/#define to discourage use - and wack the 60 or so distinct places/ where MD5 is currently used in subversion/httpd and friends and upping this to at least sha256.
>>>>
>>>> I guess cryptographically there is little point between an MD5 and the last 16 bytes of a SHA256 ? Correct ?
>>>
>>> Not sure what question you're asking?
>>
>> So MD5 seems by far the dominant digest method. MOST is actually just to get a nice hash/randmomish thing. Or just simple integrety.
>>
>> Only in a few cases does it actually need to be an MD5 for interoperability (E.g. the Content-MD5 header of htttp, the salted-MD5 against an existing htpassword file).
>>
>> In most other cases it could silently be replaced by the last 16 bytes of a SHA256 (and in quite a few cases; buffer issues permitting; in a full SHA256).
>>
>> So is, from a security perspective, the last 16 bytes of a SHA256 over a given datablock equivalent to a MD5 over the same datablock. In terms of being able to determine the outcome; i.e. produce clashing hashes/synthesise data with the same (partial) hash ?
>>
>> Or are the last* 16 bytes of a SHA256 'harder' to control ?
>
> Last 16 of SHA-256 is stronger than MD5 because, unlike MD5, it hasn't
> been broken.
Ok so if we had a special #ifdef for 'TRUE_MD5 and would manually tweak/mark up the 2 or 3 places
that we know we need a real MD5 - we could have a 'fiddle' mode where we silently return a better 'md5'
in the places where we would like to use a SHA256 but it is just too much hassle to adjust things.
Dw.
Re: SHA256 and friends.
Posted by Ben Laurie <be...@links.org>.
On 20 January 2017 at 14:52, Dirk-Willem van Gulik <di...@webweaving.org> wrote:
>
>> On 20 Jan 2017, at 15:46, Ben Laurie <be...@links.org> wrote:
>>
>> On 20 January 2017 at 14:36, Dirk-Willem van Gulik <di...@webweaving.org> wrote:
>>> On 20 Jan 2017, at 13:00, Ben Laurie <be...@links.org> wrote:
>>>
>>>> Why do you need the obsolete hash functions?
>>>
>>> I am still in the middle of some inventory work with the help of a few friendly enterprise & cloud folks.
>>>
>>> But it is nog looking good -- so far its seems that:
>>>
>>> - md4 is rarely used (i,e.a actually called).
>>>
>>> - md5 is very often used for
>>> - salted password
>>> - creating all sorts of unguessable IDs.
>>> - generation of a randomish token/digest
>>> - creating/protecting session cookies
>>> - creating 12/23/34/1221231.txt file trees or similar equal wear file / tmp file fanout.
>>> - checksumming a file along the lines of taking an fstat() snapshot.
>>> - commonly used UUID gen.
>>> - content-digest generation for things like cache headers, imap/sieve breakout.
>>> - file integrity.
>>>
>>> - sha1 is used a factor 10x less. Mostly:
>>> - salted password
>>> - creating/protecting session cookies
>>>
>>> - sha256 && 512 seems to be used about as often md4.
>>>
>>> Though nothing stopping us from having a snotty warning/#define to discourage use - and wack the 60 or so distinct places/ where MD5 is currently used in subversion/httpd and friends and upping this to at least sha256.
>>>
>>> I guess cryptographically there is little point between an MD5 and the last 16 bytes of a SHA256 ? Correct ?
>>
>> Not sure what question you're asking?
>
> So MD5 seems by far the dominant digest method. MOST is actually just to get a nice hash/randmomish thing. Or just simple integrety.
>
> Only in a few cases does it actually need to be an MD5 for interoperability (E.g. the Content-MD5 header of htttp, the salted-MD5 against an existing htpassword file).
>
> In most other cases it could silently be replaced by the last 16 bytes of a SHA256 (and in quite a few cases; buffer issues permitting; in a full SHA256).
>
> So is, from a security perspective, the last 16 bytes of a SHA256 over a given datablock equivalent to a MD5 over the same datablock. In terms of being able to determine the outcome; i.e. produce clashing hashes/synthesise data with the same (partial) hash ?
>
> Or are the last* 16 bytes of a SHA256 'harder' to control ?
Last 16 of SHA-256 is stronger than MD5 because, unlike MD5, it hasn't
been broken.
> Because in that case we get some nice middle ground,
>
> Dw.
>
> Or an XOR fold of all its byte into 16.
>
>
>
>
>
>
>
>
Re: SHA256 and friends.
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> On 20 Jan 2017, at 15:46, Ben Laurie <be...@links.org> wrote:
>
> On 20 January 2017 at 14:36, Dirk-Willem van Gulik <di...@webweaving.org> wrote:
>> On 20 Jan 2017, at 13:00, Ben Laurie <be...@links.org> wrote:
>>
>>> Why do you need the obsolete hash functions?
>>
>> I am still in the middle of some inventory work with the help of a few friendly enterprise & cloud folks.
>>
>> But it is nog looking good -- so far its seems that:
>>
>> - md4 is rarely used (i,e.a actually called).
>>
>> - md5 is very often used for
>> - salted password
>> - creating all sorts of unguessable IDs.
>> - generation of a randomish token/digest
>> - creating/protecting session cookies
>> - creating 12/23/34/1221231.txt file trees or similar equal wear file / tmp file fanout.
>> - checksumming a file along the lines of taking an fstat() snapshot.
>> - commonly used UUID gen.
>> - content-digest generation for things like cache headers, imap/sieve breakout.
>> - file integrity.
>>
>> - sha1 is used a factor 10x less. Mostly:
>> - salted password
>> - creating/protecting session cookies
>>
>> - sha256 && 512 seems to be used about as often md4.
>>
>> Though nothing stopping us from having a snotty warning/#define to discourage use - and wack the 60 or so distinct places/ where MD5 is currently used in subversion/httpd and friends and upping this to at least sha256.
>>
>> I guess cryptographically there is little point between an MD5 and the last 16 bytes of a SHA256 ? Correct ?
>
> Not sure what question you're asking?
So MD5 seems by far the dominant digest method. MOST is actually just to get a nice hash/randmomish thing. Or just simple integrety.
Only in a few cases does it actually need to be an MD5 for interoperability (E.g. the Content-MD5 header of htttp, the salted-MD5 against an existing htpassword file).
In most other cases it could silently be replaced by the last 16 bytes of a SHA256 (and in quite a few cases; buffer issues permitting; in a full SHA256).
So is, from a security perspective, the last 16 bytes of a SHA256 over a given datablock equivalent to a MD5 over the same datablock. In terms of being able to determine the outcome; i.e. produce clashing hashes/synthesise data with the same (partial) hash ?
Or are the last* 16 bytes of a SHA256 'harder' to control ?
Because in that case we get some nice middle ground,
Dw.
Or an XOR fold of all its byte into 16.
Re: SHA256 and friends.
Posted by Ben Laurie <be...@links.org>.
On 20 January 2017 at 14:36, Dirk-Willem van Gulik <di...@webweaving.org> wrote:
> On 20 Jan 2017, at 13:00, Ben Laurie <be...@links.org> wrote:
>
>> Why do you need the obsolete hash functions?
>
> I am still in the middle of some inventory work with the help of a few friendly enterprise & cloud folks.
>
> But it is nog looking good -- so far its seems that:
>
> - md4 is rarely used (i,e.a actually called).
>
> - md5 is very often used for
> - salted password
> - creating all sorts of unguessable IDs.
> - generation of a randomish token/digest
> - creating/protecting session cookies
> - creating 12/23/34/1221231.txt file trees or similar equal wear file / tmp file fanout.
> - checksumming a file along the lines of taking an fstat() snapshot.
> - commonly used UUID gen.
> - content-digest generation for things like cache headers, imap/sieve breakout.
> - file integrity.
>
> - sha1 is used a factor 10x less. Mostly:
> - salted password
> - creating/protecting session cookies
>
> - sha256 && 512 seems to be used about as often md4.
>
> Though nothing stopping us from having a snotty warning/#define to discourage use - and wack the 60 or so distinct places/ where MD5 is currently used in subversion/httpd and friends and upping this to at least sha256.
>
> I guess cryptographically there is little point between an MD5 and the last 16 bytes of a SHA256 ? Correct ?
Not sure what question you're asking?
>
> As in a lot of above case - the MD5 is not exposed - does not actually need to be an MD5 for interoperability purposes.
>
>
> Dw.
>
>
Re: SHA256 and friends.
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 20 Jan 2017, at 13:00, Ben Laurie <be...@links.org> wrote:
> Why do you need the obsolete hash functions?
I am still in the middle of some inventory work with the help of a few friendly enterprise & cloud folks.
But it is nog looking good -- so far its seems that:
- md4 is rarely used (i,e.a actually called).
- md5 is very often used for
- salted password
- creating all sorts of unguessable IDs.
- generation of a randomish token/digest
- creating/protecting session cookies
- creating 12/23/34/1221231.txt file trees or similar equal wear file / tmp file fanout.
- checksumming a file along the lines of taking an fstat() snapshot.
- commonly used UUID gen.
- content-digest generation for things like cache headers, imap/sieve breakout.
- file integrity.
- sha1 is used a factor 10x less. Mostly:
- salted password
- creating/protecting session cookies
- sha256 && 512 seems to be used about as often md4.
Though nothing stopping us from having a snotty warning/#define to discourage use - and wack the 60 or so distinct places/ where MD5 is currently used in subversion/httpd and friends and upping this to at least sha256.
I guess cryptographically there is little point between an MD5 and the last 16 bytes of a SHA256 ? Correct ?
As in a lot of above case - the MD5 is not exposed - does not actually need to be an MD5 for interoperability purposes.
Dw.
Re: SHA256 and friends.
Posted by Ben Laurie <be...@links.org>.
On 19 January 2017 at 19:50, Dirk-Willem van Gulik <di...@webweaving.org> wrote:
>
>> On 19 Jan 2017, at 19:50, Graham Leggett <mi...@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
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.
>
>
Re: SHA256 and friends.
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> On 20 Jan 2017, at 12:53, Yann Ylavic <yl...@gmail.com> wrote:
>
> On Fri, Jan 20, 2017 at 9:22 AM, Dirk-Willem van Gulik
> <di...@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.
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.
Re: SHA256 and friends.
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Jan 20, 2017 at 1:01 PM, Dirk-Willem van Gulik
<di...@webweaving.org> wrote:
> On 20 Jan 2017, at 12:53, Yann Ylavic <yl...@gmail.com> wrote:
>>>
>>> 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.
>
> I think global rename to apr_digest would be called for (and leave the few existing ones that are crypto hash in place,
Fine by me.
Regards,
Yann.
Re: SHA256 and friends.
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 20 Jan 2017, at 12:53, Yann Ylavic <yl...@gmail.com> wrote:
>>
>> 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.
I think global rename to apr_digest would be called for (and leave the few existing ones that are crypto hash in place,
Dw.
Re: SHA256 and friends.
Posted by Yann Ylavic <yl...@gmail.com>.
On Fri, Jan 20, 2017 at 9:22 AM, Dirk-Willem van Gulik
<di...@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.
Re: SHA256 and friends.
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 19 Jan 2017, at 21:04, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> 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 <mi...@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.
So turns out where are not using this that much - so retroactively fixing things should be easy - and we may be able to deprecate quickly.
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);
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.
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.
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.).
Option A and B have the advantage that with an
#ifdef APU_HAVE_CRYPTO
one can cleanly add in things like SHA512 -- and option A really locks this down (i.e. in A you cannot (dynamically) link and thus run a binary unsafe). With option B that becomes a compile time thing and option C - while ultimately flexible - would be more prone to fiddling and surprises.
What is the general thought on this ? I am tempted to go for 'A' -- as it gives strong guarantees - hard to make things go wrong. And if at some point a paying customer or employer of some one needs things like FIPS #ifdefs - these can be 'strong'.
However I do note that most crypto libraries seem to go for a const char*; and that their names are pretty much interoperable. (Though internally most use something like A, e.g. openssl its
const EVP_MD *EVP_sha512(void) { return (&sha512_md); }
I would have thought this to be an easy choice - but for the fact that I was somewhat disheartened by the general state of our hashes - and how far out of date we are. And recognize that A and B are more impediments for people who want to do the right thing; than ''C' -- where as long as you link to a capable crypto library you automatically get anything new.
Does anyone have any strong opinions ?
Dw.
Re: SHA256 and friends.
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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 <mi...@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.
Re: SHA256 and friends.
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> On 19 Jan 2017, at 19:50, Graham Leggett <mi...@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 ?
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.
Re: SHA256 and friends.
Posted by Graham Leggett <mi...@sharp.fm>.
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.
Regards,
Graham
--
Re: SHA256 and friends.
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 19 Jan 2017, at 15:20, Dirk-Willem van Gulik <di...@webweaving.org> wrote:
>
> Where can I find the proper version of below — to do things like
>
> apr_crypto_hash_t * sha256_ctx = apr_crypto_sha256_new(pool);
>
> apr_hash(sha256_ctx, …...
>
> ? Or was this abstracting in apr_random of the hash something which was never completed (nor had its MD2, MD5 and friends folded in) ?
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.
Dw.
> Index: apr_random.c
> ===================================================================
> --- apr_random.c (revision 1779018)
> +++ apr_random.c (working copy)
> @@ -53,6 +53,36 @@
> #define crypt_setkey(c,k) (c)->set_key((c)->data,k)
> #define crypt_crypt(c,out,in) (c)->crypt((c)->date,out,in)
>
> +APR_DECLARE(apr_status_t) apr_hash_init(apr_crypto_hash_t *key_hash) {
> + hash_init(key_hash);
> + return APR_SUCCESS;
> +}
> +
> +APR_DECLARE(apr_status_t) apr_hash_add(apr_crypto_hash_t * key_hash, const void * addvuff, apr_size_t addbytes) {
> + hash_add(key_hash, addvuff, addbytes);
> + return APR_SUCCESS;
> +}
> +
> +APR_DECLARE(apr_status_t) apr_hash_finish(apr_crypto_hash_t * key_hash, void ** resultp, apr_size_t *resultlenp, apr_pool_t * pool) {
> + if (*resultp == NULL)
> + *resultp = apr_palloc(pool, key_hash->size);
> + else if (*resultlenp < key_hash->size)
> + return APR_EINVAL;
> +
> + hash_finish(key_hash, *resultp);
> + *resultlenp = key_hash->size;
> +
> + return APR_SUCCESS;
> +}
> +
> +APR_DECLARE(apr_status_t) apr_hash(apr_crypto_hash_t * key_hash, void ** resultp, apr_size_t *resultlenp, const void * inbuff, apr_size_t inbytes, apr_pool_t * pool) {
> + hash_init(key_hash);
> + hash_add(key_hash, inbuff, inbytes);
> +
> + return apr_hash_finish(key_hash, resultp, resultlenp, pool);
> +}
>