Re: High-priority library replacements?

[Szabolcs Nagy <nsz@port70.net>]

* Gregor Pintar <grpintar@gmail.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)

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