[PATCH] Add class java.security.StandardMessageDigests
Xuelei Fan
Xuelei.Fan at Oracle.Com
Mon May 5 14:43:34 UTC 2014
> 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
More information about the security-dev
mailing list