1 2 Previous Next 16 Replies Latest reply on Jun 4, 2012 7:08 AM by bfluri Go to original post
      • 15. Re: Errai client-side startup problem
        almac

        Beat Fluri wrote:

         

        What I don't understand: why does it take so long to create a seed; what's the idea behind this seed algorithm? During that time, the CPU of the production system is hardly used? Do you have some references for me to read?

         

        The bulk of the time is/was spent waiting for /dev/random to produce bits. This device is a high-quality blocking source of random bits, which do not come from (deterministic) computation, but rather from real-world random events, like I/O.  A machine with very little I/O collects random bits very slowly. And errai was (originally) asking for a lot of random bits, given what it was trying to do.  (You can read about /dev/random in wikipedia.)

         

        /dev/urandom is a lower-quality bit source:  it recycles the pool to maintain the illusion of random bits even if its pool is low on entropy, so that it doesn't block waiting for more entropy to collect.  Chris' suggestion is a way to tell the java crytpto library to use /dev/urandom instead of /dev/random.  The pathname is strange due to a long-standing mess deep in the bowels of the java library:  http://bugs.sun.com/view_bug.do?bug_id=4705093

         

        I still don't understand what errai's SecureHashUtil.nextSecureHash(...) is trying to do:  if all it needs to produce is a nonce for a session-id, I'd think it could just get N bytes from a SecureRandom generator and be done with it, since that is what crypto-secure RNG's do.  I don't see the benefit of hashing the random bytes with the HTTP session-id and remote client-id, nor do I see a benefit to "re-hashing-the-hash" 100 times over (see _nextSecureHash()).

        • 16. Re: Errai client-side startup problem
          bfluri

          Thanks a lot Alvin for this detailed explanation!

          1 2 Previous Next