One clarification - my design of the existing Cipher interface was based on my mathematical understanding of what a cipher does, and I wrote the interface to reflect the mathematical semantics.
When I created the issue I was second guessing this as the 'nice' approach for end users - again, always looking to JSecurity to do what is simplest for end users. But by having a StatefulCipher or KeyStoringCipher or whatever, we obtain the same thing while retaining backwards compatibility. That's probably the way to go. I'm just looking for opinions :) On Thu, Dec 11, 2008 at 12:38 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > Just a final note - what you suggest - a StatefulCipher or something > similar would definitely accomplish what I desire, and I'd be just > fine using something like that. I was only bringing up my previous > email for discussion. > > Plus the added benefit of a separate interface is that we retain > backwards compatibility, although I don't think it is a big deal since > we only offer a BlowfishCipher implementation today. > > My email was really prompted by looking to support X.509 certificates > used to acquire the key for RSA encryption/decryption. But again, > your recommendation would work just fine (StatefulCipher). > > I'm more just feeling out to see what folks think... > > On Thu, Dec 11, 2008 at 12:34 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: >> Really? You envision that the majority of Cipher users would want to >> pass a Key in for every invocation? >> >> If we're talking about simplicity, then I don't think that is the >> case. I think that the large majority of users of a Cipher would want >> this to happen: >> >> 1. Choose an algorithm implementation >> 2. Set their key somewhere (once) >> 3. call encrypt/decrypt whenever they feel like it on that instance. >> >> Of course, under the hood, the encryption/decryption operation is >> stateless because the JDK API is written that way, but the 'state' >> held in the implementation would be the key only, and then we pass it >> to the JDK API for each call. >> >> I'm assuming there would be a much smaller percentage of Cipher >> end-users that actually want to specify the key each time. In fact, I >> think it would be an extremely rare case that most Cipher end-users of >> the world would ever do that. Every encryption-enabled application >> I've ever come across usually stores this stuff (public key, etc) in >> file that is read once at startup, or more often (unfortunately), as >> constants in a Java class. This means, from my own gathering of >> course, that most people want to 'set and forget' this stuff. >> >> If you're configuring a Cipher instance in a DI framework, I think it >> would make much more sense to set the key as a property for the large >> majority of end users. You don't feel the same? >> >> On Thu, Dec 11, 2008 at 12:04 PM, Jeremy Haile <[EMAIL PROTECTED]> wrote: >>> I always found the storing of the key inside of the cipher object to feel >>> strange. I guess Cipher's just "feel" stateless to me. So - having two >>> interfaces for this feels like it'd be more confusing to a new user and >>> over-engineering. >>> >>> If anything, seems like the default implementation should be stateless with >>> a subclass that is stateful - not the reverse. It feels more natural to >>> have a Cipher interface with a subinterface called StatefulCipher or >>> KeyStoringCipher rather than the other way around. >>> >>> Just my opinion... >>> >>> >>> On Dec 11, 2008, at 11:57 AM, Les Hazlewood wrote: >>> >>>> I just created this issue: https://issues.apache.org/jira/browse/JSEC-36 >>>> >>>> Any objections? Thoughts? >>> >>> >> >
