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