Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8212051

KeyAgreement#generateSecret is not reset for ECDH based algorithm

    Details

    • Type: CSR
    • Status: Closed
    • Priority: P2
    • Resolution: Approved
    • Fix Version/s: 12
    • Component/s: security-libs
    • Labels:
      None
    • Subcomponent:
    • Compatibility Kind:
      behavioral
    • Compatibility Risk:
      low
    • Compatibility Risk Description:
      Hide
      Calling generateSecret() multiple times without calling doPhase() in between will no longer work after this change, and will result in an exception. There is no reason to call generateSecret() multiple times in this way, and we have no evidence that this is done commonly in client code. Any client code impacted by this change will need to be modified.
      Show
      Calling generateSecret() multiple times without calling doPhase() in between will no longer work after this change, and will result in an exception. There is no reason to call generateSecret() multiple times in this way, and we have no evidence that this is done commonly in client code. Any client code impacted by this change will need to be modified.
    • Interface Kind:
      Java API
    • Scope:
      SE

      Description

      Summary

      Correct the implementation of ECDH in SunEC so that it resets itself after each secret is derived. Clarify the correct behavior in the spec of KeyAgreement and KeyAgreementSpi.

      Problem

      According to the spec of KeyAgreement.generateSecret, this method must reset the object so that it can be used in future key agreement operations. This means that the public key and any information produced by the previous key agreement operations must be cleared, so future calls to generateSecret() must fail. The "ECDH" service in the SunEC provider does not reset the object, so subsequent calls to generateSecret will succeed, and will return the same secret.

      Solution

      Modify the implementation so that generateSecret() clears the public key, requiring a call to doPhase() before the generateSecret() can be called again. If generateSecret() is called incorrectly, an IllegalStateException will be thrown.

      The spec of KeyAgreement and KeyAgreementSpi will also be clarified so that the correct behavior is obvious. This is not a change to the specification.

      Specification

      In javax.crypto.KeyAgreement and javax.crypto.KeyAgreementSpi, all generateSecret overloads have a short paragraph at the end of the Javadoc that describes how the object will be reset. This paragraph reads:

       * <p>This method resets this {@code KeyAgreement} object, so that it
       * can be reused for further key agreements. Unless this key agreement is
       * reinitialized with one of the {@code init} methods, the same
       * private information and algorithm parameters will be used for
       * subsequent key agreements.

      Replace this paragraph with the following (substituting KeyAgreementSpi for KeyAgreement, as appropriate):

       * <p>This method resets this {@code KeyAgreement} object to the state that
       * it was in after the most recent call to one of the {@code init} methods.
       * After a call to {@code generateSecret}, the object can be reused for
       * further key agreement operations by calling {@code doPhase} to supply
       * new keys, and then calling {@code generateSecret} to produce a new
       * secret. In this case, the private information and algorithm parameters
       * supplied to {@code init} will be used for multiple key agreement
       * operations. The {@code init} method can be called after
       * {@code generateSecret} to change the private information used in
       * subsequent operations.

      Also replace the documentation related to the IllegalStateException:

       * @exception IllegalStateException if this key agreement has not been
       * completed yet

      with this:

        * @exception IllegalStateException if this key agreement has not been
        * initialized or if {@code doPhase} has not been called to supply the
        * keys for all parties in the agreement 

      The complete spec diff is attached.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                apetcher Adam Petcher (Inactive)
                Reporter:
                bnallakaluva Bharath Nallakaluva (Inactive)
                Reviewed By:
                Sean Mullan
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: