> -----Original Message----- > From: linux-crypto-owner@xxxxxxxxxxxxxxx <linux-crypto-owner@xxxxxxxxxxxxxxx> On Behalf Of Pascal Van Leeuwen > Sent: Thursday, July 4, 2019 10:37 AM > To: linux-crypto@xxxxxxxxxxxxxxx > Cc: Eric Biggers <ebiggers@xxxxxxxxxx>; Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > Subject: testmgr fuzzing for AEAD ciphers > > Hi, > > I was attempting to get some fuzzing going for the RFC3686 AEAD ciphers I'm adding to the > inside-secure driver, and I noticed some more things besides what I mentioned below: > > 1) If there is no test suite, but the entry does point to something other then alg_test_null, > then fuzzing is still not performed if there is no test suite, as all of the alg_test_xxx routines > first check for suite->count being > 0 and exit due to count being 0 in this case. > I would think that if there are no reference vectors, then fuzzing against the generic > implementation (if enabled) is the very least you can do? > > 2) The AEAD fuzzing routine attempts to determine the maximum key size by actually > scanning the test suite. So if there is no test suite, this will remain at zero and the AEAD > fuzzing routine will still exit without performing any tests because of this. > Isn't there a better way to determine the maximum key size for AEAD ciphers? > > 3) The AEAD fuzzing vector generation generates fully random keydata that is <= maxlen. > However, for AEAD ciphers, the key blob is actually some RTA struct containing length > fields and types. Which means that most of the time, it will simply be generating illegal > key blobs and you are merely testing whether both implementations correctly flag the > key as illegal. (for which they likely use the same crypto_authenc_extractkeys > subroutine, so that check probably/likely always passes - and therefore is not very useful) > I just confirmed the last point by adding some pr_info statements: Even though I advertise 10 AEAD cipher suites, I have the fuzzing tests enabled with the default iter count and the fuzzing tests are actually started, NONE of the generated vectors actually hits the point where an actual encryption is being performed, they ALL fail on illegal keys. In other words: nothing relevant is tested at all by the fuzzing tests. Actually I tried to be "smart" and loop the random key generation until a valid key was generated. Which caused some nice softlock :-) Which is when I realized that with 8 bytes of RTA header (i.e. 2^64 combo's) and only a handful of legal values thereof, the odds of hitting a legal value are far less than winning the main price in the local lottery ;-) Ánd generating legal values is actually not so trivial if you don't know the actual cipher and authentication key sizes supported ... Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com
