From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3239 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Mon, 29 Apr 2013 08:09:01 -0400 Message-ID: <20130429120901.GX20323@brightrain.aerifal.cx> References: <20130425041553.GA13951@brightrain.aerifal.cx> <20130426005545.GA7923@Caracal> <20130429101620.GG12689@port70.net> 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 1367237351 16844 80.91.229.3 (29 Apr 2013 12:09:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Apr 2013 12:09:11 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3243-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 29 14:09:15 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 1UWmtP-0003yn-3d for gllmg-musl@plane.gmane.org; Mon, 29 Apr 2013 14:09:15 +0200 Original-Received: (qmail 4032 invoked by uid 550); 29 Apr 2013 12:09:14 -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 4024 invoked from network); 29 Apr 2013 12:09:13 -0000 Content-Disposition: inline In-Reply-To: <20130429101620.GG12689@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3239 Archived-At: On Mon, Apr 29, 2013 at 12:16:20PM +0200, Szabolcs Nagy wrote: > * Gregor Pintar [2013-04-26 10:11:32 +0200]: > > 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). > > > > i'm not sure about the flexibility part > > it is good when you want to have the same api > for a wide range of algorithms and you want > to be able to fiddle with their internal settings > > but in my opinion this adds many failure modes > which is bad > > i never liked that in tomcrypt, openssl etc trivial > functions have error code return values which > should never fail > > (eg hash_update(ctx, buf, len) should never fail > even if there is a counter in ctx that can overflow > every 2^64th bit of input, documenting the behaviour > for longer inputs is better, it would be even better > if the apropriate standards were more careful about > failures) This is a really good point. Hashing and encryption should fundamentally be able to deal with arbitrary inputs and should not require resource allocation to do their job. As such, they should have no failure cases. Decryption of course has the failure case where the input is malformed, but should not have any other failure cases. Rich