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