Using Cryptix 3.0.3 for E

[Bill Frantz]

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?