[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
