Re: NetBSD openjdk SecureRandom /dev/random "Resource temporarily unavailable" issue

[coypu%SDF.ORG@localhost]

On Thu, Apr 28, 2016 at 03:01:31PM +0200, Tobias Nygren wrote:
> On Thu, 28 Apr 2016 09:44:21 +0000
> coypu%SDF.ORG@localhost wrote:
> 
> > On Thu, Apr 28, 2016 at 10:29:56AM +0100, David Brownlee wrote:
> > > With the default openjdk8 settings the following code
> > > 
> > > private static final int SALT_LENGTH = 32;
> > > private static final String RANDOM_FACTORY = "SHA1PRNG";
> > > byte[] saltBytes =
> > > SecureRandom.getInstance(RANDOM_FACTORY).generateSeed(SALT_LENGTH);
> > > 
> > > Fails with an exception:
> > > 
> > > register: Error registering subscriber: java.io.IOException: Resource
> > > temporarily unavailable
> > >         at java.io.FileInputStream.readBytes(Native Method)
> > >         at java.io.FileInputStream.read(FileInputStream.java:255)
> > >         at sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedBytes(SeedGenerator.java:539)
> > >         at sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:144)
> > >         at sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:139)
> > >         at java.security.SecureRandom.generateSeed(SecureRandom.java:533)
> > > 
> > > Adjusting lib/security/java.security to switch securerandom.source
> > > from file:/dev/random to file:/dev/urandom works around the issue.
> > > 
> > > Does anyone know if NetBSD's /dev/random behaving differently to other
> > > platforms here?
> > > 
> > > David
> > 
> > It's possible this behaviour does not exist with NetBSD /dev/random and
> > is expected by Java (from linux RANDOM(4)):
> > 
> > If open(2) is called for /dev/random with the flag O_NONBLOCK, a
> > subsequent read(2) will not block if the requested number of bytes
> > is not available. Instead, the available bytes are returned.  If no
> > byte is available, read(2) will  return  -1  and errno will be set
> > to EAGAIN.
> 
> But this is supposed to be a blocking read. Why does NetBSD return
> EAGAIN in blocking mode? I can kind of appreciate why 3rd party
> applications would not expect this to happen. At least we need to
> update rnd(4) to mention this fact and how to get blocking behaviour
> since it is different from how other systems behave.
> 
> -Tobias

Hi,

The aforementioned behaviour is of Linux, not NetBSD.
It's possible that Java is expecting this behaviour, as most people
are probably not using NetBSD.

Not related to your response:

I'd be concerned about languages that tries to continue to provide
random numbers if there is not enough entropy. This does happen in
practice, and users of that language could be relying on it for some
cryptography that requires actually random numbers.