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
* 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)
{
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
