On Wed, May 21, 2003 at 04:02:31AM +0100, Toad wrote: > On Wed, May 21, 2003 at 03:25:07AM +0100, Toad wrote: > > D'OH. > > > > java.security.MessageDigest, not javax.crypto.Mac. > > Okay, that IS compatible. And about 7MB/sec on my system against about > 3MB/sec for our java code on the same system. I have implemented a > compatibility layer. Of course if we call digest(boolean, byte[], int) > with the boolean false, it blows up because java doesn't implement that. > > We only use digest(false,...) in crypt/Util.java, line 461. What I need > to know is would it be possible to rewrite that section not to need that > functionality without changing its output?
The default implementation has a working clone(), so we CAN use it. However the docs warn that not all will. So we will need to test for a working clone() at startup and use java.security.MessageDigest if we have one, and freenet.crypt.SHA1 if we don't. Or do the test in Util.java, as that's the only place it effects. All coming up tomorrow. > > > > > Can somebody explain what the difference is between the two? > > > > On Wed, May 21, 2003 at 02:45:58AM +0100, Toad wrote: > > > It would appear that javax.crypto is not compatible with our > > > implementation. We implement FIPS 180-1. Sun implements RFC 2104. > > > Experimentally, their implementation does not produce the expected > > > results in the code, whereas ours does. Standards are great, there are > > > so many to choose from :( > > > > > > > > > On Wed, May 21, 2003 at 01:39:27AM +0100, Toad wrote: > > > > It turns out that Sun JDK 1.4 implements SHA-1 natively. > > > > > > > > Benchmarks on my local machine (XP 1700+): > > > > > > > > Sun javax.crypto, default provider for HmacSHA1: > > > > > > > > SHA update 100000 times for the same data block of size 4096 bytes: > > > > 54479ms [7518493bytes/second, 1ms/update] > > > > SHA update 1000 times for different data blocks of size 4096 bytes: > > > > 574ms [7135888bytes/second, 1ms/update] > > > > > > > > freenet.crypt: > > > > > > > > SHA update 100000 times for the same data block of size 4096 bytes: > > > > 144562ms [2833386bytes/second, 0ms/update] > > > > SHA update 1000 times for different data blocks of size 4096 bytes: > > > > 1388ms [2951008bytes/second, 0ms/update] > > > > > > > > Looking good, what remains: > > > > > > > > * Implement a compatibility layer (should be trivial) > > > > * Run our SHA1 tests to verify that they interpret the standard the same > > > > way as we do. > > > > > > > > According to > > > > http://194.236.28.174/freenetstuff/6037/8kQPH_10_minutes/getCurrentTreadCPUTime/ > > > > > > > > SHA1 makes up a significant fraction of our CPU usage. It is also the > > > > limiting factor in many user visible operations. I am not sure whether > > > > we can do the same thing for DLES... have a look at > > > > > > > > http://java.sun.com/j2se/1.4.1/docs/guide/security/jce/JCERefGuide.html > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20030521/65d60d22/attachment.pgp>
