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

[coypu%SDF.ORG@localhost]

On Thu, Apr 28, 2016 at 02:57:15PM +0000, coypu%SDF.ORG@localhost wrote:
> 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.

Disregard that. read a bit.