Using Cryptix 3.0.3 for E Bill Frantz (frantz@communities.com)
Fri, 02 Oct 1998 11:00:18 -0700

For the Cryptix people, E is a secure distributed system based on Java which is available on an open source basis. For more information, see http://www.erights.org/

For the E people, we currently use JavaSoft's java.security package with the Sun provider, the java.math.BigInteger class, and the Cryptix 2.2 DES class for our communications security.

The current version of the E run time uses Diffie Hellman for key agreement, DSA for link startup authentication, a keyed HMAC based on SHA1 for message authentication, and DES-EDE/CBC for message privacy. Identities are the SHA1 hash of the DSA public key. As part of the connection startup protocol, each side sends the other its public key.

We have our own implementation of Diffie Hellman and CBC. We get DES-EDE by using Cryptix DES three times. These parts of the code should just keep working. With the Cryptix library, we can use the IJCE Cypher.getAlgorithms() static method, along with a property to dynamically build our list of supported protocols.

This works fine for symmetric encryption, but we do have a problem with public key. We need to send public keys over the wire. Neither JCE or IJCE have an interface for getting a PublicKey object from an encoded public key. Worse yet, the Cryptix implementations don't have code to convert the public key to a byte string, needed for both sending the key and generating an identity.

While the Javasoft official interface doesn't have a way of getting a public key from a encoded key, the Sun provider class sun.security.provider.DSAPublicKey has a public constructor which does the job. It takes a DER encoded structure which looks like:

seq{

seq{

      OID {1,3,14,3,2,12} // ISO code for DSA data
      SEQ{
         INT the DSA parameter P
         INT the DSA parameter Q
         INT the DSA parameter G
      }

}
BIT_STRING Y // The DSA public key
}

This structure is now a de facto part of our wire protocol. It does have the advantage that the OID specifies the public signature method, so if we introduce more than one method, the key is self identifying.

I would like the Cryptix people to consider two additions to their package:

(1) A way to get a PublicKey subclass of the correct type from a byte
stream encoded public key that doesn't require provider-specific code. (I don't require ASN1 coding, but I do think we should be compatible with the current Sun provider encoding.)

(2) Public key implementations which support encoding to self identifying
byte strings and decoding same.

I think we can do a DSA implementation, and since DSA is not an encryption algorithm, we can probably export it to be part of the Cryptix package.

Reactions?