You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Sander Striker <st...@samba-tng.org> on 2001/06/05 01:54:05 UTC
[PATCH] apr-util hmac md5
Hi,
This patch adds HMAC MD5 to apr-util.
Functions:
APU_DECLARE(apr_status_t) apr_hmac_md5_init(apr_hmac_md5_ctx_t *context,
const unsigned char *key,
apr_size_t keyLen);
APU_DECLARE(apr_status_t) apr_hmac_md5_update(apr_hmac_md5_ctx_t *context,
const unsigned char *input,
apr_size_t inputLen);
APU_DECLARE(apr_status_t) apr_hmac_md5_final(unsigned char
digest[MD5_DIGESTSIZE],
apr_hmac_md5_ctx_t *context);
APU_DECLARE(apr_status_t) apr_hmac_md5(unsigned char digest[MD5_DIGESTSIZE],
const unsigned char *key,
apr_size_t keyLen,
const unsigned char *input,
apr_size_t inputLen);
The algorithm is pretty straightforward and I needed it anyway.
I used RFC2104 as a guide.
It probably needs some looking over. Also the doc comments are a bit
dense (I'm a bit to tired to come up with any good ones).
Thx,
Sander
PS. If someone is looking into MD5, maybe MD5_DIGESTSIZE can be changed to
APR_MD5_DIGESTSIZE, like in the md4 code (which has APR_MD4_DIGESTSIZE).
Re: [PATCH] apr-util hmac md5
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
raaay, good for sander.
HMAC_MD5 is used in NTLMv2 security to help guarantee
against replay attacks on different sessions
[NTLMv2 doesn't stop replay attacks on the _same_ session :)]
HMAC_xxx is used to generate one-way hashes from secret
keys and public data, basically. if you have to one-way
hash, it's pretty much O(N ^^ -128) likely that you will
be able to obtain the secret key.
sander, just a thought: would it be possible for to write
a general HMAC_xx that accepts an xx?
and then HMAC_MD5 being a specialisation of that?
or, is it simply worth saying,well, uh, if you're gonna
do that, forget it: use openssl.
?
On Tue, Jun 05, 2001 at 07:34:33PM +0100, Ben Laurie wrote:
> Justin Erenkrantz wrote:
> >
> > On Tue, Jun 05, 2001 at 01:54:05AM +0200, Sander Striker wrote:
> > > Hi,
> > >
> > > This patch adds HMAC MD5 to apr-util.
> >
> > Where would we use this? Is this algorithm of sufficient usage that it
> > would benefit being in apr-util? I've never heard of HMAC before - I
> > had to look it up on rfc-editor.org. Maybe I live in a paper bag.
>
> Please be assured that you _do_ live in a paper bag. HMACs are good
> things if you care about security. :-)
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html
>
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
Re: [PATCH] apr-util hmac md5
Posted by Ben Laurie <be...@algroup.co.uk>.
Justin Erenkrantz wrote:
>
> On Tue, Jun 05, 2001 at 01:54:05AM +0200, Sander Striker wrote:
> > Hi,
> >
> > This patch adds HMAC MD5 to apr-util.
>
> Where would we use this? Is this algorithm of sufficient usage that it
> would benefit being in apr-util? I've never heard of HMAC before - I
> had to look it up on rfc-editor.org. Maybe I live in a paper bag.
Please be assured that you _do_ live in a paper bag. HMACs are good
things if you care about security. :-)
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
RE: [PATCH] apr-util hmac md5
Posted by Sander Striker <st...@samba-tng.org>.
> On Tue, Jun 05, 2001 at 01:54:05AM +0200, Sander Striker wrote:
> > Hi,
> >
> > This patch adds HMAC MD5 to apr-util.
>
> Where would we use this? Is this algorithm of sufficient usage that it
> would benefit being in apr-util? I've never heard of HMAC before - I
> had to look it up on rfc-editor.org. Maybe I live in a paper bag.
It is keyed MD5 :-)
Probably not in heavy use, but I'm gonna need it.
> I'd just like to make sure that someone is using this before it gets
> committed. I'd like to prevent feature creep (we're so beyond that
> point). Here's my line in the sand... =) I'll cast a -0 on this
> patch (I can do that, right?).
>
> I guess the distinction between what we have in apr-util and what is in
> OpenSSL is that the code is *probably* more portable (IIRC, OpenSSL
> sort of works on Win32 - correct me if I'm wrong). Sander, I think
> OpenSSL's portability *might* be an issue for you as you often use
> Win32. I don't use Win32 so I wouldn't know.
Well, I'm not that big a win32 fan :-). It's just that since I started
looking into apr(-util) I really liked the true portability of it. I must
admit that I didn't really look into OpenSSL that good to report on
portability issues. I just figured: hey, apr-util has got a crypto
directory, I'm missing some stuff that I'm going to need, so lets send
in a patch. I also have to say that I am not a big fan of having multiple
dependencies, if I can get away with just apr and apr-util I would be
very pleased. Also, I like the apr interface... Just my fl 0,02
> Personally, I'd defer to what Ralf and Ben have to say about this - I
> think they both are on the APR lists (in case you don't know - they are
> also OpenSSL core members). I think Ben posted a "What's up with this
> crypto stuff?" message in the last day or so. Well, *I* am not sure
> how the crypto stuff fits in either. So, time to get some feedback.
Ok, agreed. Btw, I'll be submitting patches along the way and I'd like
to see them make it into apr(-util). However, if the patches are denied
I have no problem in that, then I'll just move the code to my local
codebase. I'll just post what seems reusable, because I'm a bad judge
at that (in samba you encounter weird stuff of which you sometimes don't
know if someone else uses it).
> My $.02:
>
> I would be inclined that the more popular stuff (md5 and sha1) be
> included so that they are always present, but the more esoteric stuff
> can stay in OpenSSL. If you need those odd crypto functions, then you
> need to figure out where OpenSSL is to link against, or start
> submitting patches to them to get it to work. I'm not sure that APR
> needs to be a general purpose crypto library - OpenSSL does a decent
> enough job as-is (from what I've been told). Since OpenSSL is under
> an Apache-style license, there shouldn't be any problem using their code.
I'll look into it.
> Thoughts? *I* want to hold off on adding more crypto until I know what
> others think and we have a coherent plan for crypto/. Hence, my -0.
> I think that adding the link requirement of OpenSSL under all cases to
> httpd will be troublesome (i.e. if we use OpenSSL for SHA1). But,
> when Ralf et al get around to cleaning up the mod_ssl/mod_tls stuff,
> we might have a good way to detect/link against OpenSSL (so, we'd
> remove crypto/ entirely from apr-util). I'm not in a position to add
> external build requirements. That's a mighty big thing which needs to
> be well thought out.
Ack.
>> PS. If someone is looking into MD5, maybe MD5_DIGESTSIZE can be
>> changed to APR_MD5_DIGESTSIZE, like in the md4 code (which has
>> APR_MD4_DIGESTSIZE).
>
> Yeah, I should do that, shouldn't I? One of these days... -- justin
:-)
Sander
Re: [PATCH] apr-util hmac md5
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Tue, Jun 05, 2001 at 01:54:05AM +0200, Sander Striker wrote:
> Hi,
>
> This patch adds HMAC MD5 to apr-util.
Where would we use this? Is this algorithm of sufficient usage that it
would benefit being in apr-util? I've never heard of HMAC before - I
had to look it up on rfc-editor.org. Maybe I live in a paper bag.
I'd just like to make sure that someone is using this before it gets
committed. I'd like to prevent feature creep (we're so beyond that
point). Here's my line in the sand... =) I'll cast a -0 on this
patch (I can do that, right?).
I guess the distinction between what we have in apr-util and what is in
OpenSSL is that the code is *probably* more portable (IIRC, OpenSSL
sort of works on Win32 - correct me if I'm wrong). Sander, I think
OpenSSL's portability *might* be an issue for you as you often use
Win32. I don't use Win32 so I wouldn't know.
Personally, I'd defer to what Ralf and Ben have to say about this - I
think they both are on the APR lists (in case you don't know - they are
also OpenSSL core members). I think Ben posted a "What's up with this
crypto stuff?" message in the last day or so. Well, *I* am not sure
how the crypto stuff fits in either. So, time to get some feedback.
My $.02:
I would be inclined that the more popular stuff (md5 and sha1) be
included so that they are always present, but the more esoteric stuff
can stay in OpenSSL. If you need those odd crypto functions, then you
need to figure out where OpenSSL is to link against, or start
submitting patches to them to get it to work. I'm not sure that APR
needs to be a general purpose crypto library - OpenSSL does a decent
enough job as-is (from what I've been told). Since OpenSSL is under
an Apache-style license, there shouldn't be any problem using their code.
Thoughts? *I* want to hold off on adding more crypto until I know what
others think and we have a coherent plan for crypto/. Hence, my -0.
I think that adding the link requirement of OpenSSL under all cases to
httpd will be troublesome (i.e. if we use OpenSSL for SHA1). But,
when Ralf et al get around to cleaning up the mod_ssl/mod_tls stuff,
we might have a good way to detect/link against OpenSSL (so, we'd
remove crypto/ entirely from apr-util). I'm not in a position to add
external build requirements. That's a mighty big thing which needs to
be well thought out.
> PS. If someone is looking into MD5, maybe MD5_DIGESTSIZE can be changed to
> APR_MD5_DIGESTSIZE, like in the md4 code (which has APR_MD4_DIGESTSIZE).
Yeah, I should do that, shouldn't I? One of these days... -- justin