[PATCH] Add class java.security.StandardMessageDigests

[Florian Weimer]

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 implementation also relies on this behavior (i.e. clone() either 
consistently fails or consistently succeeds).

Note that I'm not blindly calling clone(), I'm providing a fallback in 
case clone() does not work.

> I think it might be a better place to make the improvement in crypto providers.

What kind of improvement are you thinking of?

> BTW! I guess in some situation or some providers, clone() might not be a lightweight operation.

Hmm.  I can see that the state cannot be cloned at all (that's why 
cloning is optional), but allocating a new state has to happen anyway, 
no matter how the object is constructed.

>> I think the single-block hashing case is important because it is not always possible to reuse an existing digest object after calling reset().

> It means the reset() does not work.   Looks like a bug to me.

What I meant is that there might be no place to store the reference to a 
long-term MessageDigest object which is reused again and again, so the 
best thing the code can do is to allocate a fresh object when it is needed?

Hmm, maybe we could provide a tread-local message digest that can be 
used to hash byte arrays?  It would address the simplest possible case 
where the instantiation overhead is most visible.

-- 
Florian Weimer / Red Hat Product Security Team