On Tue, Oct 13, 2015 at 6:16 PM, Henrik Gramner <hen...@gramner.com> wrote: > On Tue, Oct 13, 2015 at 11:58 PM, Ganesh Ajjanagadde <gajja...@mit.edu> wrote: >> On Tue, Oct 13, 2015 at 5:55 PM, Henrik Gramner <hen...@gramner.com> wrote: >>> On Tue, Oct 13, 2015 at 11:28 PM, Ganesh Ajjanagadde <gajja...@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 validity). > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
