> On May 5, 2014, at 9:09 PM, Florian Weimer <fwei...@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
