bash-2.05b$ java -version
java version "1.4.1-p3"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-p3-root_02_jun_2003_23_31)
Java HotSpot(TM) Client VM (build 1.4.1-p3-root_02_jun_2003_23_31, mixed mode)
trace:
java.lang.InternalError: URLSeedGenerator file:/dev/random generated exception: null
at sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedByte(SeedGenerator.java:469)
at sun.security.provider.SeedGenerator.getSeedBytes(SeedGenerator.java:137)
at sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:132)
at sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:112)
at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:169)
at java.security.SecureRandom.nextBytes(SecureRandom.java:381)
at java.security.SecureRandom.next(SecureRandom.java:403)
at java.util.Random.nextInt(Random.java:191)
It's FreeBSD 4.9-RC #12: Fri Oct 3 23:00:12 CEST 2003
--
Marcin Gryszkalis
jabber jid:m...@chrome.pl
gg:2532994
http://fork.pl
_______________________________________________
freebs...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-java
To unsubscribe, send any mail to "freebsd-java...@freebsd.org"
--
Daniel Fisher
Enable more entropy gathering using rndcontrol(8).
On Mon, Oct 20, 2003 at 03:17:22PM +0200, Marcin Gryszkalis wrote:
> I happened just once, anybody noticed anything similar?
> It's on p3, I'm going to upgrade to p4 today.
>
> bash-2.05b$ java -version
> java version "1.4.1-p3"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-p3-root_02_jun_2003_23_31)
> Java HotSpot(TM) Client VM (build 1.4.1-p3-root_02_jun_2003_23_31, mixed mode)
>
> trace:
> java.lang.InternalError: URLSeedGenerator file:/dev/random generated exception: null
> at sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedByte(SeedGenerator.java:469)
> at sun.security.provider.SeedGenerator.getSeedBytes(SeedGenerator.java:137)
> at sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:132)
> at sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:112)
> at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:169)
However, doing so will get you much lower quality random numbers.
Depending on how much you value security this may not be acceptable.
I'd try rndcontrol(8) first, as Alexey mentioned.
--
Greg Lewis Email : gle...@eyesbeyond.com
Eyes Beyond Web : http://www.eyesbeyond.com
Information Technology FreeBSD : gle...@FreeBSD.org
> On Mon, Oct 20, 2003 at 11:08:39AM -0400, Daniel Fisher wrote:
> > Looks like you ran out of random bytes in /dev/random, which is not
> > uncommon.
> > If you want to avoid this error use /dev/urandom.
> > -Djava.security.egd=file:/dev/urandom
>
> However, doing so will get you much lower quality random numbers.
> Depending on how much you value security this may not be acceptable.
> I'd try rndcontrol(8) first, as Alexey mentioned.
In my experience /dev/urandom is the only way to guarantee that ssl
connections do not fail due to lack of random bytes.
This is a common problem on servers which make a lot of separate ssl
connections and cannot gather enough entropy to keep up.
However, if the load on your application allows using /dev/random you
should do so.
Just keep in mind you may see these errors every so often.
There are also other ways to gather entropy, but I can't vouch for them:
http://egd.sourceforge.net/
--
Daniel Fisher
On Tue, Oct 21, 2003 at 11:17:43AM -0400, Daniel Fisher wrote:
> On Mon, 20 Oct 2003 17:23:51 -0600
> Greg Lewis <gle...@eyesbeyond.com> wrote:
>=20
> > On Mon, Oct 20, 2003 at 11:08:39AM -0400, Daniel Fisher wrote:
> > > Looks like you ran out of random bytes in /dev/random, which is not
> > > uncommon.
> > > If you want to avoid this error use /dev/urandom.
> > > -Djava.security.egd=3Dfile:/dev/urandom
> >=20
> > However, doing so will get you much lower quality random numbers.
> > Depending on how much you value security this may not be acceptable.
> > I'd try rndcontrol(8) first, as Alexey mentioned.
>=20
> In my experience /dev/urandom is the only way to guarantee that ssl
> connections do not fail due to lack of random bytes.
> This is a common problem on servers which make a lot of separate ssl
> connections and cannot gather enough entropy to keep up.
> However, if the load on your application allows using /dev/random you
> should do so.
> Just keep in mind you may see these errors every so often.
> There are also other ways to gather entropy, but I can't vouch for them:
> http://egd.sourceforge.net/
egd just does in user space essentially what the kernel does in kernel
space to provide the entropy used for /dev/random.
If your system is a heavy user of randomness, and normal interrupt
activity isn't enough to keep up with demand, then you'll have to
provide an external source of randomness. Some motherboard chipsets
nowadays have a built in random source -- which is just a diode that
gives you a 50-50 chance of being conductive at any time -- or you can
use certain Crypto accelerator cards: see ubsec(4) and hifn(4).
Alternatively this is the excuse you need to requisition that lava
lamp without which no contemporary machine room could be considered
complete...
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
--ghzN8eJ9Qlbqn3iT
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQE/lVS7dtESqEQa7a0RAobQAKCIkrqF7TwYvskN2nekc6hziToftgCcDPyq
fLHQpFOfpsF5jDYmoBCGr04=
=fUFx
-----END PGP SIGNATURE-----
--ghzN8eJ9Qlbqn3iT--