On Wed, Nov 6, 2013 at 10:33 AM, Nick Kew <niq@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
|