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 reason we have our own crypto API was that Java's crypto API was
introduced in 1.2, for which there was no open source version. Have we
ditched the 1.1 requirement?
Scott
>
> >
> > 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/20030520/75bfd399/attachment.pgp>
