From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3218 Path: news.gmane.org!not-for-mail From: Gregor Pintar Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Fri, 26 Apr 2013 10:11:32 +0200 Message-ID: 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=UTF-8 X-Trace: ger.gmane.org 1366963901 31710 80.91.229.3 (26 Apr 2013 08:11:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Apr 2013 08:11:41 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3222-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 26 10:11:45 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 1UVdku-0005Gv-Bz for gllmg-musl@plane.gmane.org; Fri, 26 Apr 2013 10:11:44 +0200 Original-Received: (qmail 3227 invoked by uid 550); 26 Apr 2013 08:11:43 -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 3219 invoked from network); 26 Apr 2013 08:11:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=xhGdy0c39af4UXX4UKlF+ZPMF7m4303Ho0NZpkyPjC8=; b=d2uu/4dAb/lOX4D4MX7Cs0kh5mAC0IzBS1ZGL7j232jivO1eu7jS+0Giz/6ApHqcaO m6dmRTZh3fABFdjAMhe3ysmrv9M9VhpGhEAQ/Wt/5LokOOEtmCMY+e677vub665h+K9F G0Sza5QEA3tkk2oZQGzjno51XYivQCrkBhAgx1DtvD/tiFeMucERhMsgdaM5LeCgcFoK v5406ymzfqh8h5eyHj5rZDiCil3x4jHxIlHiUkWsoFRCAlZMbBTghMJCnMHjHxcDnxB9 J2BOyHkNqZmk2Zac72UtGpKbuAoiFg+CDE+L92Xpu6DzsmviHS5onV0V+kaRfxK2glvg 9QaQ== X-Received: by 10.194.109.136 with SMTP id hs8mr80716719wjb.8.1366963892313; Fri, 26 Apr 2013 01:11:32 -0700 (PDT) In-Reply-To: <20130426005545.GA7923@Caracal> Xref: news.gmane.org gmane.linux.lib.musl.general:3218 Archived-At: 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, ...) and I want even more flexible library (variable rounds, no global state). I would like API that allows replacing ciphers very easy. For example: allways use kripto_stream_encrypt(), if you use any block cipher in any mode or stream cipher directly. Also my hash API supports variable length output (great for sponge constructions). > 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. > -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.) I am trying to do it very extensible. > And you have to write a good API. When someone else has a library with > that, you may be better off using it. That is the hardest. API better than tomcrypts is my goal. I also plan stable ABI. > 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. >> 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. I know, it was more like an long-term idea.