From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3221 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Fri, 26 Apr 2013 11:47:29 -0400 Message-ID: <20130426154728.GQ20323@brightrain.aerifal.cx> References: <20130425041553.GA13951@brightrain.aerifal.cx> <20130426005545.GA7923@Caracal> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1366991258 9547 80.91.229.3 (26 Apr 2013 15:47:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Apr 2013 15:47:38 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3225-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 26 17:47:43 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 1UVksA-0002KZ-TF for gllmg-musl@plane.gmane.org; Fri, 26 Apr 2013 17:47:43 +0200 Original-Received: (qmail 28652 invoked by uid 550); 26 Apr 2013 15:47:42 -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 28626 invoked from network); 26 Apr 2013 15:47:41 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3221 Archived-At: On Fri, Apr 26, 2013 at 10:11:32AM +0200, Gregor Pintar wrote: > 2013/4/26, idunham@lavabit.com : > > I hate to be the one who says this, but... > > Why another crypto library? > > There are at least 6 I can think of off the top of my head > > (openssl crypto, gcrypt, nettle, tomcrypt, gpg, openbgp) > > and I know that's not even half of them. > > tomcrypt is already good (as Rich mentioned), so code quality isn't > > a reason. > Most of them are realy bad (support only few ciphers, ugly API, > inflexible, license). > tomcrypt is good, but it has some global states (ltc_cipher_descriptor, ...) Yes, this is stupid, but I don't think there's any reason to use it. Can't you just use the extern descriptor for the cipher you want directly? In any case, I agree that when using tomcrypt the register and unregister functions should be nop'd out and the cipher_descriptor array replaced with a const version thereof. There may be more changes needed to fix it too, but that sounds like most of it. > > While writing your own "xyz" may be a good learning experience and fun > > and so on, a crypto library faces some restrictions: > > -You will need to fix bugs promptly until you hand over maintainership. > > (Otherwise, you become responsible when there's a vulnerability that > > stays unfixed.) > Not really a problem for me. > BTW, latest official stable tomcrypt release was released in 2007. Yes, that's because it's already very mature.. :) BTW, a big plus of that is that it would be safe to fork tomcrypt and fix any issues in it that aren't going to get fixed upstream, like global state, since maintaining a fork of a mature but clean codebase is almost no work. > > What Rich asked about was an SSL lib based on an existing crypto lib, > > namely tomcrypt. And that is likely to be a quicker path to results. > tomcrypt is definitely quicker path. Note that there's no reason the crypto implementation couldn't later be replaced if there's an option better than tomcrypt. Rich