# Re: JCE Cipher class

Benjamin Renaud (br)
Thu, 8 May 1997 11:57:38 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Eric Groennou: "Java security problem"
- Previous message: Steve Burnett: "JCE Cipher class"
- Maybe in reply to: Steve Burnett: "JCE Cipher class"

    Date: Thu, 8 May 1997 11:57:38 -0700

    From: br (Benjamin Renaud)

    Message-Id: <199705081857.LAA08653@springbank.eng.sun.com>

    To: burnettS@RSA.COM

    Subject: Re: JCE Cipher class

| Before asking my question about the Cipher class, I'd like to
|describe something about the Signature class. Then I'll try to draw an
|analogy.
|
| From my examination, it appears that the Signature class will take
|the String algorithm and call the provider to return an instance of its
|class that performs this signature algorithm. Is that correct?
|
| So then I'm thinking the Cipher class will be similar. It will take
|the String algorithm and have the provider return an object.
|
| But the algorithm may be up to three things, algorithm, feedback and
|padding. Will Cipher call down and expect the provider to return three
|objects? Will it send all three units of information to the provider and
|expect one object in return?

This is an interesting question. The way it is handled is like this:

The caller may elect to specify a provider. If he does, then the API
will require that there be an exact match between the advertised SPI
and the requested algorithm. For example, in the Sun provider, we
could specify:
DES/EDE/CFB -> sun.security.provider.DesEdeCfb

If the caller does not specify a provider, the API will try to first
get an exact match, and then to mix and match various pieces to get the
desired results. It is currently possible for a provider to specify a
cipher (i.e the first component) and a padding (i.e. the third
component). There is a draft API for a mode.

| It seems to me an implementation would be best if the "slash" (/) in
|the algorithm String indicated a new class. One class performs DES
|another RC2. Then combine either of those classes with a feedback class,
|one could perform CBC, another CFB. Then padding could be a third class,
|either PKCS#5 or PEM.

Yes. This is how our provider is implemented.

| So is Cipher expecting the provider to have one class that performs
|DES-CBC-NoPad, another DES-CBC-PKCS#5, another DES-ECB-NoPad, another
|DES-ECB-PKCS#5, then RC2-CBC-NoPad and RC2-CBC_PKCS#5, and on and on and
|on. Or are providers "allowed" to separate functionality into classes?
|
| A package that provides DES, RC2, RC5, CBC, CFB and PKCS#5 padding
|(and ECB and no padding) will either have to build 18 classes or 6
|classes.

This would require a simple additional heuristic: instead of requiring
an exact match when the provider is specified, see if the provider in
question provides all the components needed for the given requested
cipher.

[...]

| If someone passes "RSA" and calls initEncrypt (I still have trouble
|remembering to say initEncrypt, rather than encryptInit, as we do in
|BSAFE and as is done in Cryptoki and as is done by another company!)
|then the provider will by default use PKCS #1 Block Type 01. Or whatever
|the provider decides the default should be.

This should be specified in the JCE Algorithm appendix.

Cheers,
-- Benjamin Renaud
VM/Language Team (formerly of the Security group)

- Next message: Eric Groennou: "Java security problem"
- Previous message: Steve Burnett: "JCE Cipher class"
- Maybe in reply to: Steve Burnett: "JCE Cipher class"