From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4160 Path: news.gmane.org!not-for-mail From: Kyle Sanderson Newsgroups: gmane.linux.lib.musl.general Subject: Re: [Feature Request] SHA-1 HMAC Date: Sat, 26 Oct 2013 18:30:19 -0600 Message-ID: References: <20131026122848.GN1685@port70.net> <20131026183805.GP20515@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b2e090bd3cb9c04e9ae17ba X-Trace: ger.gmane.org 1382833853 29524 80.91.229.3 (27 Oct 2013 00:30:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Oct 2013 00:30:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4164-gllmg-musl=m.gmane.org@lists.openwall.com Sun Oct 27 02:30:58 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VaEFq-0000LC-J4 for gllmg-musl@plane.gmane.org; Sun, 27 Oct 2013 02:30:54 +0200 Original-Received: (qmail 5212 invoked by uid 550); 27 Oct 2013 00:30:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5204 invoked from network); 27 Oct 2013 00:30:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=RI1Gz7bHIchkS4uSrzNSyUgvZrmnPTaDEZvb6E1lcG8=; b=XXulaESppmhaoqW5X30ND5a78IrFlg3eLv4hTFzfMt/khDWPa0ODucZdbTpWA67bDD x3iZ2IzDWvGMbl1pW5Y2h+VsMEzHyci162pfw34UZMBh3RxzCuC/RZfIDFHJxGVphALJ qwZmqX/nEj10Bcvv1Ldpd9ZqsG1aMIEQVQrPBUK+vfp7ROukmrE/UhI0Nk6pA5UXusCY nnBT1Hr3iDDk3dne1VAEPwVZgTn/8aoZNUpDgXwjuKInYqw2Sig5IzmBF8j9PbGgZTsJ Ex0pbU66FY2tILpN4AmtuczuoJC2jUme7opyE0S6sobBP9HpGOUY3RISpR1uEwR+LoH+ ObcA== X-Received: by 10.68.216.132 with SMTP id oq4mr14178246pbc.50.1382833840178; Sat, 26 Oct 2013 17:30:40 -0700 (PDT) In-Reply-To: <20131026183805.GP20515@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:4160 Archived-At: --047d7b2e090bd3cb9c04e9ae17ba Content-Type: text/plain; charset=UTF-8 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 wrote: > On Sat, Oct 26, 2013 at 02:28:48PM +0200, Szabolcs Nagy wrote: > > * Daniel Cegie?ka [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 > --047d7b2e090bd3cb9c04e9ae17ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the replies! The reason why I thought it w= ould 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 act= ually SHA2, which makes the whole request bad :( I'll try my hand at po= rting 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 <dan= iel.cegielka@gmail.com> [2013-10-25 21:23:03 +0200]:
> > =C2=A0Adding HMAC to musl doesn't make sense. This is only on= e C file, so
> > why you just don't want to keep this in the sources of your s= oftware?
>
> including a source file is not optimal

I think whether this is the case depends a lot on what you're doi= ng.
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<= br> 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

--047d7b2e090bd3cb9c04e9ae17ba--