[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOPXC2mdk397cWFkqAz4bJNo4_+fWBv-VupWCHJTLGuFawcFDw@mail.gmail.com>
Date: Tue, 30 Apr 2013 11:58:26 +0200
From: Gregor Pintar <grpintar@...il.com>
To: musl@...ts.openwall.com
Subject: Re: High-priority library replacements?
2013/4/30, Szabolcs Nagy <nsz@...t70.net>:
> * Gregor Pintar <grpintar@...il.com> [2013-04-30 08:32:26 +0200]:
>> My idea was that program would be correct, if it inputs too much data
>> to hash function. It is very cheap to implement in most algorithms
>> (detect counter overflow). Otherwise program has to count it himself.
>
> i dont think the program has to count
>
> eg in case of sha1 if you know that the throughput is less than
> 10gbps then it takes more than 50years to overflow
>
Blowfish can encrypt max 128GB.
> in theory there might be use-cases where the overflow could occure
> in which case reporting error makes sense, but it seems to me that
> can be avoided by the proper choice of algorithm or reasonable
> application design
>
Choice of algorithm is not mine.
> of course if you allow configurability of the block size and rounds
> etc then the overflow becomes a practical concern so the error is
> justified, which is why i said that flexibility is not necessarily
> a good thing (general interface requires general error handling)
>
Block size isn't configurable (but algorithms have different block
size). Rounds can cause error only on *_create() (so does key).
Flexibility usually increases complexy.
>> However, in most cases it is too late to handle correctly when it
>> already fails. Not returning error on too much input or output could
>> silently cause incorrect usage. Using assert might be better idea
>> since at that point it is fatal anyway, but that would cause data
>> leak, unless program would catch SIGABRT (it should others like SIGINT
>> anyway) and wipe data, but that requires all sensitive data in program
>> is global.
>
> i'd let the user do the bad thing (silently overflow)
> if it matters it can be designed around in the application
>
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.
