Date: Thu, 28 May 1998 10:49:36 -0700 (PDT)
From: Jan Luehe <Jan.Luehe@Eng>
Subject: Re: greetings from down under.
To: dgh@aba.net.au
Hi David:
> I've just hit a snag with the way IV's are currently being handled, the
> problems in two parts, one it looks like I'll need to try and talk to
> an older encryption mechanism, the other is it would be nice if there
> was some way of setting up a sealed object so all you need to decrypt
> it is the Key and the mode of the Cipher. I can work around this but
> it seems a shame to produce such kludgy code when everything else
> comes out quite elegantly. Details are below.
We were thinking along the same lines and propose the following
solution which will require minor API changes:
1. Add
public AlgorithmParameters getParameters()
and
public void init(int opmode, Key key, AlgorithmParameters params)
methods to the Cipher class. (The "AlgorithmParameters" class is
defined in the java.security package in JDK 1.2.)
2. In SealedObject, change
public Object getObject(Cipher c)
to
public Object getObject(Key key)
and
public Object getObject(Key key, String provider)
3. When you seal an object,
SealedObject will call the new "getParameters" method on the Cipher
object that you pass to its constructor,
and store the parameters along with the sealed object contents.
It will also store the Cipher's algorithm
(returned by Cipher.getAlgorithm()).
In order to unseal the object, all you need is the key and optionally
the name of the Cipher provider. The "getObject" method will
create an instance of Cipher (using the stored algorithm name and
optionally the specified provider) and initialize it with the key
and the stored parameters.
YOu should be able to see those changes in the upcoming JCE 1.2 beta
release.
>
> Apologies for dumping this on you personally, I tried posting to the
> archive last night and it bounced.
I am cc'ing java-security on my reply.
> ---------------------------------------------------------------------
>
> The JCE currently specifies that the initialisation vector for
> a Cipher *must* be passed in at initialisation.
>
> As far as I'm aware there are three ways of setting the IV in
> decryption mode.
>
> 1. pass it in on initialisation (the current one).
> 2. pass it in as the first block of the input.
> 3. pass it encrypted in the first block.
>
> This raises a couple of issues, how best to talk to other ciphers
> that pass the IV in the incoming stream using modes 2 and 3 (and they
> are out there), and also, for example, that it is currently
> impossible to unseal a SealedObject without knowing the IV if you've
> used a Cipher in CBC mode, so even if you have a bunch of objects
> sealed with the same key, you'll still need to have a table of IV's
> around somewhere to read them as well (my current problem, not hard
> to solve, but I find myself asking "why?").
This is exactly the kind of problem we are trying to solve above.
>
> While the extra code for handling systems talking 2 is not very lengthy,
> it gets a little bit more confusing if you are trying to talk to a system
> of type 3. To the best of my knowledge keeping the IV secret does not
> improve the security of a given system so having it sitting at the start
> of a stream unencrypted doesn't really matter.
>
> I think this restriction should be lifted. There really should be some
> way of telling a Cipher about other modes for using an IV. Either by saying
> something like "DES/CBCInlineIV8/PKCS5Padding" or by extending the
> IVParameterSpec to tell the Cipher, "no I don't have the value but here's
> how to calculate it".
>
> Thinking about it I probably prefer introducing a standard naming convention.
> if we simply added PlainIV, EncodedIV, and PassedInIV (default) as
> extenders to CBC, etc... little should need to change.
This seems like a good idea. I am not sure if the SunJCE provider
will support those "modes", but I will consider adding those modes
to the list of "standard algorithm names" in the JCE API Reference & User
Guide.
Thanks for your comments!
Jan