|
Message-ID: <CAOPXC2kYu7WxcRAqT-Ni=hYwJkxreSEvMRh7vsVap=e4VjcVjg@mail.gmail.com> Date: Mon, 29 Apr 2013 19:35:03 +0200 From: Gregor Pintar <grpintar@...il.com> To: musl@...ts.openwall.com Subject: Re: High-priority library replacements? 2013/4/29, Szabolcs Nagy <nsz@...t70.net>: > * 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) Devs that ignore return values would probably ignore documentation too. > 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 Encrypting more than 2^(block size) / 2 of blocks is broken too.
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.