On Wed, May 21, 2003 at 03:25:07AM +0100, Toad wrote:
> D'OH.
>
> java.security.MessageDigest, not javax.crypto.Mac.
<lol>
A message digest is a hash function. A Mac is a Message Authentication
Code, which is usually a keyed digest. A MAC requires the key to be
verified correctly. This is used as a lightweight integrity algorithm,
where the receiver knows the sender's key, but it isn't transmitted.
HMAC is a common MAC which uses a symmetric cipher and SHA1 together.
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/018b69bc/attachment.pgp>
