Date: Fri, 15 Aug 1997 10:31:15 -0700 (PDT)
From: Jan Luehe <Jan.Luehe@Eng>
Subject: Re: Padding in the JCE
To: java-security@web2.javasoft.com, emaher@baltimore.ie
Hi Eamonn:
> First of all I have a specific bug report. This is to do with
> JavaSoft's implementation of PKCS#5 as distributed in their jce.zip.
Thanks for pointing this out! We are aware of this bug, and
will fix it.
> The other thing I'ld like to comment on is the general API for padding.
> One must supply offsets and lengths as well as the byte array to be padded.
> This seems rather confusing, why not just supply the byte array to be
> padded or unpadded and let the padding class figure out if the array has
> been padded correctly etc. For instance in the JCE, the unpad method returns
> the index of where the padding starts. It doesn't return an unpadded byte
> array. Also some paddings (PKCS#1) require a prng so why not initialise a
> padding class with a prng or have a setRandom method. Again this is an example
> of JavaSoft putting what should be in the JCA in the JCE.
I agree that Padding should have been part of the JDK, since it is
also required by some signatures mechanisms. Adding a "setRandom"
method would have made perfect sense.
In the new JCE spec (which we will publish shortly), Padding will no
longer be exposed at the java API level. Padding is specified
as part of the algorithm (format: algorithm/mode/padding), and is
an integral part of the Cipher. Providers may implement padding in
whatever way they want.
We added new methods for initializing a cipher operation, which take
a SecureRandom as one of their arguments. So if the underlying
padding mechanism requires any random bytes, it can get them from
there.
Thanks,
Jan