From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3213 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Thu, 25 Apr 2013 21:51:14 -0400 Message-ID: <20130426015114.GP20323@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 1366941086 21349 80.91.229.3 (26 Apr 2013 01:51:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Apr 2013 01:51:26 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3217-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 26 03:51:31 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 1UVXou-00025w-CA for gllmg-musl@plane.gmane.org; Fri, 26 Apr 2013 03:51:28 +0200 Original-Received: (qmail 21510 invoked by uid 550); 26 Apr 2013 01:51:27 -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 20478 invoked from network); 26 Apr 2013 01:51:27 -0000 Content-Disposition: inline In-Reply-To: <20130426005545.GA7923@Caracal> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3213 Archived-At: On Thu, Apr 25, 2013 at 05:55:45PM -0700, idunham@lavabit.com wrote: > > I am working on cryptographic library. It's far from being finished. > > I would be very glad, if someone could look at it. > > Currently I have problems with API design so help would be welcome. > > It isn't in git yet. > > You can get it here: > > https://dl.dropboxusercontent.com/u/83450675/kripto/kripto.tar.gz > > I have plans for SSL library on top of it, but it could take years. > > 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. > 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.) > -You have to finish it. > Consider the case of gcrypt, which is a GNU project with multiple > contributors, but still doesn't implement enough to make LDAP over SSL > work in all cases (I don't know the exact issue, but it's a standing bug > in Debian.) > > And you have to write a good API. When someone else has a library with > that, you may be better off using it. > 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. Yes. Crypto is hard to get right and when there's an implementation with high-quality public domain code, I think you'd need a really strong justification for using a new crypto implementation in an SSL library. > > I think best way is not to trust any certificate authority. > > Maybe some certificate p2p protocol could be done? > > Not really an option for regular SSL, I'm afraid. > (just due to the standards, and the need for getting it going...) > But something along the lines of OpenBGP (I think that's the name; it's > a BSD-licensed PGP library) would be one place to start if you wanted > that. > It would be interesting if the library transparently handles both SSL > and something along those lines, so someone gets the certificate p2p > stuff for free by using the library. Yes, I don't really know what the future directions will be, I just think a library should be prepared to adapt to changing needs for how we determine trust. > > > - Have absolutely zero global state. > > There is no global state and there won't be any. > > Sounding good, and looking good from what I saw. (Although I tend to > dislike "magic number tables", but that's mainly personal taste... > Also, don't consider me an authority on C or programming. I know some, > but far too little.) If you dislike magic number tables, you can always include a script in the build process to generate them. Using tens or hundreds of kb per process and tons of startup time however is not an acceptable solution to "I dislike magic number tables". Like them or not, magic number tables are the only non-bloated solution. Rich