From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3236 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Mon, 29 Apr 2013 12:16:20 +0200 Message-ID: <20130429101620.GG12689@port70.net> 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 1367230589 7274 80.91.229.3 (29 Apr 2013 10:16:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Apr 2013 10:16:29 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3240-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 29 12:16:34 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 1UWl8L-0000pl-Q7 for gllmg-musl@plane.gmane.org; Mon, 29 Apr 2013 12:16:33 +0200 Original-Received: (qmail 32352 invoked by uid 550); 29 Apr 2013 10:16:32 -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 32344 invoked from network); 29 Apr 2013 10:16:32 -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:3236 Archived-At: * 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) the way it is done in most crypt apis make most of the code that use them broken: they don't check the return value so if the function may fail the code is broken, or they check but never test the failure path so the code is broken for a different reason my preference would be to have a well documented, clean highlevel api with minimal amount of failure modes (no error code return value), and a flexible api with ugly names for those who like to fiddle with internals