Date: Wed, 10 Mar 1999 08:46:52 -0800
From: David Brownell <David.Brownell@eng.sun.com>
To: Jan Luehe <Jan.Luehe@eng.sun.com>
Subject: Re: FCS coming up?
Jan Luehe wrote:
>
> Dave:
>
> > > * <p>If this cipher requires any algorithm parameters that cannot be
> > > * derived from the given <code>key</code>, the underlying cipher
> > > * implementation is supposed to generate the required parameters itself
> > > * (using provider-specific default or random values) if it is being
> > > * initialized for encryption, and raise an
> > > * <code>InvalidKeyException</code> if it is being
> > > * initialized for decryption.
> >
> > Perhaps it's the WORA tester in me ... but shouldn't that
> > read "algorithm-specific default values" for encryption,
> > and also for decryption?
> >
> > If it's provider-specific, then two programs using different
> > implementations of the same algorithm will get different
> > behavior. No "write once run anywhere". In effect it's
> > not the same algorithm at all.
>
> Why?
Same algorithm == WORA ... any time I see specs saying that
implementations may vary in behavior, I look carefully since
it affects portability (WORA). In this case it's not required,
and has drawbacks.
> Some provider may choose a specific salt value and iteration
> count for PBE encryption, and a different provider may choose
> different values. They should have the right to choose
> whatever values they want, right?
Not when it affects interoperability.
> In the JDK, we have default
> parameter values for DSA, and we don't enforce that every provider
> use the same values.
DSA is a signature algorithm, and the parameters are part of
the signature output. Doesn't affect interoperability.
Not so for a cipher.
> Also, we don't provide certain algorithm implementations
> that other providers do. Should we also define default
> parameter values for those?
Probably. JCE seems to define its own namespace of algorithm
names, so part of the cost of maintaining entries in that
namespace should be any default parameter values.
> > Similarly, if it's random, it's not going to be useful for
> > two parties to communicate, since they'll both have as a
> > rule different values for those parameters. Basically it'd
> > be a write-only bitbucket.
>
> Why? You can create random parameter values for encryption,
> and then use those same values for decryption.
>
> > Also, why would decryption behave differently?
>
> Because if you do not use the same parameters that were used
> for encryption, decryption will not work.
If both parties have a way to communicate the values, all is
fine ... it's either in-band, or out-of-band. In the case of
signature algorithms (DSS/DSA, RSA) it's in-band.
The problem with doing this for a cipher is that it's got to
be out-of-band. IVs, for example, are generally managed (and
exchanged!) with the same sensitivity as keys.
JCE doesn't generate keys transparently ... why would it generate
other such sensitive data transparently? Frank commented that
the docs don't even cover secure exchange of IVs (I think that's
what I read, it was an "after 11pm" e-mail :-).
> The benefit of this is that users don't really have to know
> anything about parameters, all they need to know is
> whether or not parameters were used for encryption, and provide
> those same parameters to the decryption routine.
I see two basic options:
- Lack of parameters is an error, always.
- Same parameters are always selected.
WORA is all about repeatable behavior, regardless of which
underlying implementation is in use. Either of those options
can be fine, if it's repeatable. At this point I'd go for the
former -- it's simpler, and easier to conformance test as well.
The problem I see with what's now _specified_ (i.e. can't
get away from it) is that non-WORA behavior is not just
permitted, it's encouraged!
- Dave