Subject: [Classpathx-crypto] latest checkins

From: "Raif S. Naffah" <[email-masked]>
Date: Sat, 27 Jul 2002 12:37:49 +1000

hello guys,

i've checked in more JCE Adapters to wrap all our secure PRNG 
implementations, and added a small test to the TestOfProvider in 
test.jce for that.

earlier i checked in an implementation of David McGrew's UST algorithm. 
  i'm still waiting for its review --which is why i didnt announce it 
earlier.

finally i updated the build.xml, Makefile.in (in toplevel) and 
Makefile.am (in gcj/source).  i tested the two former ones but was 
unable to try the gcj version because (a) dont have a working gcj and 
(b) dont have autoconfigure2.50.

i'd like to aim for the 30th of August as the date for the first public 
release of the library.  so from now on it's concentrating on:

a. the documentation: organisation, spelling, clarity, etc...
b. the build process: ANT and the 2 makes --i/we probably would need 
help with Nic's automakejar tool; any takers?
c. sort out the test vector issue; and finally
d. sort out signing the distribution issue.

volunteers for above tasks, and ideas/suggestions about the still open 
issues are welcome.

cheers;
rsn

---

From: Olivier LF <[email-masked]>
Date: Sun, 28 Jul 2002 16:12:29 +1000

On Sat, Jul 27, 2002 at 12:37:49PM +1000, Raif S. Naffah wrote:
> ...
> ...
 
I have updated the GCJ build accordingly.
Both crypto library and JUnit test suite build successfully however
Anubis still does not pass its self test!

Making the GCJ build mostly useless for now... Anyway it is there.

Oli

----------------------------------------------------------------------
Olivier Louchart-Fletcher
olivier -at- zipworld com au

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sun, 28 Jul 2002 19:52:58 +1000

> I have updated the GCJ build accordingly.

thanks a bunch!

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

cheers;
rsn

---

From: Casey Marshall <[email-masked]>
Date: Thu, 1 Aug 2002 18:30:29 -0700 (PDT)

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

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 did some profiling of the libraries 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).

-- 
Casey Marshall < [email-masked] > http://metastatic.org/

---

From: "Raif S. Naffah" <[email-masked]>
Date: Sat, 03 Aug 2002 19:22:54 +1000

hello Casey,

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

> 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

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

---

From: Casey Marshall <[email-masked]>
Date: Sat, 3 Aug 2002 16:23:05 -0700 (PDT)

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

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

> AES submission that may give you an idea about what i'm talking about).

I'll look into this.

> <p><b>Implementation issue:</b> This implementation is not

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