You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Les Hazlewood <lh...@apache.org> on 2008/12/11 17:57:51 UTC
Cipher Refactoring
I just created this issue: https://issues.apache.org/jira/browse/JSEC-36
Any objections? Thoughts?
Re: Cipher Refactoring
Posted by Les Hazlewood <lh...@apache.org>.
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 <da...@yahoo.com> 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 <lh...@apache.org>
>> 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 <lh...@apache.org>
>>> 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 <jh...@fastmail.fm>
>>>> 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?
>>>>>
>>>>>
>>>>
>>>
>
>
Re: Cipher Refactoring
Posted by Jeremy Haile <jh...@fastmail.fm>.
Yeah, that approach feels much more natural to me. The StatefulCipher
may not even need to know what the underlying Cipher is - it just
holds the stateful part (the key or whatever).
It's delegation vs inheritance - in this case, delegation feels more
appropriate.
On Dec 11, 2008, at 1:21 PM, David Jencks 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 <lhazlewood@apache.org
>> > 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 <lhazlewood@apache.org
>>> > 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
>>>> <jh...@fastmail.fm> 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?
>>>>>
>>>>>
>>>>
>>>
>
Re: Cipher Refactoring
Posted by David Jencks <da...@yahoo.com>.
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
> <lh...@apache.org> 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 <lhazlewood@apache.org
>> > 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
>>> <jh...@fastmail.fm> 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?
>>>>
>>>>
>>>
>>
Re: Cipher Refactoring
Posted by Les Hazlewood <lh...@apache.org>.
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 <lh...@apache.org> 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 <lh...@apache.org> 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 <jh...@fastmail.fm> 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?
>>>
>>>
>>
>
Re: Cipher Refactoring
Posted by Les Hazlewood <lh...@apache.org>.
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 <lh...@apache.org> 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 <jh...@fastmail.fm> 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?
>>
>>
>
Re: Cipher Refactoring
Posted by Les Hazlewood <lh...@apache.org>.
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 <jh...@fastmail.fm> 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?
>
>
Re: Cipher Refactoring
Posted by Jeremy Haile <jh...@fastmail.fm>.
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?