# Padding in the JCE

Eamonn Maher (emaher@baltimore.ie)
Mon, 11 Aug 1997 17:21:23 +0100

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Stefan Manzke: "no success with signed applets"
- Previous message: Adriano C. R. da Cunha: "Java applet file access"
- Next in thread: Jan Luehe: "Re: Padding in the JCE"

    Message-Id: <3.0.1.32.19970811172123.00946840@cougar.baltimore.ie>

    Date: Mon, 11 Aug 1997 17:21:23 +0100

    To: java-security@web2.javasoft.com

    From: Eamonn Maher <emaher@baltimore.ie>

    Subject: Padding in the JCE

Hello all,

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.

I received some text which had been encrypted with the JCE implementation
of DES and had been padded as is usual with PKCS#5. The ciphertext decrypted
without any problems (using Baltimore's J/CRYPTO DES) but didn't unpad
correctly. PKCS#5 works as follows, bytes are appended to the plaintext
until it is a multiple of the blocksize. The particular bytes appended are
just the byte value of the number of bytes to be appended. So if M the
plaintext is 29 bytes in length then it is padded with the 3 bytes 0x03
0x03 0x03. This is an unambiguous padding suggested by RSA in their PKCS
standards. If M is already a multiple of the blocksize in length then an
extra block consisting of 0x08 0x08 0x08 0x08 0x08 0x08 0x08 0x08 is
appended.

What JCE PKCS#5 appears to be doing is using the ascii value of 3 (in the
first example) giving an actual byte value of 0x33. ie 48 is added on to
each value then it is converted to a byte. Presumably it unpads correctly
since it follows the same procedure but it is not compliant with other
crypto packages at the moment.

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.

Eamonn
_________________________________________________________________________
Eamonn Maher, J/CRYPTO Engineer, emaher@baltimore.ie
Baltimore Technologies Ltd., Information Security Specialists
IFSC House, Custom House Quay, Dublin 1, Ireland
Tel: +353-1-605 4386 Fax: +353-1-605 4388 Web: www.baltimore.ie

- Next message: Stefan Manzke: "no success with signed applets"
- Previous message: Adriano C. R. da Cunha: "Java applet file access"
- Next in thread: Jan Luehe: "Re: Padding in the JCE"