Re: [PATCH] SHA1 clarify kerneldoc

[Bill Davidsen <davidsen@tmr.com>]

Matt Mackall wrote:
> On Tue, Jan 25, 2005 at 11:31:19PM +0200, Denis Vlasenko wrote:
> 
>>On Tuesday 25 January 2005 23:14, Matt Mackall wrote:
>>
>>>On Tue, Jan 25, 2005 at 11:07:21PM +0200, Denis Vlasenko wrote:
>>>
>>>>On Friday 21 January 2005 23:41, Matt Mackall wrote:
>>>>
>>>>>- * @W:      80 words of workspace
>>>>>+ * @W:      80 words of workspace, caller should clear
>>>>
>>>>Why?
>>>
>>>Are you asking why should the caller clear or why should it be cleared at all?
>>>
>>>For the first question, having the caller do the clear avoids
>>>redundant clears on repeated calls.
>>>
>>>For the second question, forward security. If an attacker breaks into
>>>the box shortly after a secret is generated, he may be able to recover
>>>the secret from such state.
>>
>>Whoops. I understood a comment as 'caller should clear prior to use'
>>and this seems to be untrue (code overwrites entire W[80] vector
>>without using prior contents).
>>
>>Now I think that you most probably meant 'caller should clear AFTER use'.
>>If so, comment should be amended.
> 
> 
> Indeed.
> 
> Index: rc2mm1/lib/sha1.c
> ===================================================================
> --- rc2mm1.orig/lib/sha1.c	2005-01-25 09:31:59.000000000 -0800
> +++ rc2mm1/lib/sha1.c	2005-01-25 13:48:34.000000000 -0800
> @@ -25,11 +25,15 @@
>   *
>   * @digest: 160 bit digest to update
>   * @data:   512 bits of data to hash
> - * @W:      80 words of workspace, caller should clear
> + * @W:      80 words of workspace (see note)
>   *
>   * This function generates a SHA1 digest for a single. Be warned, it
                                                   ^^^^^^
Is this a term I don't know, "single" as a noun, or should "512 bit 
block" follow, as it does in crypto/sha1 from rc1-bk1 which is what I 
have handy?

>   * does not handle padding and message digest, do not confuse it with
>   * the full FIPS 180-1 digest algorithm for variable length messages.
> + *
> + * Note: If the hash is security sensitive, the caller should be sure
> + * to clear the workspace. This is left to the caller to avoid
> + * unnecessary clears between chained hashing operations.
>   */
>  void sha_transform(__u32 *digest, const char *in, __u32 *W)
>  {
> 
> 


-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me