# JCE Cipher class

Steve Burnett (burnettS@RSA.COM)
Thu, 8 May 1997 11:45:15 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Benjamin Renaud: "Re: JCE Cipher class"
- Previous message: Carl McClellan: "certificates"
- Next in thread: Benjamin Renaud: "Re: JCE Cipher class"

    Message-Id: <c=US%a=_%p=RSA_Data_Securit%l=LOBESTER-970508184515Z-3788@LOBESTER.rsa.com>

    From: Steve Burnett <burnettS@RSA.COM>

    To: "'JavaSoft crypto questions'" <java-security@web2.javasoft.com>

    Subject: JCE Cipher class

    Date: Thu, 8 May 1997 11:45:15 -0700

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?

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.

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.

It would be great to see the Cipher class source code (as with the
Signature class source code) to better plan a provider package. When
will that be available?

And one more question on the Cipher class. If I'm performing RSA
encryption, what do I pass as the String algorithm? "RSA"? If so, then
how does it know to do PKCS #1 Block Type 01 or 02 encoding? Or OAEP or
PSS? Will there be several flavors of RSA, such as "RSAPKCS#1Block01"
and "RSAOAEP"? Or maybe the block type could be analagous to the padding
with a block cipher. "RSA/PKCS#1Block01" or "RSA/SETOAEP" or
"RSA/P1363OAEP".

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.

- Next message: Benjamin Renaud: "Re: JCE Cipher class"
- Previous message: Carl McClellan: "certificates"
- Next in thread: Benjamin Renaud: "Re: JCE Cipher class"