libgcrypt integration into OSS-Fuzz differential cryptography fuzzer

[Jussi Kivilinna]

On 8.5.2019 22.58, Guido Vranken wrote:
> While we're on the subject, can you comment on which ciphers/cipher modes allow for "chunked updating"? Eg. if you have a cleartext of 16 bytes, when is it allowed to call gcry_cipher_encrypt with the first 10 bytes, then another 3 bytes, then the final 3 bytes (for example)? I've been noticing a host of wrong outputs if I allow "chunked updating" with libgcrypt.

Following modes should work with "chunked updating":
    GCRY_CIPHER_MODE_STREAM
    GCRY_CIPHER_MODE_OFB
    GCRY_CIPHER_MODE_CTR
    GCRY_CIPHER_MODE_CFB
    GCRY_CIPHER_MODE_CCM
    GCRY_CIPHER_MODE_GCM
    GCRY_CIPHER_MODE_EAX
    GCRY_CIPHER_MODE_POLY1305

ECB and CBC require input length in multiples of cipher blocksize.

For XTS input length can be from 16 to 16*2^20 bytes. 

OCB requires first N-1 input buffer lengths to be multiples of cipher blocksize. Before last input buffer 'gcry_cipher_final()' needs to be called and last Nth input buffer does not have restriction on input size.

> The documentation states "Depending on the selected algorithms and encryption mode, the length of the buffers must be a multiple of the block size." but this doesn't make it clear when it is allowed exactly. And should the function not just fail if chunked input is attempted when full blocks are expected?

Modes that do not accept chunked input return error.

> 
> Also, I consistently get the error message "selftest for CFB failed - see syslog for details" both from git master and 1.8.4. Is this expected?

That is not expected. Which compiler and what kind of configuration are you using? Do you get these errors when running libgcrypt build tests, "make check"?

-Jussi

> 
> Thanks
> 
> Guido
> 
> On Wed, May 8, 2019 at 9:48 PM Jussi Kivilinna <jussi.kivilinna at iki.fi <mailto:jussi.kivilinna at iki.fi>> wrote:
> 
>     Hello,
> 
>     On 8.5.2019 16.31, Guido Vranken wrote:
>     > Hi,
>     >
>     > I've been building a differential cryptography fuzzer that has been finding some nice bugs in major cryptographic libraries: https://github.com/guidovranken/cryptofuzz#hall-of-fame
>     > It's very effective as it can find the Whirlpool bug (before 1.60.0) and the recent Stribog bug instantly.
>     >
>     > It finds errors in message digests like RipeMD160 in the current master branch that are not present in 1.8.4. I still have to research the cause.. I can post demonstration code later.
> 
>     Thanks! It looks like culprit commit is 46d7dbbc293fdc1e04656798b3e6f58873fee110 which breaks md4, md5 and rmd160. Quickly looking at code, this happens when input size is '64*nblks + 56..63'. Bug is at md4.c/md5.c/rmd160.c new code path "/* need one extra block */" and when writing bit count to buffer. Buffer offsets there should be "hd->bctx.buf + 56 + 64" and "hd->bctx.buf + 60 + 64". Other message digests modified in that commit appear to get this right.
> 
>     Bigger issue here is that there is quite big cap in testing coverage for digest finalization functions.. fuzzing against different libraries would definitely help.
> 
>     >
>     > It's running 24/7 on Google's OSS-Fuzz. Are the libgcrypt maintainers interested in participating in the OSS-Fuzz project? This entails that results for message digests, HMACs, CMACs and symmetric ciphers are compared to other libraries, and if there is a mismatch, everyone gets an e-mail. At that point we have to find out which library is emitting the wrong result, and the bug has to be fixed.
>     >
> 
>     I'd be interested getting emails of such mismatches.
> 
>     What do others think? Werner? Niibe?
> 
> 
>     -Jussi
>