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 >>>> >>>> > >
