# Re: FCS coming up?

Jan Luehe (Jan.Luehe@Eng)
Tue, 9 Mar 1999 09:57:41 -0800 (PST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Jan Luehe: "Re: JCE 1.2"
- Previous message: Jan Luehe: "Re: Previous mail"
- Maybe in reply to: Frank Yellin: "FCS coming up?"
- Next in thread: David Brownell: "Re: FCS coming up?"

    Date: Tue, 9 Mar 1999 09:57:41 -0800 (PST)

    From: Jan Luehe <Jan.Luehe@Eng>

    Subject: Re: FCS coming up?

    To: Jan.Luehe@Eng, David.Brownell@Eng

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?
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? In the JDK, we have default
parameter values for DSA, and we don't enforce that every provider
use the same values.
Also, we don't provide certain algorithm implementations
that other providers do. Should we also define default
parameter values for those?

>
> 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.

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.

Jan

- Next message: Jan Luehe: "Re: JCE 1.2"
- Previous message: Jan Luehe: "Re: Previous mail"
- Maybe in reply to: Frank Yellin: "FCS coming up?"
- Next in thread: David Brownell: "Re: FCS coming up?"