[FFmpeg-devel] [PATCH 07/10] checkasm: add tests for AES
gajjanag at mit.edu
Wed Oct 14 00:24:14 CEST 2015
On Tue, Oct 13, 2015 at 6:16 PM, Henrik Gramner <henrik at gramner.com> wrote:
> On Tue, Oct 13, 2015 at 11:58 PM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
>> On Tue, Oct 13, 2015 at 5:55 PM, Henrik Gramner <henrik at gramner.com> wrote:
>>> On Tue, Oct 13, 2015 at 11:28 PM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
>>>> Not really that important, but unless this increases FATE time
>>>> significantly, I would recommend a much larger MAX_COUNT, and multiple
>>>> iterations (e.g #define an ITER_COUNT), so that the testing is more
>>>> extensive over random inputs.
>>> Each count is in the order of microseconds, but with this kind of
>>> algorithm I don't see how just iterating over a larger buffer will
>>> increase the chance of finding any issues.
>> The random stream will be of longer length, providing more bytes of
>> data over which aes runs (and thereby covering more bit patterns).
>> This was my motivation.
> That certainly makes sense in some cases but it doesn't really apply
> here IMO since there's no specific bit pattern in the input buffer
> that could trigger a different behavior such as overflows etc. (unless
> you're trying to find flaws in the AES-NI instructions themselves, but
> that seems pretty far fetched).
Thanks for the explanation - I forgot this was using the CPU crypto,
and not an algorithm (in which case my point has slightly more
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel