<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Sure, it is dependent on the algorithm. So it is the case also in
      the case of <tt>gcry_mac_handle </tt>which then internally uses
      a union for the different algorithm types. <tt>gcry_md_handle </tt>uses
      different approach by adding space at the end of the struct
      depending on the algorithm. <br>
    </p>
    <p>So my question would be why we don't use one of these existing
      approaches for APIs as well for the KEM API.<br>
    </p>
    <p>I think the union approach used in the case of the MAC API is
      much more transparent then the approach taken for the hash API and
      would be my recommendation for the KEM API. Overly large
      reservations in the struct for specific KEM algorithms can be
      prevented by the algorithm specific code allocating heap memory
      for them during the open() call.</p>
    <p>- Falko<br>
    </p>
    <div class="moz-cite-prefix">Am 18.10.23 um 11:21 schrieb Werner
      Koch:<br>
    </div>
    <blockquote type="cite" cite="mid:87wmvkwajn.fsf@jacob.g10code.de">
      <pre class="moz-quote-pre" wrap="">On Wed, 18 Oct 2023 11:00, Falko Strenzke said:

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">hash functions, MAC, etc. Or is there a specific reason to make the
type obscure specifically in this case?
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Yes, because they depend on the algorithm.  Opaque things should ise a
void pointer to avoid unnecessary casting.  Remember that we are doing C
and not C++.


Salam-Shalom,

   Werner

</pre>
    </blockquote>
    <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>