# JCE bug report

Simon Spero (ses@tipper.oit.unc.edu)
Mon, 02 Jun 1997 17:15:09 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Marianne Mueller: "Re: Java Card API"
- Previous message: Marianne Mueller: "Re: Help"

    Date: 	Mon, 02 Jun 1997 17:15:09 -0400

    From: Simon Spero <ses@tipper.oit.unc.edu>

    To: mrm@Eng, java-security@web2.javasoft.com

    Subject: JCE bug report

hey Marianne--I've been doing some coding using the alpha jce and I've
found a weird bug which showed up when I wrote some code which made
repeated calls to a cipher configured in ecb mode with no padding.

For reasons which you can probably guess from what I'm about to say, I
needed a cipher operating in PCBC mode. Can you guess what the
application is yet :-) anyway, since there doesn't seem to be any way to
add extra modes to cipher, I just created a new class not subclassed
from the usual cipher, and had that own an instance of a DES/ECB/NONE
cipher. I then did my own padding and feedback stuff. Whilst I was
debugging this, I found that the cipher that shipped with the 95 jce 1.1
has problems when used in this way. Since I was doing my own padding, I
always wrote to the cipher in eight byte chunks. The first block
decrypted perfectly. However the second block decrypted exactly the
same as the first. The third block returned the decrypt of the second
block and so ad infinitum (or at least until I ran out of blocks. The
decrypt of the last block disappeared through a warp in space, only to
appear out of nowhere in the middle of important peace negotiations
leading to a bloody war with many millions of deaths. The bloodshed
must end here :-).

The obvious fix of encrypting the first block twice works fine. If you
like I'll try and isolate a test--case for you, or I could send you the
entire package when I've finished the last few bits (I can now get and
decode initial kerberos tickets ok, which is 90% of the battle).

It's amazing how much easier it is to code this stuff in java--the only
real problem is with the way the cipher API is structured.It might be
better if modes and padding were separated from the insta nce factory
approach. If feedback cipher worked in the same way as filter input
stream, it would be much easier just to subclass for a new mode, and
much easier to plug in a new padding scheme. The only place where the
factory stuff is really needed is for the basic ecb crypto engine--if
the other stuff could be made orthogonal it would make adding specialty
modes on the fly much easier.

Simon

- Next message: Marianne Mueller: "Re: Java Card API"
- Previous message: Marianne Mueller: "Re: Help"