<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body>
    <p>Webrev updated:
      <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~valeriep/8172680/webrev.01/">http://cr.openjdk.java.net/~valeriep/8172680/webrev.01/</a></p>
    Thanks,<br>
    Valerie<br>
    <div class="moz-cite-prefix">On 3/19/2020 1:33 PM, Valerie Peng
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:80555c5a-b69e-654d-71d7-f6a48f836236@oracle.com">
      <p>Hi Bernd,</p>
      <p>Thanks for the comments~ Please find additional reply inline.<br>
      </p>
      <div class="moz-cite-prefix">On 3/18/2020 4:06 PM, Bernd Eckenfels
        wrote:<br>
      </div>
      <blockquote type="cite"
cite="mid:AM6PR03MB4389C21F2BF848D3CBFB57E6FFF70@AM6PR03MB4389.eurprd03.prod.outlook.com">
        <div dir="ltr">
          <div data-ogsc="">
            <div>
              <div>Hello Valerie.</div>
              <div><br>
              </div>
              <div>In MacKAT 121 you would get a NPE if the catch prints
                the skip message, probably needs an additional return;
                guard?</div>
            </div>
          </div>
        </div>
      </blockquote>
      <p>Good catch, will add a return.</p>
      <blockquote type="cite"
cite="mid:AM6PR03MB4389C21F2BF848D3CBFB57E6FFF70@AM6PR03MB4389.eurprd03.prod.outlook.com">
        <div dir="ltr">
          <div data-ogsc="">
            <div>
              <div><br>
              </div>
              <div>The BAOS default length change in parse() was not
                immediately clear to me? (Maybe next s. Base64?)</div>
            </div>
          </div>
        </div>
      </blockquote>
      <p>Some of the test values use ":" as a separator. When such
        separator is present, it takes a longer string to represent the
        same number of bytes. So, depending on whether the separator is
        used, the default number of bytes is calculated differently.</p>
      <blockquote type="cite"
cite="mid:AM6PR03MB4389C21F2BF848D3CBFB57E6FFF70@AM6PR03MB4389.eurprd03.prod.outlook.com">
        <div dir="ltr">
          <div data-ogsc="">
            <div>
              <div><br>
              </div>
              <div>BTW It is good to see that you also add truncated
                SHA512 variants. It's not mentioned in commit message or
                RFE.</div>
            </div>
          </div>
        </div>
      </blockquote>
      <p>Support for the truncated SHA512 variants is mainly done in a
        separate/earlier RFE, i.e. JDK-8051408 (<a
          class="moz-txt-link-freetext"
          href="https://bugs.openjdk.java.net/browse/JDK-8051408"
          moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8051408</a>).
        I only added the missing OIDs and the supporting classes, i.e.
        KeyGenerator for Hmac w/ truncated SHA512 variants. I can add a
        comment to the RFE to make this clear.<br>
      </p>
      <p>Regards,</p>
      <p>Valerie<br>
      </p>
      <blockquote type="cite"
cite="mid:AM6PR03MB4389C21F2BF848D3CBFB57E6FFF70@AM6PR03MB4389.eurprd03.prod.outlook.com">
        <div dir="ltr">
          <div data-ogsc="">
            <div>
              <div><br>
              </div>
              <div>hTH</div>
              <div>Bernd</div>
              <div><br>
              </div>
            </div>
            <div><br>
            </div>
            <div class="ms-outlook-ios-signature">
              <div><br>
              </div>
              <div>-- </div>
              <div><a class="moz-txt-link-freetext"
                  href="http://bernd.eckenfels.net"
                  moz-do-not-send="true">http://bernd.eckenfels.net</a></div>
            </div>
          </div>
        </div>
        <hr tabindex="-1">
        <div id="divRplyFwdMsg" dir="ltr"><b>Von:</b> security-dev <a
            class="moz-txt-link-rfc2396E"
            href="mailto:security-dev-bounces@openjdk.java.net"
            moz-do-not-send="true"><security-dev-bounces@openjdk.java.net></a>
          im Auftrag von Valerie Peng <a class="moz-txt-link-rfc2396E"
            href="mailto:valerie.peng@oracle.com" moz-do-not-send="true"><valerie.peng@oracle.com></a><br>
          <b>Gesendet:</b> Wednesday, March 18, 2020 11:57:37 PM<br>
          <b>An:</b> OpenJDK Dev list <a class="moz-txt-link-rfc2396E"
            href="mailto:security-dev@openjdk.java.net"
            moz-do-not-send="true"><security-dev@openjdk.java.net></a><br>
          <b>Betreff:</b> [15] RFR 8172680: Support SHA-3 based Hmac
          algorithms
          <div> </div>
        </div>
        <div class="BodyFragment"><span>
            <div class="PlainText"><br>
              Anyone has time to help review this straight forward RFE?
              It's to add <br>
              SHA-3 support to Hmac.<br>
              <br>
              RFE: <a
                href="https://bugs.openjdk.java.net/browse/JDK-8172680"
                moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8172680</a><br>
              <br>
              Webrev: <a
                href="http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/"
                moz-do-not-send="true">http://cr.openjdk.java.net/~valeriep/8172680/webrev.00/</a><br>
              <br>
              Mach5 run is clean.<br>
              <br>
              Thanks,<br>
              Valerie<br>
            </div>
          </span></div>
      </blockquote>
    </blockquote>
  </body>
</html>