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