commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (RNG-59) More robust "SeedFactory"
Date Thu, 25 Oct 2018 15:23:00 GMT

     [ https://issues.apache.org/jira/browse/RNG-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Gilles resolved RNG-59.
-----------------------
    Resolution: Fixed

Commit 350fb428eaf42a0ece8ebc59714201d590f6ff94 ("master" branch).

> More robust "SeedFactory"
> -------------------------
>
>                 Key: RNG-59
>                 URL: https://issues.apache.org/jira/browse/RNG-59
>             Project: Commons RNG
>          Issue Type: Improvement
>          Components: simple
>    Affects Versions: 1.0, 1.1
>            Reporter: Gilles
>            Priority: Major
>             Fix For: 1.2
>
>
> {{SeedFactory}} will produce the same seed when several instances of the same program
are launched in rapid successions.
> In the _static_ block of {{SeedFactory}}, an initial "random" seed is generated using
{{System.currentTimeMillis()}}.
> I think that it should be replaced by retrieving data from a {{SecureRandom}} instance.
> The drawback is that instantiating such an object is necessary slower.  However if it
is the way to go (to ensure different initial seeds in parallel runs of a program), the question
is whether to use only {{SecureRandom}} to create the (relatively large) state of the RNG
used by the {{SeedFactory}} or to use it only to generate 8 bytes (and proceed with the rest
of the _static_ block as it is now).
> I'm planning to follow the advice [here|https://tersesystems.com/blog/2015/12/17/the-right-way-to-use-securerandom/],
i.e. fill the whole state with the system's default RNG.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message