On Tue, Sep 15, 2009 at 8:51 AM, Andreev Konstantin <andr...@swemel.ru> 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() ?
>
> 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.
Thank you for the bug report. The semantics of SHA{256,384,512}_End
are the closest to what I would expect, based on my experience with
other NSS crypto functions. I would expect that on return, *digestLen
contains the number of bytes written.
Also note that there are <Hash>_HashBuf functions that require
you to know the output length of a hash algorithm. So I think the
FreeBL hash functions assume that the callers know the hash
output length.
Wan-Teh
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
