From: "Robert Feldt" <feldt / ce.chalmers.se>
> The right way is probably simply to do an ordinary class hierarchy (Cipher
> > ((BlockCipher > (Blowfish, ...)), (StreamCipher > ...) etc) and then
> have CSP as a sort of convenience API and different CSP subclasses
> collecting alg's of similar strength etc. Or have I totally misunderstood
> the CSP idea?

It gets more complex than that with crypto.  Not only do applications have
constraints on the crypto algorithms they can use, defined by IETF standards
for example, but users have constraints on the *implementations* of those
algorithms that they trust or are allowed to use by the organisations they
work for.  For example, a European comany might not trust US closed-source
crypto software or crypto hardware in case it had a backdoor to allow
commercial espionage by US agencies.

So a crypto framework needs to:

1) define the generic protocols used  by objects implementing crypto
algorithms (hashes, stream/block ciphers, public vs. private key crypto,
signatures, etc.).
2) define protocols for configuring each crypto algorithm separately from
any implementation of that algorithm.
3) provide a way for the user to tell the crypto framework which
implementation it must use for each algorithm
4) provide a way for the application to load and use an implementation of a
crypto algorithm by name, rather than by implementation, as specified by the
users' preferences.
4) providea implementations of crypto algorithms that conform to the
predefined protocols and can be loaded at runtime by an application.

That's why the programming interface to the Java Cryptography Extension is
so complex.

Cheers,
            Nat.