How about adding a log message on component activation (if fast seeding is off) which says something like "The generation of securely random numbers on some operating systems can take up to several minutes depending upon environment factors. If this is a problem for you, set the system property java.security.egd to file:/dev/./urandom or enable the "fast seeding" mode in the OSGi web console"
Justin On 9/6/10 9:41 AM, Felix Meschberger wrote: > Thanks for the feedback. > > I committed the patch but did not enable the "fast seeding" by default > because I am not really sure how strong it is for general use. > > But I have no strong feelings about it and if the general consensus is > to enable it by default, we can change this. > > Regards > Felix > > On 06.09.2010 13:10, Ian Boston wrote: >> Yes LvGTM, I like the MD5 of tmp names to create non sequential entropy. >> I am almost tempted to say this should be on by default. >> Ian >> >> On 6 Sep 2010, at 10:57, Felix Meschberger wrote: >> >>> Hi, >>> >>> I have implemented a different method to generate a seed value for the >>> SecureRandom number generator and attached to SLING-1729 [1]. This >>> method is not used by default and must be explicitly enabled using >>> configuration. >>> >>> Does this make sense ? >>> >>> Regards >>> Felix >>> >>> [1] >>> https://issues.apache.org/jira/secure/attachment/12453934/SLING-1729.patch >>> >>> On 06.09.2010 08:51, Felix Meschberger wrote: >>>> Hi, >>>> >>>> I have run both your tests with no differing behaviour. I got >>>> non-blocking results when setting the java.security.egd system property >>>> as follows: >>>> >>>> -Djava.security.egd=file:/dev/./urandom >>>> >>>> Note "/./" notation, which seems to be required to not have Java use >>>> /dev/urandom as an alias for /dev/random.... >>>> >>>> So I wonder whether we could do something like this in the form handler: >>>> >>>> if (exists /dev/random) { // check for Linux >>>> set system property java.security.egd=file:/dev/./urandom >>>> } >>>> explicitly seed SecureRandom >>>> reset java.security.egd system property >>>> >>>> Its not nice but would solve the problem .... >>>> >>>> Regards >>>> Felix >>>> >>>> >>>> On 05.09.2010 11:16, Ian Boston wrote: >>>>> java.util.Random does not have enough entropy to be used for security >>>>> purposes. IIRC the sequence can be repeated as the seed is based on the >>>>> epoch, and so is predictable. >>>>> You could use it, but the keys would be predictable and since these keys >>>>> are used to generate the HMACs for all user logins, then it would be >>>>> relatively easy to zero in on the key by watching generated HMACs and >>>>> looking for the points at which they change, and expire. >>>>> If there was 1 key for all time, even SecureRandom would not be good >>>>> enough, which is why the keys rotate every 5 min and expire after 30min >>>>> (configurable). >>>>> >>>>> So, in this instance we have to use SecureRandom. >>>>> ---------------------------------------------------------------------------- >>>>> >>>>> The problem is down to the configuration for SecureRandom on the OS >>>>> platform. And the way we get an instance. I think we do >>>>> getInstance(SHA1PRNG), but that might be a mistake as it will force the >>>>> JRE to use that one, (see notes on [1]) >>>>> >>>>> IIRC on Solaris and Linux un.security.provider.NativePRNG is used which >>>>> binds to /dev/urandom or equiv. On WIndows SHA1PRNG is used. also IIRC >>>>> SHA1PRNG will use the OS's random generator to provide the seed, so >>>>> whatever PRNG you use, it will always need a seed and the seed is OS >>>>> depenant >>>>> >>>>> You can set the source using securerandom.source in the JRE or >>>>> -Djava.security.egd=file:/dev/urandom on the command line. >>>>> >>>>> However, there are some JRE bugs in various versions, see [1]. >>>>> >>>>> Can you try running the following 2 tests on you OS to see if there is >>>>> any difference. >>>>> >>>>> import java.security.SecureRandom; >>>>> >>>>> public class Test { >>>>> public static void main(String args[]) throws Exception { >>>>> SecureRandom rnd = SecureRandom.getInstance("SHA1PRNG"); >>>>> for (int i=0; i < 1000; i++) { >>>>> rnd.generateSeed(256); >>>>> System.out.println("Got " + i); >>>>> } >>>>> } >>>>> } >>>>> >>>>> and >>>>> >>>>> import java.security.SecureRandom; >>>>> >>>>> public class Test2 { >>>>> public static void main(String args[]) throws Exception { >>>>> SecureRandom rnd = SecureRandom.getInstance(); >>>>> for (int i=0; i < 1000; i++) { >>>>> rnd.generateSeed(256); >>>>> System.out.println("Got " + i); >>>>> } >>>>> } >>>>> } >>>>> >>>>> HTH >>>>> Ian >>>>> >>>>> 1 >>>>> http://bugs.sun.com/view_bug.do;jsessionid=e1244ca9c599cffffffffd8eb336175a921b?bug_id=6202721 >>>>> >>>>> >>>>> On 3 Sep 2010, at 22:25, Felix Meschberger wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I noticed slow (extremely slow, actually: something like 30seconds) >>>>>> startup of the Form Authentication Handler [1]. Tracking this down I >>>>>> found, that the SecureRandom implementation uses /dev/random which may >>>>>> block indefinitely to gather enough entropy to ensure secure random byte >>>>>> stream. >>>>>> >>>>>> Now, a local quick hack solution is to create a symbolic link from >>>>>> /dev/urandom to /dev/random. But I don't think this is the right >>>>>> solution in the long run -- and I doubt this is a viable solution on a >>>>>> server system. >>>>>> >>>>>> I wonder, whether we really new SecureRandom here or whether >>>>>> java.util.Random would just be random enough ? >>>>>> >>>>>> Do others have experience with this ? >>>>>> >>>>>> (ah, Sun has a whole range of bugs for this /dev/random issue) >>>>>> >>>>>> Regards >>>>>> Felix >>>>>> >>>>>> >>>>>> [1] https://issues.apache.org/jira/browse/SLING-1729 >>>>> >>>>> >> >>
