<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>There is another point to consider for the design of a generic
      KEM API: the use of the public in the key derivation, which makes
      it necessary to pass the public key to the decapsulation function
      if one doesn't want to run the computation of the public key from
      the private key in the decapsulation function. <br>
    </p>
    <p>We are using using this now for instance in our OpenPGP PQC draft
      (<a class="moz-txt-link-freetext" href="https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/66">https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/66</a> corrects
      the ECC-KEM function signature regarding that matter).</p>
    <p>- Falko<br>
    </p>
    <div class="moz-cite-prefix">Am 24.10.23 um 08:25 schrieb NIIBE
      Yutaka:<br>
    </div>
    <blockquote type="cite" cite="mid:875y2wwn7x.fsf@akagi.fsij.org">
      <pre class="moz-quote-pre" wrap="">Werner Koch <a class="moz-txt-link-rfc2396E" href="mailto:wk@gnupg.org"><wk@gnupg.org></a> wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">On Thu, 19 Oct 2023 16:37, NIIBE Yutaka said:

</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">gcry_error_t gcry_kem_decap (int algo,
                             const void *seckey,
                             const void *ciphertext,
                             void *shared_secret);
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">
I still don't feel comfortable without a size argument.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Assumption here (for lower level API) is:

        It's caller side (user of libgcrypt) which does static
        compile-time check against ALGO and the length of each
        byte-array.

        If not static, caller side can do run-time check, if needed,
        before the call.

Having a size argument would mean, 

        libgcrypt does run-time check of the length (for each call)

I wonder if this kind of run-time check in libgcrypt is useful in lower
level API.

I could imagine having an API offering static compile-time check.  In
this case, it would provide a macro something like gcry_kem_decap_check
which has length arguments.  The ABI is gcry_kem_decap.
</pre>
    </blockquote>
    <div class="moz-signature">-- <br>
      <!-- MTG AG HTML signature v.1.0, 2021-02-12 - Author: Andreas Cholet -->
      <p style="line-height: 1.5;"><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);">
            <!--personalize--><span
              style="display:inline-block;width:4em">Phone: </span>+49
            6151 8000 24<br>
            <!--personalize--><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>
          </span></p>
        <a
href="https://www.linkedin.com/search/results/all/?fetchDeterministicClustersOnly=true&heroEntityKey=urn%3Ali%3Aorganization%3A13983133&keywords=mtg%20ag&origin=RICH_QUERY_SUGGESTION&position=0&searchId=d5bc71c3-97f7-4cae-83e7-e9e16d497dc2&sid=3S5&spellCorrectionEnabled=false"
          title="Follow us on LinkedIn" target="_blank"
          rel="“noreferrer" noopener"="">
          <img data-filename="Li-in-Bug.png"
            src="cid:part1.VMegwQEU.vsIdoC6w@mtg.de"
            style="width:50px; margin-left:1px" width="50"></a><br>
        <span
style="font-size: small; color: rgb(93, 93, 95); margin-left: 1px">Follow
          us</span>
        <hr
style="width:340px; text-align:left;margin-left:0; height: 0,1">
        <a
href="https://www.mtg.de/de/aktuelles/MTG-AG-erhaelt-Innovationspreis-des-Bundesverbands-IT-Sicherheit-e.V-00001.-TeleTrust/"
          title="TeleTrusT Innovationspreis 2023" target="_blank"
          rel="“noreferrer" noopener"="">
          <img data-filename="Logo_Teletrust_innovationspreis_cut.jpg"
            src="cid:part2.Pe6it3we.I6FBDlQ1@mtg.de"
            style="width:210px; margin-left: 0px" width="210"></a>
        <a href="https://www.itsa365.de/de-de/companies/m/mtg-ag"
          title="Info it-sa 2024" target="_blank" rel="“noreferrer"
          noopener"="">
          <img data-filename="itsa.png"
            src="cid:part3.XDNQ60Te.k95ddpNv@mtg.de"
            style="width:115px; margin-left: 15px" width="115"></a><br>
        <font face="Arial"> </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>