From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3257 Path: news.gmane.org!not-for-mail From: Gregor Pintar Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Tue, 30 Apr 2013 11:58:26 +0200 Message-ID: References: <20130425041553.GA13951@brightrain.aerifal.cx> <20130426005545.GA7923@Caracal> <20130429101620.GG12689@port70.net> <20130429215500.GJ12689@port70.net> <20130430021014.GC20323@brightrain.aerifal.cx> <20130430083516.GK12689@port70.net> 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 1367315920 7058 80.91.229.3 (30 Apr 2013 09:58:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Apr 2013 09:58:40 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3261-gllmg-musl=m.gmane.org@lists.openwall.com Tue Apr 30 11:58:40 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 1UX7KZ-0002SH-7X for gllmg-musl@plane.gmane.org; Tue, 30 Apr 2013 11:58:39 +0200 Original-Received: (qmail 22419 invoked by uid 550); 30 Apr 2013 09:58:38 -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 22408 invoked from network); 30 Apr 2013 09:58:38 -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=JkBxK04UEKyXuXOKZr8MyMvKRNZmzaGDSrX2nclgiSQ=; b=bkrVtjdd8WgrRJ2tJ70O0MrjVssgxjSrjEJSyRbZnDxFryTEJk3w6GGEPVz0C7oP04 vtjeFx7yb3sJHwQsQYMH5d7+9ve9q7+F1WeslzMgEKfnyaedp5pMhMKQTuZdUBasbJ/U VY7cUbFdOBUaihRfe1cEgPxdMQu61/vU1DhikgQlGA5TbhQBswpm7OBJBrVe8zgsMEcT /uSTC9Ze7/MRrPcn9diDk73S6VeTBGT7NB6Etom0Yq6UiDwU/3b8xw82BtUxigbtdUZ7 VPVnzcD8mIrNE6Rq0CakWp3h97Pzwgk6v7b+T9XyoC4IDZihs2RUs6gOkwAEeQe/24Fe +WUw== X-Received: by 10.180.183.139 with SMTP id em11mr1830861wic.16.1367315906642; Tue, 30 Apr 2013 02:58:26 -0700 (PDT) In-Reply-To: <20130430083516.GK12689@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:3257 Archived-At: 2013/4/30, Szabolcs Nagy : > * Gregor Pintar [2013-04-30 08:32:26 +0200]: >> My idea was that program would be correct, if it inputs too much data >> to hash function. It is very cheap to implement in most algorithms >> (detect counter overflow). Otherwise program has to count it himself. > > i dont think the program has to count > > eg in case of sha1 if you know that the throughput is less than > 10gbps then it takes more than 50years to overflow > Blowfish can encrypt max 128GB. > in theory there might be use-cases where the overflow could occure > in which case reporting error makes sense, but it seems to me that > can be avoided by the proper choice of algorithm or reasonable > application design > Choice of algorithm is not mine. > of course if you allow configurability of the block size and rounds > etc then the overflow becomes a practical concern so the error is > justified, which is why i said that flexibility is not necessarily > a good thing (general interface requires general error handling) > Block size isn't configurable (but algorithms have different block size). Rounds can cause error only on *_create() (so does key). Flexibility usually increases complexy. >> However, in most cases it is too late to handle correctly when it >> already fails. Not returning error on too much input or output could >> silently cause incorrect usage. Using assert might be better idea >> since at that point it is fatal anyway, but that would cause data >> leak, unless program would catch SIGABRT (it should others like SIGINT >> anyway) and wipe data, but that requires all sensitive data in program >> is global. > > i'd let the user do the bad thing (silently overflow) > if it matters it can be designed around in the application >