Good idea. Will do that. Thanks. Regards Felix
On 06.09.2010 17:10, Justin Edelson wrote: > 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 >>>>>> >>>>>> >>> >>> > >
