Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

file:/dev/random generated exception: null

24 views
Skip to first unread message

Marcin Gryszkalis

unread,
Oct 20, 2003, 9:18:20 AM10/20/03
to
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)
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

unread,
Oct 20, 2003, 11:10:53 AM10/20/03
to
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

--
Daniel Fisher

Alexey Zelkin

unread,
Oct 20, 2003, 11:56:21 AM10/20/03
to
hi,

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)

Greg Lewis

unread,
Oct 20, 2003, 7:24:13 PM10/20/03
to
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.

--
Greg Lewis Email : gle...@eyesbeyond.com
Eyes Beyond Web : http://www.eyesbeyond.com
Information Technology FreeBSD : gle...@FreeBSD.org

Daniel Fisher

unread,
Oct 21, 2003, 11:19:42 AM10/21/03
to
On Mon, 20 Oct 2003 17:23:51 -0600
Greg Lewis <gle...@eyesbeyond.com> wrote:

> 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

Matthew Seaman

unread,
Oct 21, 2003, 11:46:49 AM10/21/03
to

--ghzN8eJ9Qlbqn3iT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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...

http://www.lavarnd.org/

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--

0 new messages