From: "Frank Yellin" <Frank.Yellin@eng.sun.com>
To: "Jan Luehe" <Jan.Luehe@eng.sun.com>, <David.Brownell@eng.sun.com>
Subject: RE: FCS coming up?
Date: Tue, 9 Mar 1999 13:15:12 -0800
In-Reply-To: <libSDtMail.9903090957.9867.luehe@laguna>
I confess. I was originally getting ready to send a message complaining
about the assymmetry.
Why should decryption be treated any differently than encryption? If
encryption
gets to use default parameters, why should encryption. . .
Then I started to realize the logic of this. It does make sense to create a
random
initial value if one isn't provided. Random initial values make it harder
for
an eavesdropper to figure things out. . . . And SealedObject realizes that
it needs to
save the AlgorithmParameters in addition to the encryption.
I suppose I wish that there were some way of saying for both encryption and
decryption:
"Any algorithm parameter I don't provide, just set to the 'standard default
value' for
that algorithm, and don't bother me." Then I could just pass the encryption
bits.
As a partial aside, (relevance to soon be made obvious),
I think it would be nice if in the next version of JCE, DESKeySpec could
specify the IV vector.
One way to partially make up for DES's lack of adequate key space is to
include the IV as
part of the key. This doesn't work in the current implementation. Too
many built-in classes,
like SealedObject, save the algorithm parameter is clear text, since they
know it is needed
for decryption. It would be interesting to allow the SecretKey to
optionally override
the AlgorithmParameter. (Obviously, c.getparameter() would still have to
return the old value,
not the new value. It's overriding, not replacing)
== Frank