<div dir="ltr"><div dir="ltr"><div dir="ltr">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?</div><div dir="ltr"><br></div><div>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?</div><div><br></div><div>Thanks</div><div><br></div><div>Guido<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 8, 2019 at 9:48 PM Jussi Kivilinna <<a href="mailto:jussi.kivilinna@iki.fi">jussi.kivilinna@iki.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
On 8.5.2019 16.31, Guido Vranken wrote:<br>
> Hi,<br>
> <br>
> I've been building a differential cryptography fuzzer that has been finding some nice bugs in major cryptographic libraries: <a href="https://github.com/guidovranken/cryptofuzz#hall-of-fame" rel="noreferrer" target="_blank">https://github.com/guidovranken/cryptofuzz#hall-of-fame</a><br>
> It's very effective as it can find the Whirlpool bug (before 1.60.0) and the recent Stribog bug instantly.<br>
> <br>
> 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.<br>
<br>
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. <br>
<br>
Bigger issue here is that there is quite big cap in testing coverage for digest finalization functions.. fuzzing against different libraries would definitely help.<br>
<br>
> <br>
> 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.<br>
> <br>
<br>
I'd be interested getting emails of such mismatches.<br>
<br>
What do others think? Werner? Niibe?<br>
<br>
<br>
-Jussi<br>
</blockquote></div>