Re: [PATCH] Add class java.security.StandardMessageDigests

On 05/06/2014 03:14 PM, Xuelei Fan wrote: True. So you think providing more efficient means for hashing relatively short byte sequences isn't worth the effort? The benefits are small, I think. It is easy to get similar improvement in application layer, but if we want add this to JRE for gen

Re: [PATCH] Add class java.security.StandardMessageDigests

On 5/6/2014 9:01 PM, Florian Weimer wrote: >> When the implementation of the underlying is unknown, it is hard to >> estimate the detailed behavior in the unknown black box. > > True. So you think providing more efficient means for hashing > relatively short byte sequences isn't worth the effort?

Re: [PATCH] Add class java.security.StandardMessageDigests

On 05/06/2014 02:35 PM, Xuelei Fan wrote: When I though about the case, the idea come to my mind was that the clone() may need to use the current states of MD. It is great if all of the current states can also be cloned to another session. But ... The PKCS#11 provider can do this. The sessi

Re: [PATCH] Add class java.security.StandardMessageDigests

>> Per the spec, clone() may throw CloneNotSupportedException. It is OK a >> certain provider does not support Cloneable. > > The key part is that the behavior has to be consistent across all > objects. It's not required that clone() works, but if it works for one > instance, it works for all of

Re: [PATCH] Add class java.security.StandardMessageDigests

On 05/06/2014 01:39 PM, Xuelei Fan wrote: Another concern of mine is about that the returned MessageDigest object heavily depends on the providers configuration when the object get instantiated for the 1st time. If the providers configuration get updated during run time, the provider of the retu

Re: [PATCH] Add class java.security.StandardMessageDigests

Another concern of mine is about that the returned MessageDigest object heavily depends on the providers configuration when the object get instantiated for the 1st time. If the providers configuration get updated during run time, the provider of the returned MessageDigest object does not get updat

Re: [PATCH] Add class java.security.StandardMessageDigests

On 05/05/2014 04:43 PM, Xuelei Fan wrote: It's 10% faster, even including the digest overhead for a single-block message. clone() is an optional operation for MD. This point may make this class unreliable. I think the MessageDigest specification requires that this works. The TLS implemen

Re: [PATCH] Add class java.security.StandardMessageDigests

> On May 5, 2014, at 9:09 PM, Florian Weimer wrote: > >> On 05/05/2014 02:31 PM, Xuelei Fan wrote: >> Comparing with the call: >>MessageDigest md = MessageDigest.getInstance("SHA-1"); >> >> What's the benefit of the following call? >> >>MessageDigest md = StandardMessageDigests.newSHA1

Re: [PATCH] Add class java.security.StandardMessageDigests

On 05/05/2014 02:31 PM, Xuelei Fan wrote: Comparing with the call: MessageDigest md = MessageDigest.getInstance("SHA-1"); What's the benefit of the following call? MessageDigest md = StandardMessageDigests.newSHA1(); What's the context that this new class is supposed to use? It's 10%

Re: [PATCH] Add class java.security.StandardMessageDigests

Comparing with the call: MessageDigest md = MessageDigest.getInstance("SHA-1"); What's the benefit of the following call? MessageDigest md = StandardMessageDigests.newSHA1(); What's the context that this new class is supposed to use? Thanks & Regards, Xuelei On 5/5/2014 7:51 PM, Florian

Re: [PATCH] Add class java.security.StandardMessageDigests

On 03/24/2014 05:30 PM, Florian Weimer wrote: This CR adds a new class java.security.StandardMessageDigests: Could I get a bug number if this change is fine in principle? Cryptographic hash functions are frequently used direct

[PATCH] Add class java.security.StandardMessageDigests

This CR adds a new class java.security.StandardMessageDigests: Could I get a bug number if this change is fine in principle? Cryptographic hash functions are frequently used directly, often for non-cryptographic purposes, so I