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? > > 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/b53c27bd/attachment.pgp>
