Re: [Classpathx-crypto] latest checkins

[Casey Marshall]

On Sat, 3 Aug 2002, Raif S. Naffah wrote:

> hello Casey,
>
> Casey Marshall wrote:
> > On Sun, 28 Jul 2002, Raif S. Naffah wrote:
> >
> >>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?
>

I'll look at their list archives to see if this has come up before; if
not I'll post a message.

> [...]
>
> > I did some profiling of the libraries...
>
> care to elaborate?!
>

I was testing out an evaluation version of a Java profiler (I think it
was JProfiler -- which isn't worth it; proprietary and too expensive)
and put it through its paces by running the gnu-crypto test suite (plus
testing the full NIST vectors).

I was rather shocked/amused to see the number of int arrays climb to
25,000, then fall back to zero while Serpent was running.

> >... 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[].
>

Won't work. The S-Box functions would also need to be in-lined, and this
would make the code much less readable.

(It's situations like this that make me want a Java preprocessor.)

> * 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'll look into this.

> 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.
>

Or mention generally that the library is not necessarily thread-safe, if
thread safety is not a big issue for this library.

-- 
Casey Marshall < address@hidden > http://metastatic.org/