Re: Hardware acceleration?

On Friday 12 December 2008 10:46, Ancoron Luciferis wrote:
> Matthew Toseland wrote:
> > On Thursday 11 December 2008 23:32, Ancoron Luciferis wrote:
> >> Matthew Toseland wrote:
> >>>>> Short answer: No. =)
> >>>>>
> >>>>> Long answer:
> >>>>> You need special JCE module (software) installed.
> >>>>> (e.g. http://www.via.com.tw/en/initiatives/padlock/via-jcp.jsp )
> >>>>>
> >>>>> However,
> >>>>> the most-used crypto in freenet is Rijndael (original favour, not the
> >> NIST
> >>>> one),
> >>>>> no module provide this acceleration.
> >>>> AFAIK it's the same, but we generally use 256/256, whereas AES is
> >> actually
> >>>> 256/128. In any case there are export policy / key length issues until
> >> 1.6,
> >>>> and we don't require 1.6 yet.
> >>> This also applies to DSA/RSA. We use our own implementations because
> >> the JVM
> >>> versions are restricted in key length until 1.6.
> >>>
> >>> It would be possible to switch between the different impls by a config
> >> option,
> >>> if it was deemed worth the effort...
> >>>>> SHA-256, while do have some acceleration exist, are used sparsely.
> >>>> We use SHA-256 in many places. We use the JVM implementation. So if
> >> hardware
> >>>> acceleration is enabled, and if the relevant java library is included
> >>>> (manually, RTFM), SHA-256 will be accelerated.
> >>> The accelerator card doesn't do SHA-256 apparently, only SHA-1 and md5.
> >> We do
> >>> use md5 in some cases (e.g. the spider), but it's not widely used as it 
is
> >>> known to be broken.
> >>>> The hardware RNG will also be useful.
> >> OK. I think I've got it.
> >>
> >> Many things that freenet uses goes beyond the capabilities of those
> >> accelerators. But some would get a benefit. Can someone give a hint
> >> how much the security related things that would be supported by such
> >> an accelerator (RNG, RSA/DSA) are used inside freenet? Or basically
> >> which action of the node implies which security related method?
> >
> > DSA would be a significant gain for connection setup and routing SSKs.
> > However, if you queue downloads, they will need to be FEC decoded. This 
can
> > take 100% CPU for a longish period on slow hardware.
> >> So is there a detection of the used JVM? I mean if I just would use
> >> the 1.6 JVM does it imply that I'm able to choose the implementation
> >> using JCE system properties?
> >
> > No, we implement our own Rijndael (unfortunately the 256 bit block size 
means
> > it's not compatible anyway), and our own DSA (which would be compatible 
but
> > we don't use because of crypto export issues).
> >> If that is not the case could freenet be made configurable in such a way?
> >
> > It is possible yes. But it hasn't been done yet and I'm not sure it would 
be a
> > big gain. We use SHA-256 a lot more than we use DSA. Profiling would be of
> > interest; if a large proportion of the node's runtime is spent doing DSA, 
it
> > would be more interesting to implement such a toggle.
> >> I am purchasing such a board as I'm dealing with many parallel SSL
> >> connections and until now I have a server doing that work. But the
> >> power consumption of such a small Soekris box sounds really nice to
> >> me. And running freenet on such a small device along with my other
> >> things that have to run 24/7 would make my life much easier. So if
> >> freenet doesn't benefit a lot of those hardware accelerators I have to
> >> evaluate if it is using too much CPU for that box to not interfere my
> >> other things.
> >>
> >> Thanx and greetz,
> >>
> >> AncoL
> >>
> >> ------------------------------------------------------------------------

You seem to have sent this message twice.
> 
> OK. Thanks for that info so far.
> 
> I just searched a bit for other hardware accelerators a bit and came
> across the Sun UltraSparc T2 again.
> 
> If SHA-256 and DSA are the most common tasks within freenet I think that
> would be the processor of choice for hardware acceleration, although it
> lacks a RNG or Rijndael of course.

We also do a lot of Rijndael. Some hardware may be able to do Rijndael with a 
256 bit block size, I dunno exactly what operations the hardware actually 
does.

However, if you are actually queueing downloads, we also do a lot of FEC 
decoding and encoding. Which can't be hardware accelerated.
> 
http://wikis.sun.com/display/CryptoPerf/Using+the+UltraSPARC+cryptographic+accelerators
> 
> 1 crypto processor per core, 8 cores per socket... *dreaming of speed*
> 
> Anyway... freenet runs fine on Solaris, doesn't it?
> 
> The further I read the more I'm into replacing my server. If freenet
> won't run on that little soekris box well I would need a server and if
> the UltraSparc T2 is really that good I would use it for my VPNs too. So
> no need for that extra board in the Soekris anymore.

Niagara 2 is pretty awesome, I have to give them that. Especially as they've 
opened the source code for the cores!
> 
> The good thing with Sun is that it is always concerning about Java. With
> anything they develop. So you also get the appropriate JCE provider. And
> as long as I have seen the Sun JVM is far more effective running under
> Solaris than on any other platform. I don't know why this is but all
> applications I have seen are always faster at the Java side when running
> on a Solaris system.
> 
> What do think of that?
> 
> Regards,
> 
> AncoL

_______________________________________________
Tech mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iQIVAwUASUJnY3svjZi+xPTDAQJvMRAAityFzCv12+gWKa4OONZVt9XBvAjLrsbm
3vSk9+Q/ceg1nglBerTU8V6DtG/PYSdJIytilBUNMoEjvjr8mpGgMD8TTHlEncd4
5GHNlz3wQSZW5864KIgPMFVqUx5iq7dtaZAG6evjsa53IzZMet+LfJD5yLq2TIrd
Pc8uMro3XNL5mDFJi95LQA7WwRodYWVYegaFUvezjU0gvEgXhDi54pngoB2HDACo
Dp8eOUXx0PjB0eHcGKp7vsT4wdFsfX16ap3yJjyunhgpBq9JSIcHufoTSq79Mz4d
2Sw3qLwWjsk5Sen3qb85r8Ct+Ii6ved9BYG20T+oM4u6WH57/avoh2+vkyDsPIxZ
Vxo1RiQSVgvPwKcOi6ZvzmprcjPh7qLpl7v8DG3cdiMxqQK+cC8i1UGoeZ157wVp
Dd7BwoYbF1fRKonBs/DMlPHIGKHjHyioFgiIkqut8wkRpL3pPEvenzOP2mKyvMBv
J8jnQfHF8cYsyF+0i3CnqkIO0L6QJJfwGjwZnD6WAO8hVdc/GGwFRFl7Yh0ttSw1
EbdEu4VNSJdg2sV+78oeL/3zbq4AiQunxF8nprSXmqx2/Z6Rupq2mjyBtIfLf9cZ
bwbXGtwQOeryEhKDoamI3borMWRG2NOUYUbfgVzQnDBV1kYj4KwnHWaSMTSQLfm2
XXUL/4Qr4vA=
=4IqM
-----END PGP SIGNATURE-----