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? >> >> >
