Right now we have a Java/jni package called symkey that does much of the low level symmetric key manipulation. The JNI was needed due to the intricate derivations that take place, which are not supported in JSS.

The C portion of this code has grown out of control and has some issues.

Here is the proposal:

1. Rewrite symkey entirely in Java. It could even be a part of TKS as a class.
2. Get rid of all the JNI native code that we use.
3. Beef up JSS to that it fully supports the "PK11_Derive" family of command in NSS.
   The main reason why we need the C code is to do those derivations. JSS should also be enhanced to do any other intricate operations done in symkey. These JSS calls should be able to use the full "WithFlags" variants of command families in use. This will allow for best security of the keys manipulated.

This has the following benefits.

1. The hardest stuff/JNI is left to JSS, which will enjoy the improvements.
2. The main logic can be kept in Java which is less prone to errors and memory constraints.
3. Implementing future secure channel protocols will simply make use of the new JSS PK11_Derive functionality

Other must haves for the new "symkey" or whatever form it takes:

1. Logic must be greatly simplified and refactored. Too much duplicated error prone code is used now.
2. All symkey commands used must be of the highest security with respect to the flags in use.
3. Of course FIPS must be preserved.
4. We must keep JSS updated to allow for any latest and greatest derivation mechanisms and key type that come down the pike. Often we can even drive this.