[PATCH] Add class java.security.StandardMessageDigests

[Xuelei Fan]

> On May 5, 2014, at 9:09 PM, Florian Weimer <fweimer at redhat.com> 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();
>> 
>> What's the context that this new class is supposed to use?
> 
> 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 it might be a better place to make the improvement in crypto providers.  BTW! I guess in some situation or some providers, clone() might not be a lightweight operation.

>  I forgot to mention that the benchmark numbers I posted include that, to make them more realistic.  If I only measure the cost of instantiation and a single-byte update, the numbers are as follows:
> 
> Benchmark                                       Mode   Samples Mean   Mean error    Units
> o.o.j.b.StandardMessageDigestsBenchmark.get    thrpt       200 6292.827      178.149   ops/ms
> o.o.j.b.StandardMessageDigestsBenchmark.smd    thrpt       200 10018.883      294.193   ops/ms
> 
> 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.

>  The difference will be more visible once we have message digests with hardware support (which is apparently around the corner for SHA-1 and SHA-256).
> 
> We could also revisit the decision about NoSuchAlgorithmException:
> 
>>>> I deliberately did not include support for MD5.  It would be nice if we
>>>> could drop the NoSuchAlgorithmException, but this would be problematic
>>>> once there are providers that do not support SHA-1.
> 
> If we guarantee that the algorithms are always supported, we could drop the checked exception, making it easier to initialize objects.  This would be an added benefit, then.
It cannot be guaranteed in JRE level.  The supported algorithms should totally depend on crypto providers, although java may suggest a minimal supported algorithm set.

Thanks & Regards,
Xuelei

> -- 
> Florian Weimer / Red Hat Product Security Team