Ok, so it seems clear that we only want to create one of these, but
since it's not thread safe how are we going to share it? Are we
going to need a thread-safe wrapper class?
Kumar Jayanti wrote on 09/02/09 05:47:
> I just tried to collect some info before getting down to defining the
> class :
>
> ------------------------
> From the SSL FAQ :
> Q: It seems the first SSL connection takes longer than subsequent
>
> connections. Is there anything I can do to improve the performance of
> the first connection?
>
> A: The SSLContext needs a java.security.SecureRandom object. It is
> expensive to seed a SecureRandom object. You should see better
> performance for the first connection if you can provide a pre-seeded
> SecureRandom
> object when initializing the SSLContext. However, extreme care should be
> taken in such action as seeding is an important aspect of cryptographic
> effectiveness.
> ------------------------
>
> From the javadocs of SecureRandom :
>
> public SecureRandom()
>
> Constructs a secure random number generator (RNG) implementing the
> default random number algorithm. The returned SecureRandom object has
> not been seeded. To seed the returned object, call the setSeed method.
> If setSeed is not called, the first call to nextBytes will force the
> SecureRandom object to seed itself. This self-seeding will not occur if
> setSeed was previously called.
>
> -----------------------------
> From a Sun forum Thread : http://forums.sun.com/thread.jspa?
>
> forumID=9&threadID=410950
>
> Cipher's, AlgorithmParameters, and SecureRandom objects are not thread
> safe. None of the JCE providers use synchronized anywhere. Additonally,
> multiple threads using the same cipher at the same time makes little
> sense.
>
> Now from what you are talking about where you are using a pool you are
> fine so long as your pool is thread safe and that the pool garuntees
> that only a single thread will ever be working with a single (crypto)
> object at a time. You can reuse a cipher, alg parameter, or secure random
> object without fear.
>
> There is one small gotcha on the SecureRandom. SecureRandom uses a seeding
> method by default which gives you a certain level of entropy. That entropy
> is effective for probably upto 200 or 300 bytes. After that it becomes less
> than effective random. So every time it is checked into the pool it should
> be reseeded. If you have a /dev/random and you are using a newer version of
> java and the JCE then this should not be an issue for you. Just call
> generateSeed(N); and then setSeed() when it is checked in.
>
> ---------------------------------
>
>
> SecureRandom :
> http://javaboutique.internet.com/resources/books/JavaSec/javasec3_3.html
>
> SecureRandom is easy to use. We can construct one normally, with the
> default constructor, and then pass byte arrays to it with nextBytes()
> and receive them back filled with random data. For instance, to create
> an 8-byte array using secure random we could do the following:
>
> byte[] randomBytes = new byte[8];
> SecureRandom random = new SecureRandom();
> random.nextBytes(randomBytes);
>
> As an aside, you may have noticed a delay during the running of the
> examples we have seen so far and wondered what causes it. Well, it's not
> the encryption that's so slow; it's the initialization of
> java.security.SecureRandom. Sun's implementation of SecureRandom creates
> a great number of threads and checks their interaction over a period of
> time. It then uses that to initialize a Pseudo-Random Number Generator
> (PRNG). It's the thread creation and interaction that takes so long.
>
> To combat this, a couple of providers have created implementations of
> SecureRandom that are at least partially native, giving a huge speed
> increase in the seeding of the random number generator. Cryptix
> (http://www.cryptix.org) provides an implementation that runs on Linux
> and the various BSDs, and Virtual Unlimited
> (http://www.virtualunlimited.com) provides one for Windows.
>
> Also, the initialization of SecureRandom is only expensive the first
> time it's done in a single Java VM instance. If you have a long-running
> program or a server, you can initialize SecureRandom on startup and all
> later operations will run quite quickly. You may also want to try to
> architect your programs so that they run for a longer period of time
> rather than starting and stopping often. This would allow you to
> amortize the cost of initialization.
>
> regards,
> kumar
>
>
> Bill Shannon wrote:
>> Kumar Jayanti wrote on 08/28/09 02:38:
>>> Bill Shannon wrote:
>>>> Kedar Mhaswade wrote on 8/27/09 11:28 AM:
>>>>
>>>>> Bill Shannon wrote:
>>>>>
>>>>>> Kedar Mhaswade wrote on 8/26/09 5:39 PM:
>>>>>>
>>>>>>
>>>>>>>> Maybe someone should just put an instance of SecureRandom in the
>>>>>>>> Habitat
>>>>>>>> so everyone can get it by injection and use it?
>>>>>>>>
>>>>>>> That's doable.
>>>>>>>
>>>>>> So who should do it?
>>>>>>
>>>>> I think an appropriate place for this is SecurityService that Kumar
>>>>> owns. I also have
>>>>> an IdmService that does some identity management related stuff.
>>>>> It's an
>>>>> Init Service, and I can create the global SecureRandom there. It can
>>>>> be the usual Contract/Service thingie. Let me know what you guys
>>>>> prefer.
>>>>>
>>>>
>>>> Since I need to use it in the LocalPassword init service, it needs to
>>>> be done before then. Is there a way to control order of init services?
>>>> Or should it be done by the GlassFish startup code that calls the init
>>>> services?
>>>>
>>>> Kumar, are you the right person to own this?
>>>>
>>> I will just need to think a little bit and i can send a proposal.
>>> Also as i said, i would not put it inside security/core module since
>>> it can cause circular dependency issues which we better avoid at this
>>> time. I would like to put it in internal-api.
>>
>> Thanks.
>>
>>> Should it be a static singleton or a HK2 singleton. If you have an
>>> opinion send me your thoughts.
>>
>> An HK2 singleton seems fine, but I don't have a strong opinion.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>