On 30/01/2015 1:27 a.m., Niels Möller wrote:
> Amos Jeffries writes:
>
>> I have added a fuzz tester that runs a set of randomly generated strings
>> past the default encoder and decoder, then the extended one.
>
> Nice. It would be good with a couple of short manual examples as well. A
> pity that RFC 4648 doesn't include any testvectors for base64url. (Or am
> I missing something? Simon?)
>
>> - if you have a better random generator you would like to use please
>> let me know where to find a code example or docs for it.
>
> I'd suggest using lfib_knuth generator in nettle. And maybe you already
> to that, but it's good to randomize also the length of the data.
>
Aha. Thank you. I missed that in the docs. (Kudos to the person who
designed that function set, its probably the most lovely I've seen in a
long while.)
Yes I was randomizing the length, which actually turned out to be the
assert problem. rand()%N-4 [vs. rand()%(N-4)] will eventualy become
negative and break tha stack. The consistency in the face of changing
seed values has also confirmed my aversion to staying with rand() for
the final version.
It would seem worthwhile adding some additional compiler flags to add
things like stack protectors specifically for the unit tests to catch
other mistakes like mine.
>> The test and the coders seem to be working fine. Except that when I
>> increase the *count* of fuzz test run it asserts regular as clockwork on
>> the 950th loop:
>>
>> base64-test: base64-encode.c:96: _base64_encode_raw: Assertion `in ==
>> src' failed.
>
> This needs investigation. Have you run the tests under valgrind? ("make
> check EMULATOR='$(VALGRIND)'")?
>
>> Do you wish me to remove base64_encode_group entirely?
>
> No, not at this time (it's used in one place, in the unfinished openpgp
> code).
>
> Regards,
> /Niels
>
Okay. v3 patch about to follow.
Amos
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
