I'm writing/cleaning up the cipher stuff to work as a CipherService with essentially the same API as before, but it will also support streaming operations. One important change I've made thus far is that the CipherService implementations will _not_ have a default encryption/decryption key like they did previously.
I made this decision based on the CipherService API: I created this interface originally to mirror the mathematical concept of a cipher, which accepts a key for each operation. Now, if the implementation has a default key, then the caller doesn't know whether or not to supply one. It is rather odd to have a method argument in the method signature, and use a default value if not supplied at runtime - very odd-feeling contract. So I've removed the default key inside the implementation and pushed the burden of maintaining a default to the CipherService caller if they want one. For example, the DefaultRememberMeManager can specify a default key upon instantiation. So there's still a default in Shiro, but it's just not located in the CipherService itself. Any objections? Thoughts? - Les
