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 session is initialized lazily, so that it doesn't have to be cloned at all if no data has been hashed yet. As far as I can tell, you end up with the same token no matter how the digest object is created (after all, there might be only one in the system), which probably incurs some synchronization overhead. But it doesn't matter if you use cloning or not. Allocation is always kind of expensive because of the finalization requirement.
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?
-- Florian Weimer / Red Hat Product Security Team
