The function signature
*hash*_End( , , unsigned *digestLen, unsigned maxDigestLen )
let assume that the original goal of this design - is to ensure
dynamic configuration of the buffer length in two steps. This is like
GNU libc 'snprintf()' or Win32 'GetTempPath()', etc. At 1st step you
try to accomplish the action with buffer of arbitrary length
(including zero), and, if the length is not sufficient, you get back
the length of the buffer required. At 2nd step you accomplish the action.
You are over thinking. This API is not for applications, but for
softoken. Softoken knows the length of the digest already (supplied in
the HashTable). It already implements exactly what you describe on top
of your code.
If you are required to supply a generic API that many applications need
to call, then I would agree with you, but the PKCS #11 layer already
handles this. The API applications call already return a short buffer,
and provides that application with the length of the full hash on a
'zero'/NULL case.
To support this scenario *hash*_End() should place required length to
digestLen. Placing the number of bytes written into the digestLen is
less useful, - we can only be sure digest is written completely if
(digestLen < maxDigestLen). If (digestLen >= maxDigestLen) we do not
know neither we have full digest, nor which length it is.
This, in general is how the PKCS #11 api works, which is the API
applications get. You don't have to implement the semantics in your code
again to get this. (In fact it won't end up being used if you do,
because the upper layers will always make sure the length is specified
correctly.... you don't really think we ASSERT all over the place when
applications try to use SHA1 did you?
My point is you can implement this API is you want. it will continue to
work because all the code that will ever call it already handles the
block size appropriately.
To Robert Relyea: On 15 Sep 2009 you wrote about "Rus GOST 89":
... solution would be to add the new algorithm as a separately loaded
PKCS #11 module
[... SKIP ...]
The one thing I still really need to make this work is a way to
automatically add the new algorithm's configuration.
May the scenario above reduce the number of configuration parameters
for dynamically added hash algorithms ?
There are already a host of things that are necessary for configuration
of a new hash algorithm (including appropriate oids and PKCS #11
mechanisms. Adding the hashlen is a pretty small burden).
Of course it's also totally irrelevent to freebl, the API for the
dynamically added hashes would be PKCS 11, with already define exactly
what you propose.
Hope this helps clarify things.
bob
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
