CrytoService
			     ============

Version: $Id$

Its job is to provide SecurityService and potentially others with
common access to encryptions protocols. Currently I have three
different ones:

ClearCrypt - No encryption at all. Just returns the supplied clear
             text PW

JavaCrypt  - Access to all the Java MessageDigest ciphers as before

UnixCrypt  - Unix crypt(3) encryption supplied via cryptix.tools.UnixCrypt

The last one is only compiled if the cryptix32.jar is present in
lib. If it is not, it is not included. I use the same mechanism as
with castor or FreeMarker in the build.xml file and I tested both
presence and absence of the cryptix32.jar
I ripped out the whole MessageDigest stuff from the BaseSecurity
Service and wrapped that into CryptoAlgorithm objects which are
supplied by the CryptoService. This one can be configured from the
TRP. If you keep the default configuration, you get only the
MessageDigest ciphers.

One nice side effect is the fact that
"services.SecurityService.secure.passwords" becomes obsolete, because
setting it to "false" is equal to setting it to "true" and keeping
cleartext as the encryption algorithm for the security service. I
wrote a comment about this in the TRP.  This switch can go in a latter
revision of Turbine.

I gave this some basic testing (compiling with and without
cryptix32.jar). The patch works (with our inhouse, somehow modified)
turbine-2.jar and UnixCrypt passwords.

As I don't use cleartext and MessageDigest passwords anywhere, I would
have to set up a testbed. If anyone can give this a spin, please try
and tell me the result.