Thanks David - I agree, this looks like a viable solution. Thanks for
the feedback!
On Thu, Dec 11, 2008 at 1:21 PM, David Jencks <[EMAIL PROTECTED]> wrote:
> IIUC you have a couple functions that don't require any state
>
> Data encrypt(Algorithm, Data)
> and
> Data decrypt(Algorithm, Data)
>
> and you want to turn these into partially applied functions with Algorithm
> specified elsewhere:
> Algorithm = MyAlgorthm
> Data encrypt(Data) { encrypt(MyAlgorithm, Data) }
> Data decrypt(Data) {decrypt(MyAlgorithm, Data) }
>
> It looks to me that in the absence of language support for partially applied
> functions these sets of functions would belong to different classes, the
> second delegating to an instance of the first.
>
> Maybe I've been spending too much time learning scala but this design still
> seems to make sense to me in java.
>
> thanks
> david jencks
>
> On Dec 11, 2008, at 9:45 AM, Les Hazlewood wrote:
>
>> 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?
>>>>>
>>>>>
>>>>
>>>
>
>
