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

Cleanup "restricted" crypto support

    Details

    • Type: Enhancement
    • Status: Closed
    • Priority: P4
    • Resolution: Won't Fix
    • Affects Version/s: 8
    • Fix Version/s: None
    • Component/s: security-libs
    • Labels:
      None

      Description

      This is a SUNBUG entry for https://bugs.openjdk.java.net/show_bug.cgi?id=100062

      Description

      Created an attachment (id=79) [details]
      Cleanup "restricted" crypto support

      There is still a lot of cruft in the codebase for preventing the usage of
      certain crypto algorithms or key-sizes. And we were actually shipping
      restricted policies preventing people from using unlimited crypto. Oops.

      So if you saw: "java.securityInvalidKeyException: Illegal key size or default
      parameters" that was caused by wrongly installed security policy files. The
      code was actually there, just not properly activated.

      This patch cleans up the crypto code so it doesn't go out of its way to prevent
      usage of "restricted crypto" and makes sure no restricted crypto security
      policies are installed. It removes all the unneeded classes like JarVerifier
      (that didn't actually do anything) and JceSecurityManager (that did all the
      unnecessary tricky class loader stack walking stuff) and reduces the
      JceSecurity class to just the method getInstance() and the static field RANDOM
      for the shared SecureRandom instance.

      For now I also kept the canUseProvider() method, that can now just return true.
      This last one was kept because the SecretKeyFactory, KeyGenerator, Mac and
      KeyAgreement classes still call it. It could be removed completely but I wanted
      to keep something that in principle could be easily used for some closed
      proprietary version that still insists on this "restricted crypto" thing.

      I believe this is now pretty clean. And it should be simple to verify that it
      works correctly now since all unnecessary code is just thrown out. Of course I
      threw all the crypto and security tests at it that I could find and all happily
      passed. I did alter the TestUtil class so that it always checks all algorithms
      and full keys.

      It would be nice to push this in OpenJDK proper so there is less divergence and
      so the GPLed version always has full crypto support enabled.

      This has been in production use for over a year now through IcedTea on various
      GNU/Linux distros and so should be pretty well tested.

      See also the discussions on the mailinglists:
      http://mail.openjdk.java.net/pipermail/security-dev/2008-August/000283.html
      http://mail.openjdk.java.net/pipermail/security-dev/2008-September/000329.html
      http://mail.openjdk.java.net/pipermail/security-dev/2008-November/000385.html

      Comment #1

      Discussion started June 2009 in security-dev (at) openjdk (dot) java (dot) net.

      http://mail.openjdk.java.net/pipermail/security-dev

      Comment #2

      The actual mail seems to be:

      http://mail.openjdk.java.net/pipermail/security-dev/2009-June/000916.html

      Is there any more progress on this?

      Comment #3

      (In reply to comment #2)
      > The actual mail seems to be:
      >
      > http://mail.openjdk.java.net/pipermail/security-dev/2009-June/000916.html
      >
      > Is there any more progress on this?

      There has been no further discussion, after my query how to get the patch into
      a form that is acceptable to Brad. But some cleanup work has been done by
      others: http://hg.openjdk.java.net/jdk7/build/jdk/rev/fe61ef5aada9
      I haven't investigated yet how much overlap there is with my cleanup patch.
      And there seems to be no public record/discussion on the above commit.

      Comment #4

      That change is mine. I wanted to see how much we were able to remove before
      continuing the thread. There is some overlap, but not as much as you would
      have hoped for.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                wetmore Bradford Wetmore
                Reporter:
                tbell Tim Bell
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: