12

I'm a little confused with how Java (6+) distributes its security framework. On one hand, you have the following packages (and their respective subpackages & types):

  • java.security.*
  • javax.security.*

And on the other hand you have java.lang.SecurityManager, and possibly other security-related types sprinkled in other non-security packages (like java.lang).

So, several questions:

  1. What is the difference between java.security and javax.security? When to use types in each?
  2. Besides java.lang, are there any other packages where security-centric types appear, and if so, what are they?
  3. Where do JCE and JCA fit in here? What packages do they comprise, or are they totally separate and in their own JARs?
halfer
  • 19,824
  • 17
  • 99
  • 186
IAmYourFaja
  • 55,468
  • 181
  • 466
  • 756
  • I'm not an expert about usage of these packages, but the question looks too broad. Have you searched for this before posting the question? – Luiggi Mendoza Nov 26 '13 at 15:04
  • Yes but there doesn't seem to be a good explanation to my 1st question. As for my 2nd question, it's like looking for a needle in a haystack: how do I comb the entire JRE for security-centric types, when I don't even know what I'm looking for. And after visiting the [JCE homepage](http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html) all they offer is to download some jurisdiction policy files, but not a JAR that contains actual types. This leads me to believe that the JCE is a part of the JRE, but don't see a package like "java.security.jce", etc. – IAmYourFaja Nov 26 '13 at 15:07
  • 1
    if your question is purely about the JCE, then the answer is "yes" it is included in the jre. – jtahlborn Nov 26 '13 at 15:09
  • Thanks @jtahlborn (+1) - But what about the [JCA](http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html). Also still wondering about #1 and #2 above. Thanks again! – IAmYourFaja Nov 26 '13 at 15:11
  • yes, the JCA is all included as well. – jtahlborn Nov 26 '13 at 15:12

1 Answers1

8

The split has mainly historical reasons. Once upon a time there were export restrictions on cryptographic software in the US.

As a rule of thumb: Stuff related to signatures is found in java.security, the rest (ciphers, ...) in javax.security.

The JRE nowadays comes with the standard security provider bundled in, so JCE is part of the platform.

Henry
  • 42,982
  • 7
  • 68
  • 84
  • Thanks @Henry (+1) - a few followups: (1) is the JCE and JCA one in the same, or are they different (and if so, how)? (2) Is the JCE itself an API (like JDBC, or JPA), or is it a reference implementation of a security API? If the latter, what is it a reference implementation of? And (3) anything else in the JRE besides java.security.*, javax.security.* and SecurityManager that is a part of the "security framework"? Thanks again! – IAmYourFaja Nov 26 '13 at 15:13
  • @TicketMonster - is there something specific you are trying to determine? – jtahlborn Nov 26 '13 at 15:16
  • 1
    Not an expert here but I think JCA is mainly a specification and JCE is an implementation of it. It is a plugin architecture so other security providers can be used as well under the hood of the framework. – Henry Nov 26 '13 at 15:23
  • 1
    The SecurityManager has a different purpose it is not related with cryptography but with the sandbox model of Java that allows to restrict certain operations (like file access) for untrusted code. – Henry Nov 26 '13 at 15:24
  • Ahhh, thanks again @Henry (+1 to all). So just to confirm: the JCA is the API, and the JCE is a reference impl of that API, just like [Legion of the Bouncy Castle](http://www.bouncycastle.org/) also provides an impl of it. So JCE and bouncy castle are "competing JCA implementations", if you will. Is this a fair assessment? Thanks again! – IAmYourFaja Nov 26 '13 at 15:28
  • bouncy castle was once a competing implementation, for later Java versions it is just a security provider and runs within the JCE framework. Plus some extras. – Henry Nov 26 '13 at 15:35