SecureRandom speed up

[dimazig]

Hi team,

Have you considered somehow to speed up SecureRandom initialization
For now I created a hack like that:

@Component
public class SecureRandomPreloaderCustomizer implements WebServerFactoryCustomizer<TomcatServletWebServerFactory>, Ordered {

    @Override
    public void customize(TomcatServletWebServerFactory factory) {
        factory.addContextCustomizers((TomcatContextCustomizer) new TomcatContextCustomizer() {
            @Override
            public void customize(Context context) {
                context.addPropertyChangeListener(new PropertyChangeListener() {
                    @Override
                    public void propertyChange(PropertyChangeEvent evt) {
                        if ("manager".equals(evt.getPropertyName())) {
                            new Thread(() -> {
                                context.getManager().getSessionIdGenerator().generateSessionId();
                            }).start();
                        }
                    }
                });
            }
        });

    }




    @Override
    public int getOrder() {
        return 0;
    }

}

[wilkinsona]

Yes. We already configure the Manager with LazySessionIdGenerator which initialises SecureRandom on first use rather than during startup. This ensures that the cost of SecureRandom initialization is only paid by applications that use sessions. In my opinion, that's preferable to using a separate thread for initialisation as not all environments will parallelize particularly well and even in those that do, there's still a cost to initialising SecureRandom that will be unnecessary for some apps. Thanks anyway for the suggestion.

[dimazig]

that's the problem with your solution that the first user has to wait for unreasonable time while initialisation in parallel gives chance to avoid this. I don't demand to change yiur default settings but yiu hardcoded your lazy generator so digging thorough your code this is the only solution I found to enforce triggering securerandom initialisation. This part should be customasable, not hardcoded as you've done

[dimazig]

In my opinion I should be able to register my own sessionid generator as a spring bean and it should be applied automatically if found. if not then use your lazy one

[wilkinsona]

Configuring Tomcat to defer initialisation of SecureRandom aligns it with both Undertow and, IIRC, Jetty. We believe it is the best option for most applications. Given that it's been that way since 1.4 (see #6174) and this is the first time anyone has suggested doing something differently, it appears that Spring Boot's user base broadly agrees.

Thanks for the suggestion of using a bean, but that doesn't really fit with the existing model of embedded container customisation. Using a more general purpose customiser, such as the context customiser you have used above, is our preferred approach. The alternative would be to offer a property to control whether or not the initialisation was done lazily. We generally only offer properties for settings that we think will be fairly widely used and I don't think this meets that criteria. If you'd like the initialisation to be done up front, you existing customiser-based approach is what I would recommend.

[dimazig]

ok. I'll do my way. I'm trying to initialise it not in advance but in parallel with general initialisation which I find the best as it does not affect the the whole system initialisation time and doesn't annoy the first user as on some servers this initialisation might take up to a minute as not much entropy comparing to desktop pc. Also I can't agree that no one complains. If you Google with words securerandom spring boot there'll be lots of discussions about it

[shakuzen]

@dimazig If you configure the JVM to use /dev/urandom instead of /dev/random, it will solve your blocking issue. (see also Myths about /dev/urandom)