Re: [Classpathx-crypto] latest checkins

[Raif S. Naffah]

hello Casey,

Casey Marshall wrote:
> On Sun, 28 Jul 2002, Raif S. Naffah wrote:
>
>
> > Olivier LF wrote:
> >
> > > On Sat, Jul 27, 2002 at 12:37:49PM +1000, Raif S. Naffah wrote:
> >
> > > Both crypto library and JUnit test suite build successfully however
> > > Anubis still does not pass its self test!
> >
> > Anubis does not have anything specially different than the other ciphers
> > --in terms of the java language constructs and invocations.  does any
> > other cipher pass its self-test?
>
> I think this is an optimization bug in GCJ. I inspected the selfTest()
> method, and using good old print-out-the-state debugging found out that
> selfTest() actually passes all of its tests -- ie it gets past the two
> nested for loops -- but for some reason returns false. I re-made the
> GCJ build after removing the -O2 flag and every cipher test succeeds.
> It also works with just -O.

excellent detective work!  are the gcj people aware of this?  would it 
help'em if you submit a bug-report with sample code?


> As for the other two build methods, Ant works for me, yet the top-level
> make seems to want either the NIST test vectors to be in the tree, or
> wants to try to build them (and there is no target for them). I'm guessing
> that the test vectors will be included in the distribution, or that the
> Makefile will not include these files and there will be a pointer in
> the documentation to download and test these files.

i'm spending this weekend looking at this.  i'm more or less convinced 
that the test-vectors (a) can be generated by a special target in the 
make/ant files, that can be invoked on its own, and (b) should be jarred 
and made available for download.  unless somebody convinces me otherwise 
this is how i shall be proceeding.


> I did some profiling of the libraries...

care to elaborate?!


>... and discovered that because Serpent
> creates a new integer array for every block it processes, a LOT of objects
> are allocated during execution. This could be a problem in low-memory
> devices, where a lot of time will be taken up with garbage collection.
>
> Making the integer array 'x' on lines 597 and 686 a private instance
> variable will correct this, but breaks thread-safety (if that's an issue).

we can always use the "lock" object in the BaseCipher to protect those 
code blocks.

the other 2 alternatives are:

* in-line the transform() (and its inverse) in the encrypt() and 
decrypt() methods, and use 4 ints rather than the int[].

* re-write the code to eliminate the need for this array. (i'll send you 
 in private an implementation i did for the Serpent's authors for their 
AES submission that may give you an idea about what i'm talking about).


i guess we have to add to our checklist of TODO list before the release 
the thread-safety issue you raise.  when we identify such a case the 
documentation has to make it clear that it is an issue the user has to 
be aware of; e.g. something in the class javadoc like:

<p><b>Implementation issue:</b> This implementation is not 
thread-safe... </p>

or something like that.


cheers;
rsn