|
Message-ID: <20130429101620.GG12689@port70.net> Date: Mon, 29 Apr 2013 12:16:20 +0200 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: High-priority library replacements? * 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) 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
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.