<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p class="source-line" data-source-line="69">There is one feature of
Libgcrypt’s MAC API that in my opinion can be a certain security
risk for applications.</p>
<p class="source-line" data-source-line="71">Take for instance the
HMAC verification:</p>
<pre><code>static gcry_err_code_t
hmac_verify (gcry_mac_hd_t h, const unsigned char *buf, size_t buflen)
{
unsigned int dlen;
const unsigned char *digest;
dlen = _gcry_md_get_algo_dlen (h->u.hmac.md_algo);
digest = _gcry_md_read (h->u.hmac.md_ctx, h->u.hmac.md_algo);
if (buflen > dlen)
return GPG_ERR_INV_LENGTH;
return buf_eq_const (buf, digest, buflen) ? 0 : GPG_ERR_CHECKSUM;
}
</code></pre>
<p class="source-line" data-source-line="89">If there a MAC is
provided to the verify
function that is shorter than the regular MAC length, the
verification
succeeds if that shorter MAC is matching the start of the regular
MAC.<br>
</p>
<p class="source-line" data-source-line="89">The risk for
applications is that if a client application is just handing
through an attacker controlled MAC value together with its length,
then attacks are possible if the size of the MAC can be controlled
by the attacker in the protocol. (Zero-length MAC are caught by
the higher level API functions.) It would be more conservative to
enforce
the full length of the MAC in the verification function and allow
shortened MACs only as specific variant algorithms.</p>
<p class="source-line" data-source-line="96">I tested this and
actually the only MAC verification that I found that doesn’t
accept MACs of size one is that of the GMAC algorithm.</p>
<p class="source-line" data-source-line="98">- Falko<br>
</p>
<p></p>
<div class="moz-signature">-- <br>
<!-- MTG AG HTML signature v.1.0 - Messen 2022, 2022-03-14 - Author: Andreas Cholet -->
<p style="line-height: 1.1;"><font face="Arial"><span
style="font-size: small; color: rgb(93, 93, 95);">
<strong>MTG AG</strong><br>
Dr. Falko Strenzke<br>
Executive System Architect<br>
<!--up to here--> </span></font></p>
<font face="Arial">
<p>
<span style="font-size: small; color: rgb(93, 93, 95);">
<span style="display:inline-block;width:4em">Phone: </span>+49
6151 8000 24<br>
<span style="display:inline-block;width:4em">E-Mail: </span><a class="moz-txt-link-abbreviated" href="mailto:falko.strenzke@mtg.de">falko.strenzke@mtg.de</a><br>
<span style="display:inline-block;width:4em">Web: </span><a
href="https://www.mtg.de" title="MTG AG Internet"
target="_blank">mtg.de</a><br>
<br>
<br>
</span></p>
<font face="Arial">
<hr
style="width:320px; text-align:left;margin-left:0; height: 0,1px">
</font>
<p style="line-height: 1.2;"><font face="Arial">
<span style="font-size: x-small; color: rgb(93, 93, 95);">
MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany<br>
Commercial register: HRB 8901<br>
Register Court: Amtsgericht Darmstadt<br>
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz<br>
Chairman of the Supervisory Board: Dr. Thomas Milde<br>
<br>
This email may contain confidential and/or privileged
information. If you are not the correct recipient or have
received this email in error,
<br>
please inform the sender immediately and delete this
email. Unauthorised copying or distribution of this email
is not permitted.<br>
<br>
Data protection information: <a
href="https://www.mtg.de/en/privacy-policy"
title="MTG Privacy policy" target="_blank">Privacy
policy</a>
</span></font></p>
</font></div>
</body>
</html>