the Microsoft C Runtime Library makes use of this function in its
implementation of rand_s, so it's removal would break a lot of
programs. I think this is a relative guarantee that the function is here
to stay.
Ok.
What are the fallbacks for SystemRandomImpl if /dev/urandom or the
Hi Brad,
On 01/01/2015 02:46 AM, Bradford Wetmore wrote:
To the actual proposal:
http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.03/
Overall, I'm ok with what's proposed. This is more straightforward to
parse/understand than trying to adjust NativeSeedGenerator to
To the actual proposal:
http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.03/
Overall, I'm ok with what's proposed. This is more straightforward to
parse/understand than trying to adjust NativeSeedGenerator to
create/call directly (e.g. UNIX: new
Hi Brad,
I am glad that you came across all the threads on this topic. I agree
with your evaluation of my comments from an early thread. I have gone
through security providers infrastructure multiple times since then and
I can see where my comments were incorrect. The confusion was mostly
On 12/17/2014 06:37 PM, Peter Levart wrote:
Martin wrote:
https://bugs.openjdk.java.net/browse/JDK-8047769
If you've been following this bug, I've figured why the NativePRNG$*
classes are initing and thus opening the /dev/random,urandom. This
definitely needs some adjustment.
Something
Various comments for this thread from June/July/November/December.
Some of the comments I'm responding to may already be better understood
than when they were originally written.
Peter wrote in response to a suggestion to use /dev/random:
Although the approach would cause some more classes
Hi Doug,
On 12/06/2014 05:14 PM, Doug Lea wrote:
On 12/04/2014 07:22 PM, Doug Lea wrote:
Because Random, SplittableRandom, and ThreadLocalRandom all use the
same basic approach, they can/should use the same mechanism.
In other words, to establish a common default-constructor-seed
generator
On 12/04/2014 07:22 PM, Doug Lea wrote:
Because Random, SplittableRandom, and ThreadLocalRandom all use the
same basic approach, they can/should use the same mechanism.
In other words, to establish a common default-constructor-seed
generator internal to the JDK. So we only need one
On 12/04/2014 12:32 AM, Martin Buchholz wrote:
On Wed, Dec 3, 2014 at 2:15 PM, Doug Lea d...@cs.oswego.edu wrote:
No public API because systemSeed need only be implemented
inside TLR, for its initial seed. Then the others can get their seeds
using ThreadLocalRandom.current().nextLong(), unless
On 12/04/2014 09:20 AM, Peter Levart wrote:
P.S. Is anyone interested in generating truly random bytes?
http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf
https://software.intel.com/en-us/tags/35970
Maybe not a good idea:
http://en.wikipedia.org/wiki/RdRand#Reception
Hi,
I think we may be over-rotating a little on this.
There is already a mechanism to create a cryptographically strong seed by
setting a system property and using SecureRandom. That has a high
initialization cost, but i think under those circumstances that cost is
acceptable (it may well be
On 12/04/2014 10:40 AM, Paul Sandoz wrote:
Hi,
I think we may be over-rotating a little on this.
There is already a mechanism to create a cryptographically strong seed by
setting a system property and using SecureRandom. That has a high
initialization cost, but i think under those
On 12/04/2014 09:20 AM, Peter Levart wrote:
So what we have here is two desires:
- we want a resource-friendly / with as little dependencies as
possible way to generate some unique seed, with implicit fall-back
which need not be secure
- we want a resource-friendly / with as little
On 12/04/2014 04:40 AM, Paul Sandoz wrote:
There is already a mechanism to create a cryptographically strong seed by
setting a system property and using SecureRandom. That has a high
initialization cost, but i think under those circumstances that cost is
acceptable (it may well be possible to
On 02/12/2014 22:34, Martin Buchholz wrote:
:
Martin's pet peeve: use readFully (why doesn't InputStream support
that yet?!) copy-paste from elsewhere in the jdk.
I agree, I think this should be #2 on the list to look at as part of the
I/O convenience methods thread.
-Alan
Hi,
On 12/02/2014 01:02 PM, Paul Sandoz wrote:
Please find below a patch to remove the networking code computing a
seed in ThreadLocal/SplittableRandom.
Looks good.
We thought it a good idea at the time :-) but subsequently on certain
platforms this results in very high initalization costs
Hi Peter,
A few questions and comments:
- Can/should this function be fit into one of the existing classes?
- Is more than one instance needed?
Seed material seems to be needed only as a one-shot so a simpler
implementation that opens,
uses and closes would leave fewer leftovers (and
On 12/02/2014 05:34 PM, Martin Buchholz wrote:
I support Peter's initiative and am willing to help review if we have
general consensus about the direction.
Peter's implementation scheme of using Unix /dev/urandom
or the Windows Crypto API (or something else on failure) seems
like the best
On Wed, Dec 3, 2014 at 7:26 AM, Doug Lea d...@cs.oswego.edu wrote:
On 12/02/2014 05:34 PM, Martin Buchholz wrote:
I support Peter's initiative and am willing to help review if we have
general consensus about the direction.
Peter's implementation scheme of using Unix /dev/urandom
or the
On 12/03/2014 12:20 PM, Martin Buchholz wrote:
I don't think such a general purpose utility belongs in
SplittableRandom or ThreadLocalRandom - those are the clients. Random
is a slightly better fit, but still not great.
Perhaps one of these could be made to be a good fit.
As of now, this
Hi all,
There seems to be a consensus that a simpler static method would be just
fine, since it will be used only to gather secure seed for other java
based PRNG implementations. UNIX file as well as Windows Crypro API
implementation are naturally exposed as open/use/close API, so I did
that
Hi Roger,
Thanks for looking at my baby steps in the JNI / Windows worlds...
Answers inline...
On 12/03/2014 03:14 PM, roger riggs wrote:
Hi Peter,
A few questions and comments:
- Can/should this function be fit into one of the existing classes?
As a static method perhaps, yes. The
On Wed, Dec 3, 2014 at 9:38 AM, Doug Lea d...@cs.oswego.edu wrote:
On 12/03/2014 12:20 PM, Martin Buchholz wrote:
I don't think such a general purpose utility belongs in
SplittableRandom or ThreadLocalRandom - those are the clients. Random
is a slightly better fit, but still not great.
On 12/03/2014 02:03 PM, Martin Buchholz wrote:
On Wed, Dec 3, 2014 at 9:38 AM, Doug Lea d...@cs.oswego.edu wrote:
... Of the two choices, housing the code in ThreadLocalRandom
seems logistically a bit easier. Then SplittableRandom could use
private static final AtomicLong defaultGen =
On Wed, Dec 3, 2014 at 2:15 PM, Doug Lea d...@cs.oswego.edu wrote:
No public API because systemSeed need only be implemented
inside TLR, for its initial seed. Then the others can get their seeds
using ThreadLocalRandom.current().nextLong(), unless
java.util.secureRandomSeed is set (which I
On 02/12/2014 10:02, Paul Sandoz wrote:
Hi,
Please find below a patch to remove the networking code computing a seed in
ThreadLocal/SplittableRandom.
We thought it a good idea at the time :-) but subsequently on certain platforms
this results in very high initalization costs that can
On Dec 2, 2014, at 11:10 AM, Alan Bateman alan.bate...@oracle.com wrote:
On 02/12/2014 10:02, Paul Sandoz wrote:
Hi,
Please find below a patch to remove the networking code computing a seed in
ThreadLocal/SplittableRandom.
We thought it a good idea at the time :-) but subsequently on
On 12/02/2014 05:02 AM, Paul Sandoz wrote:
Hi,
Please find below a patch to remove the networking code computing a seed in
ThreadLocal/SplittableRandom.
Thanks for pushing this through.
(I also adjusted 166 sources accordingly.)
One more touch-up for SplittableRandom is to remove mention
of
On Dec 2, 2014, at 1:17 PM, Doug Lea d...@cs.oswego.edu wrote:
On 12/02/2014 05:02 AM, Paul Sandoz wrote:
Hi,
Please find below a patch to remove the networking code computing a seed in
ThreadLocal/SplittableRandom.
Thanks for pushing this through.
(I also adjusted 166 sources
On Dec 2, 2014, at 5:42 PM, Peter Levart peter.lev...@gmail.com wrote:
On 12/02/2014 11:02 AM, Paul Sandoz wrote:
Hi,
Please find below a patch to remove the networking code computing a seed in
ThreadLocal/SplittableRandom.
We thought it a good idea at the time :-) but subsequently on
On 02/12/2014 16:42, Peter Levart wrote:
:
Here's a proof of concept for an API that just delegates to
system-provided cryptographically secure (as declared by the
system(s)) pseudo random number generator:
http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.01/
The API looks
I support Peter's initiative and am willing to help review if we have
general consensus about the direction.
From superficial review:
+int nread = randomStream.read(bytes);
+if (nread != bytes.length) {
+throw new InternalError(Short read from:
32 matches
Mail list logo
