<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html;

      charset=windows-1252">

  </head>

  <body>

    <p>On 2/20/2021 6:16 AM, Peter Gutmann wrote:<br>

    </p>

    <blockquote type="cite"

      cite="mid:1613830585412.93830@cs.auckland.ac.nz">

      <pre class="moz-quote-pre" wrap="">Kristian Gjøsteen <a class="moz-txt-link-rfc2396E" href="mailto:kristian.gjosteen@ntnu.no" moz-do-not-send="true"><kristian.gjosteen@ntnu.no></a> writes:

</pre>

      <blockquote type="cite" style="color: #007cff;">

        <pre class="moz-quote-pre" wrap="">The attacks on GCM-AES and similar constructions that we have seen discussed

here lately, almost always reduce to either key management or nonce

management.

</pre>

      </blockquote>

      <pre class="moz-quote-pre" wrap="">And that would be one reason why you don't want to use TLS with a OTP.  We

can't even get working with 128-256 bits of key + nonce right, how are we

going to deal with OTPs which are nothing but key?</pre>

    </blockquote>

    <p><br>

    </p>

    <p>Could be quite simple if you use the OTP as a source of shared

      secrets. Consider for example the "shared secret" variant of TLS.

      The client provides an identifier of the shared secret, which

      could be something like name of OTP + offset + length. Server

      recognizes that. Both get a set of bits from the OTP, then use the

      bits in TLS exactly the same way they could currently use a shared

      secret. Derive a master secret, and then key and nonce for your

      favorite AEAD algorithm using all the existing TLS machinery. Very

      little new code required.</p>

    <p>-- Christian Huitema<br>

    </p>

  </body>

</html>