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