Re: Hardware acceleration?

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

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

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

iQIVAwUASUGqInsvjZi+xPTDAQIiEA//QXoVv2FXlA38yNe4ShcdKsrFnZ0yxPIv
T6eYmcI14Piqir81XRjpBZWWRFg+MiYUB3zSLA7VMUNyj7QETdFvoJhxiUagvks8
Dn1uzA6oESL2jT/0Os5LnYbz0r887VKrezcTv16TXq5hPVvjLr8hip7elaFdeQln
4aXWrk/G2XaZFhxROF6l5n6LwbbsYmH2Kf9t6kHhFhUMW62cWm6m5BrMQApxJy8T
p1uE0U61/52OyiHKu3bLJ9xLNguMTZszhDXs6HR0BQPz6gfpY6fA+VK3mWWJuV+m
hF6B8j4MRQOvBxmL3AUgyeHI9UVsF/J/W8wKAgw4gNUfkmnOgzy/khXorpF6y7TS
F1hLm2eL7bz/B892qswYRJVp4MBdz4r58NXFIcQoHS/OgzY3Kosd9OUsjfHNLim5
fQJd2g6tWCwJ2uMJirtL1yWGkBq5oSa33P5L1/ZijB9BRU2v/rWeaXfrB58/cJ++
3hgyVntFRiYqQ3ivqEqM2s6DJpNx+JAQ4cPsjsff9H7Yzlg7ekoGPJulydkzrVku
0P0kitFufke345oIKH4Q11p0eJ8SSqjdp8ZIm1zvUrv14etKn8ooqdrIELHyUQ8Z
KcutMH62xKL37SQ+rtoLRxoXwXBpf6Nj9svD1AvOXe6flG9RXKm7K/CeOFrT8BXc
Kjx5nQ+iTZc=
=WoZ+
-----END PGP SIGNATURE-----