[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130429120901.GX20323@brightrain.aerifal.cx>
Date: Mon, 29 Apr 2013 08:09:01 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: High-priority library replacements?
On Mon, Apr 29, 2013 at 12:16:20PM +0200, Szabolcs Nagy wrote:
> * Gregor Pintar <grpintar@...il.com> [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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
