[Feature Request] SHA-1 HMAC

[Feature Request] SHA-1 HMAC

[Kyle Sanderson]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

Forgive my ignorance, but would it be possible to include SHA-1 HMAC into
musl? I'm not really sure if there's a list of functionality that's
prohibited from a libc; hopefully this is an acceptable request. I have a
single HMAC key that I use to sign multiple hashes with. I'm using
PolarSSL's implementation at the moment and I'd like to eliminate the
requirement.

Thanks,
Kyle.

[-- Attachment #2: Type: text/html, Size: 444 bytes --]

Re: [Feature Request] SHA-1 HMAC

[Rich Felker]

On Fri, Oct 25, 2013 at 09:36:12AM -0600, Kyle Sanderson wrote:
> Forgive my ignorance, but would it be possible to include SHA-1 HMAC into
> musl? I'm not really sure if there's a list of functionality that's
> prohibited from a libc; hopefully this is an acceptable request. I have a
> single HMAC key that I use to sign multiple hashes with. I'm using
> PolarSSL's implementation at the moment and I'd like to eliminate the
> requirement.

Hi. The conditions for something to go into libc are pretty stringent;
otherwise, it would be called libeverything. :-)

- Anything mandated by the current version of one of the relevant
  standards (ISO C or POSIX) goes in without question.

- Things with major historical precedent or presence in obsolete
  standards are pretty sure to get included unless there's a strong
  reason against inclusion.

- Modern BSD or GNU extensions that are widely used and not
  unreasonably costly to add generally get included.

It sounds like what you're asking for is the addition of a new
interface with no existing precedent, in which case, libc is really
not the appropriate place for it. However, I think you can implement
SHA-1 in just a few lines of code and include it with your project
rather than depending on large libraries. Busybox has a very light,
simple implementation you could copy; it's under GPLv2, but the code
is by Rob Landley and I imagine he would relicense it under BSD/MIT
for you if you need a less restrictive license. The original code it
was based on was public domain, so you could also just go back to
that. See libbb/hash_md5_sha.c in the Busybox source for details.

Rich

RE: [Feature Request] SHA-1 HMAC

[Alain Toussaint]

> Busybox has a very light, simple implementation you could copy; it's under
GPLv2, but the 
> code is by Rob Landley and I imagine he would relicense it under BSD/MIT
for you if you need 
> a less restrictive license. The original code it was based on was public
domain, so you could 
> also just go back to that. See libbb/hash_md5_sha.c in the Busybox source
for details.

I don't think it's possible to relicense Busybox as BSD/MIT as it stand but
Rob Landley is working on a replacement toolset to Busybox which is called
toybox and is indeed under a BSD license.

> Rich

Alain

Re: [Feature Request] SHA-1 HMAC

[Rich Felker]

On Fri, Oct 25, 2013 at 05:08:20PM -0400, Alain Toussaint wrote:
> > Busybox has a very light, simple implementation you could copy; it's under
> GPLv2, but the 
> > code is by Rob Landley and I imagine he would relicense it under BSD/MIT
> for you if you need 
> > a less restrictive license. The original code it was based on was public
> domain, so you could 
> > also just go back to that. See libbb/hash_md5_sha.c in the Busybox source
> for details.
> 
> I don't think it's possible to relicense Busybox as BSD/MIT as it stand but
> Rob Landley is working on a replacement toolset to Busybox which is called
> toybox and is indeed under a BSD license.

I think the relevant code is all his so he could relicense it.

Rich

Re: [Feature Request] SHA-1 HMAC

[Rob Landley]

On 10/25/2013 11:00:06 AM, Rich Felker wrote:
> It sounds like what you're asking for is the addition of a new
> interface with no existing precedent, in which case, libc is really
> not the appropriate place for it. However, I think you can implement
> SHA-1 in just a few lines of code and include it with your project
> rather than depending on large libraries. Busybox has a very light,
> simple implementation you could copy; it's under GPLv2, but the code
> is by Rob Landley and I imagine he would relicense it under BSD/MIT
> for you if you need a less restrictive license. The original code it
> was based on was public domain, so you could also just go back to
> that. See libbb/hash_md5_sha.c in the Busybox source for details.

I'm way way behind on email, but the toybox implementation of md5/sha1  
is essentially public domain (BSD license without any "copy this  
license into your derivatives" clause). I've been pushing code into  
busybox for years, but I wrote this is the first place for toybox, and  
they replaced their old version with mine because mine's simpler, and  
implements both sha1 and md5sum in the same file:

http://landley.net/hg/toybox/file/tip/toys/lsb/md5sum.c

FYI.

(And if you didn't have the reply-to: header in the list, the original  
poster would have been cc'd on my reply all. Oh well.)

Rob

Re: [Feature Request] SHA-1 HMAC

[Daniel Cegiełka]

Hi Kyle

 Adding HMAC to musl doesn't make sense. This is only one C file, so
why you just don't want to keep this in the sources of your software?

Daniel

Re: [Feature Request] SHA-1 HMAC

[Szabolcs Nagy]

* Daniel Cegie?ka <daniel.cegielka@gmail.com> [2013-10-25 21:23:03 +0200]:
>  Adding HMAC to musl doesn't make sense. This is only one C file, so
> why you just don't want to keep this in the sources of your software?

including a source file is not optimal

putting crypto primitives in a library makes perfect sense

the place for this is not libc but a crypto library like
libopenssl, libtomcrypt, libgcrypt, etc

unfortunately most of these are not well-structured or
well-maintained which is important for crypto code

there are various high quality but half baked solutions
(like nacl of djb or the kripto lib that came up on this
list earlier, neither of them are widely used/deployed)

Re: [Feature Request] SHA-1 HMAC

[Rich Felker]

On Sat, Oct 26, 2013 at 02:28:48PM +0200, Szabolcs Nagy wrote:
> * Daniel Cegie?ka <daniel.cegielka@gmail.com> [2013-10-25 21:23:03 +0200]:
> >  Adding HMAC to musl doesn't make sense. This is only one C file, so
> > why you just don't want to keep this in the sources of your software?
> 
> including a source file is not optimal

I think whether this is the case depends a lot on what you're doing.
One question I always recommend asking is which will be larger and
more work to maintain: the copied code, or the library glue? For use
of a single hash function from a crypto lib with a complex API, just
the glue code to setup and call the crypto lib is probably as large as
the hash code. Then you have to consider also the build system. At
this point we haven't even started considering the potential space for
bugs, issues if someone uses a different implementation of the
original crypto lib as a drop-in replacement for it (common with
openssl), etc.

So I think in this specific case, including the source file may
actually be the optimal solution.

Rich

Re: [Feature Request] SHA-1 HMAC

[Kyle Sanderson]

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

Thanks for the replies! The reason why I thought it would be cool to have
SHA1-HMAC included was I had thought SHA1 was included (in the crypt/
folder). However, now that I look at it again, it's actually SHA2, which
makes the whole request bad :( I'll try my hand at porting the code from
Busybox.

Thanks for the kind responses!
Kyle.


On Sat, Oct 26, 2013 at 12:38 PM, Rich Felker <dalias@aerifal.cx> wrote:

> On Sat, Oct 26, 2013 at 02:28:48PM +0200, Szabolcs Nagy wrote:
> > * Daniel Cegie?ka <daniel.cegielka@gmail.com> [2013-10-25 21:23:03
> +0200]:
> > >  Adding HMAC to musl doesn't make sense. This is only one C file, so
> > > why you just don't want to keep this in the sources of your software?
> >
> > including a source file is not optimal
>
> I think whether this is the case depends a lot on what you're doing.
> One question I always recommend asking is which will be larger and
> more work to maintain: the copied code, or the library glue? For use
> of a single hash function from a crypto lib with a complex API, just
> the glue code to setup and call the crypto lib is probably as large as
> the hash code. Then you have to consider also the build system. At
> this point we haven't even started considering the potential space for
> bugs, issues if someone uses a different implementation of the
> original crypto lib as a drop-in replacement for it (common with
> openssl), etc.
>
> So I think in this specific case, including the source file may
> actually be the optimal solution.
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 2090 bytes --]