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/979ec8dd/attachment.pgp>
