Date: Wed, 17 Nov 2004 13:32:53 -0500 (EST) From: "Iang" <iang@iang.org> To: "Palle Girgensohn" <girgen@pingpong.net> Cc: freebsd-java@freebsd.org Subject: Re: Crypto takes 17 seconds to wind up for the throw... Message-ID: <1887.82.70.142.134.1100716373.squirrel@82.70.142.134> In-Reply-To: <983D763530B95ACD8E418A06@palle.girgensohn.se> References: <417ECD08.8010805@systemics.com> <417F6596.8050808@telia.com> <4180DD57.9060100@systemics.com> <983D763530B95ACD8E418A06@palle.girgensohn.se>
next in thread | previous in thread | raw e-mail | index | archive | help
Palle, Thanks for that! Below is a quick report on why Cipher.getCipher() takes too long. > Kinda late to feed back on this, but I ran into a similar problem a while back, and it was fixed by setting up rndcontrol(8) to get a good pool of entropy. Set something like: > > rand_irqs="5 10" > > in /etc/rc.conf. The IRQs should of course be some where there is some action. check the rndcontrol manpage... Actually I ran into that last month in a different circumstance, where unless the rand_irqs has some irqs, it just blocks totally. > The stuff you describe below is not quite like my problem, so you are probably not helped by this, but maybe it's worth a try... I'm conscious of promising more feedback on this, even a detailed report which I should bug report to Sun. (But I ran out of time and also my thunderbird was totally hosed, as were other KDE/gnome areas so I'm limping at the moment. I guess I just have to upgrade from 4.9 to 5.3 when it gets into release.) Anyway, this is the problem: The JCE goes out to the network stack and asks some mindless question like what host am I. If the machine is misconfigured, the question doesn't come back for 17 seconds or so while the network goes through some sort of try/this/timeout scenario. As soon as the network is properly configured, then it pops back such that the entire process takes about a second. Doing stack dumps or whathaveyou confirms that 98% of the time is spent blocking on some network call. Of course it is totally unacceptable for crypto code to be dependent on the network, and introduces all sorts of questions and potential security holes. But, the JCE is that, in a nutshell; not something that was put together for security ... Why the JCE has decided to go out to the network is open to speculation. I've thought of several reasons; One is that it is an artifact of random x.509 cert usage in checking the signatures on the libraries. Another is that the certs have OCSP enabled, and do a freshness check. Third, it is doing some sort of passive check on IP numbers related to its policy. Fourth, it's reporting in to Virginia... In order of likelihood ;) The problem is that this sort of heavy weight administration lumped on top of a bunch of what should be slightly sophisticated maths methods is becoming more and more OTT as time goes on. First we had the JCE itself, then we had the difficult-to-bypass API, those silly but hard to find "policy files", then the signed providers and now we have checks on the network. It doesn't take a cryptographer to realise that this is adding insecurity at all levels and the solution is to get back to the basic maths. Anyway, enough whinging. iang
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1887.82.70.142.134.1100716373.squirrel>