On 09/15/2009 08:51 AM, Andreev Konstantin wrote:
Hello.
At the moment NSS head supports 6 hash algorithm:
md2,md5,sha{,-256,-384,-512}.
However, their implementations in freebl backend have no consistent
semantics for method
*hash*_End( Context *, unsigned char *digest, unsigned int
*digestLen, unsigned int maxDigestLen )
Look how various hashes handle (maxDigestLen < REAL_HASH_LENGTH) case:
MD2_End,MD5_End:
PORT_SetError(SEC_ERROR_INVALID_ARGS) then return.
- there is no other indication to the caller about error occured
- they do not care about clearing error if maxDigestLen is
sufficient
SHA1_End:
application dies with post-mortem message.
SHA{256,384,512}_End:
return only maxDigestLen of digest
- there is no error indication to the caller at all
I should correctly add GOST hash algorithm to the NSS, but which
semantics should I implement for GOST_End() ?
These are private interfaces for NSS softoken, applications can not call
them directly. It's fine to require maxDigestLen to be at least
REAL_HASH_LENGTH. You may assert or not in GOST.
I would propose to unify *hash*_End() semantics for (maxDigestLen <
REAL_HASH_LENGTH) as follows:
1) return only maxDigestLen of digest
2) always set digestLen to the real hash length.
3) do *not* kill application (this is unfriendly), do not
SetError(). The caller can always detect digest buffer shortage from
the fact (digestLen > maxDigestLen), and caller now knows required
buffer length from digestLen.
You are assuming applications have access to these functions. If the
caller passes something less than REAL_HASH_LENGTH for maxDigestLen,
then it's a bug in the internals of NSS. If this were to change we would
also update the remaining hash functions.
bob
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
