Re: [PATCH] SHA1 clarify kerneldoc

[Bill Davidsen]

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@xxxxxxx)
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/