You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Dirkjan Ochtman <dj...@apache.org> on 2013/10/10 22:49:53 UTC
SHA2 in APR
Hi,
(Sending again from the right mail address, please ignore the other one.)
I've been hanging out in #apr on Freenode recently, but it appears the
intersection of people hanging out there and active APR committers is
pretty much the empty set.
I recently filed
https://issues.apache.org/bugzilla/show_bug.cgi?id=55520 and I wonder
if people had actually seen that. There seems to have been a lot of
talk about an 1.5 release, so I might be late with this, but since the
implementation has already been there, maybe exposing this isn't so
hard? In any case, this seems like a no-brainer to me.
The reason I've recently gotten interested in APR (and SHA support) is
my work on https://github.com/mozilla/mod_authn_persona.
Cheers,
Dirkjan
Re: SHA2 in APR
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Oct 10, 2013 at 4:49 PM, Dirkjan Ochtman <dj...@apache.org> wrote:
> Hi,
>
> (Sending again from the right mail address, please ignore the other one.)
>
> I've been hanging out in #apr on Freenode recently, but it appears the
> intersection of people hanging out there and active APR committers is
> pretty much the empty set.
>
> I recently filed
> https://issues.apache.org/bugzilla/show_bug.cgi?id=55520 and I wonder
> if people had actually seen that. There seems to have been a lot of
> talk about an 1.5 release, so I might be late with this, but since the
> implementation has already been there, maybe exposing this isn't so
> hard? In any case, this seems like a no-brainer to me.
>
> The reason I've recently gotten interested in APR (and SHA support) is
> my work on https://github.com/mozilla/mod_authn_persona.
>
> Cheers,
>
> Dirkjan
>
(Only since nobody responded yet...)
Somebody in APR-land with an interest in hashes needs to take a bite. What
it looks like to my very untrained eye is an implementation of one of a
handful of the SHA2 hashes* (i.e., incomplete) which was taken in 10 years
ago from another source and maintained independently and never used in a
way that would expose implementation defects beyond what various compilers
and static analysis tools complained about over the years.
*Maybe it is more complete in the 1.x branches; I just noticed that some
unused hashes were ripped out of trunk 10 months ago.
Surely there's a more appropriate place to pick up SHA2?
(But really, somebody with a real interest will hopefully respond.)
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: SHA2 in APR
Posted by Nick Kew <ni...@apache.org>.
On 7 Nov 2013, at 05:57, William A. Rowe Jr. wrote:
> Otherwise, it seems prudent to get out of
> the hashing business and rip out md/sha1 entirely from apr 2.
-1 to ripping: that's pulling the rug from under existing apps.
At worst, deprecate.
The question is about exposing existing sha2 code.
For: it's there, and serves someone's need.
Against: it would appear to be less than complete, and to need a
fair bit of work to look comprehensive.
I guess I should take yours as a vote against what I was mulling over:
namely inviting Dirkjan to submit a patch and commit if it WorksForMe
and noone shouts?
> I have no issue with providing a simple hash, these are used for just
> about all arbitrary string values where you need to uniquify them into
> a predictable byte token.
That sounds like existing apr_md5 apps.
--
Nick Kew
Re: SHA2 in APR
Posted by Branko Čibej <br...@apache.org>.
On 07.11.2013 06:57, William A. Rowe Jr. wrote:
> On Wed, 16 Oct 2013 16:17:33 +0100
> Nick Kew <ni...@apache.org> wrote:
>> On 10 Oct 2013, at 21:49, Dirkjan Ochtman wrote:
>>
>>> The reason I've recently gotten interested in APR (and SHA support)
>>> is my work on https://github.com/mozilla/mod_authn_persona.
>> OK, that raises two questions:
>>
>> 1. From your point of view, how useful would a fully-implemented
>> apr_sha2 be, compared either to using a third-party library or a
>> standalone implementation?
>>
>> 2. If it does add value, is the API referenced in your bug exactly
>> what you want, or might there be mileage in reviewing/extending it?
>>
>> It's not really clear to me what value an APR wrapper adds to sha2.
>> Or indeed, md5/sha1, beyond their being widely used by existing apps.
> If we are a 'hash provider', IMHO we should provide the strongest
> hashing available, even if we simply delegate it to openssl (which we
> already consume in apr 2). Otherwise, it seems prudent to get out of
> the hashing business and rip out md/sha1 entirely from apr 2.
I'd sooner rip the dbd and dbm providers ... and the built-in
Berkeley-DB wrapper whose only discernible purpose is to create havoc by
helping apps to load two different versions of BDB at the same time.
-- Brane
Re: SHA2 in APR
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Wed, 16 Oct 2013 16:17:33 +0100
Nick Kew <ni...@apache.org> wrote:
>
> On 10 Oct 2013, at 21:49, Dirkjan Ochtman wrote:
>
> > The reason I've recently gotten interested in APR (and SHA support)
> > is my work on https://github.com/mozilla/mod_authn_persona.
>
> OK, that raises two questions:
>
> 1. From your point of view, how useful would a fully-implemented
> apr_sha2 be, compared either to using a third-party library or a
> standalone implementation?
>
> 2. If it does add value, is the API referenced in your bug exactly
> what you want, or might there be mileage in reviewing/extending it?
>
> It's not really clear to me what value an APR wrapper adds to sha2.
> Or indeed, md5/sha1, beyond their being widely used by existing apps.
If we are a 'hash provider', IMHO we should provide the strongest
hashing available, even if we simply delegate it to openssl (which we
already consume in apr 2). Otherwise, it seems prudent to get out of
the hashing business and rip out md/sha1 entirely from apr 2.
I have no issue with providing a simple hash, these are used for just
about all arbitrary string values where you need to uniquify them into
a predictable byte token.
Re: SHA2 in APR
Posted by Dirkjan Ochtman <dj...@apache.org>.
On Wed, Nov 6, 2013 at 10:33 AM, Nick Kew <ni...@apache.org> wrote:
> An even briefer look just now in response to your ping suggests
> I was missing your point, and that all you're asking for is that
> random/unix/sha2.h be exposed in the public API. Is that correct?
That's right, yes.
> I would guess this code has never been tested, though there's
> what looks like a placeholder in testpass.c. Have you run it
> at all? How well does it work for you if you just copy sha2.h
> manually to your APR include directory and use it for your module?
I copied the sha2.h from SVN (trunk) straight to my module code, and
did a few things like this:
@@ -29,9 +30,9 @@ void hmac(const void *key, apr_size_t keylen, const
char *data, apr_size_t datal
if (keylen > HMAC_BLOCKSIZE) {
- apr_sha1_ctx_t context;
- unsigned char digest[APR_SHA1_DIGESTSIZE];
- apr_sha1_init(&context);
- apr_sha1_update_binary(&
context, key, keylen);
- apr_sha1_final(digest, &context);
+ SHA256_CTX context;
+ unsigned char digest[SHA256_DIGEST_LENGTH];
+ apr__SHA256_Init(&context);
+ apr__SHA256_Update(&context, key, keylen);
+ apr__SHA256_Final(digest, &context);
key = digest;
It seems to work correctly; my HMAC implementation based on this gets
the same result as doing a SHA256-based HMAC using the Python built-in
implementation. One slight limitation of the SHA256 API compared to
the apr_sha1 API is that the sha1 api has two update methods, whereas
the sha2 version has just one:
- apr_sha1_update_binary(&inner, keypad, HMAC_BLOCKSIZE);
- apr_sha1_update(&inner, data, datalen);
+ apr__SHA256_Update(&inner, keypad, HMAC_BLOCKSIZE);
+ apr__SHA256_Update(&inner, (const unsigned char*) data, datalen);
(Although I must say I'm not completely clear if the distinction
between char and unsigned char is actually important here... casting
seems to work just fine.)
Cheers,
Dirkjan
Re: SHA2 in APR
Posted by Nick Kew <ni...@apache.org>.
On 6 Nov 2013, at 07:37, Dirkjan Ochtman wrote:
> On Wed, Oct 16, 2013 at 5:57 PM, Dirkjan Ochtman <dj...@apache.org> wrote:
>> Well, the alternatives are (a) relying on an extra dependency for my
>> Apache module, probably NSS or OpenSSL or both, or (b) pulling in a
>> semi-random copy of SHA2 from the internet and including that. If APR
>> already included a maintained version of SHA2 (and it looks like it
>> already does, except it's not exposed to external users), that would
>> definitely make things easier for me.
>
> Ping! Is this essentially of the table?
I had a brief look, and concluded it could rapidly lead to a lot of work.
An even briefer look just now in response to your ping suggests
I was missing your point, and that all you're asking for is that
random/unix/sha2.h be exposed in the public API. Is that correct?
I would guess this code has never been tested, though there's
what looks like a placeholder in testpass.c. Have you run it
at all? How well does it work for you if you just copy sha2.h
manually to your APR include directory and use it for your module?
--
Nick Kew
Re: SHA2 in APR
Posted by Dirkjan Ochtman <dj...@apache.org>.
On Wed, Oct 16, 2013 at 5:57 PM, Dirkjan Ochtman <dj...@apache.org> wrote:
> Well, the alternatives are (a) relying on an extra dependency for my
> Apache module, probably NSS or OpenSSL or both, or (b) pulling in a
> semi-random copy of SHA2 from the internet and including that. If APR
> already included a maintained version of SHA2 (and it looks like it
> already does, except it's not exposed to external users), that would
> definitely make things easier for me.
Ping! Is this essentially of the table?
Cheers,
Dirkjan
Re: SHA2 in APR
Posted by Dirkjan Ochtman <dj...@apache.org>.
On Wed, Oct 16, 2013 at 5:17 PM, Nick Kew <ni...@apache.org> wrote:> OK,
that raises two questions:
> 1. From your point of view, how useful would a fully-implemented
> apr_sha2 be, compared either to using a third-party library or a
> standalone implementation?
Well, the alternatives are (a) relying on an extra dependency for my
Apache module, probably NSS or OpenSSL or both, or (b) pulling in a
semi-random copy of SHA2 from the internet and including that. If APR
already included a maintained version of SHA2 (and it looks like it
already does, except it's not exposed to external users), that would
definitely make things easier for me.
> 2. If it does add value, is the API referenced in your bug exactly
> what you want, or might there be mileage in reviewing/extending it?
Given that the API seen in Doxygen [1] is quite similar to the API
already exposed for sha1 (which for some reason doesn't appear at
http://apr.apache.org/docs/apr-util/1.5/, although it certainly
installed on my Linux box through dev-libs/apr-util-1.5.2), I'm quite
confident it's sufficient.
(So I only just discovered that the sha1 implementation we're using is
in APR-util, not APR itself; not sure how that changes things.)
Cheers,
Dirkjan
[1] http://ci.apache.org/projects/httpd/trunk/doxygen/sha2_8h.html
Re: SHA2 in APR
Posted by Nick Kew <ni...@apache.org>.
On 10 Oct 2013, at 21:49, Dirkjan Ochtman wrote:
> Hi,
Sorry, missed your post; just caught it in Jeff's reply.
> I've been hanging out in #apr on Freenode recently, but it appears the
> intersection of people hanging out there and active APR committers is
> pretty much the empty set.
That'll depend on who was around/awake/attentive at the time.
> I recently filed
> https://issues.apache.org/bugzilla/show_bug.cgi?id=55520 and I wonder
> if people had actually seen that.
Yes - now.
> The reason I've recently gotten interested in APR (and SHA support) is
> my work on https://github.com/mozilla/mod_authn_persona.
OK, that raises two questions:
1. From your point of view, how useful would a fully-implemented
apr_sha2 be, compared either to using a third-party library or a
standalone implementation?
2. If it does add value, is the API referenced in your bug exactly
what you want, or might there be mileage in reviewing/extending it?
It's not really clear to me what value an APR wrapper adds to sha2.
Or indeed, md5/sha1, beyond their being widely used by existing apps.
--
Nick Kew