libgcrypt integration into OSS-Fuzz differential cryptography fuzzer

[Guido Vranken]

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. 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?

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?

Thanks

Guido

On Wed, May 8, 2019 at 9:48 PM Jussi Kivilinna <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20190508/122b7339/attachment.html>