From: Bill Davidsen <davidsen@tmr.com>
To: Matt Mackall <mpm@selenic.com>
Cc: Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>,
Andrew Morton <akpm@osdl.org>, "Theodore Ts'o" <tytso@mit.edu>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] SHA1 clarify kerneldoc
Date: Thu, 27 Jan 2005 13:22:28 -0500 [thread overview]
Message-ID: <41F93164.9000508@tmr.com> (raw)
In-Reply-To: <20050125215015.GQ12076@waste.org>
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
next prev parent reply other threads:[~2005-01-27 18:21 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-21 21:41 [PATCH 0/12] random pt4: Moving and sharing code Matt Mackall
2005-01-21 21:41 ` [PATCH 1/12] random pt4: Create new rol32/ror32 bitops Matt Mackall
2005-01-21 21:41 ` [PATCH 2/12] random pt4: Use them throughout the tree Matt Mackall
2005-01-21 21:41 ` [PATCH 3/12] random pt4: Kill the SHA variants Matt Mackall
2005-01-21 21:41 ` [PATCH 4/12] random pt4: Cleanup SHA interface Matt Mackall
2005-01-21 21:41 ` [PATCH 5/12] random pt4: Move SHA code to lib/ Matt Mackall
2005-01-21 21:41 ` [PATCH 6/12] random pt4: Replace SHA with faster version Matt Mackall
2005-01-21 21:41 ` [PATCH 7/12] random pt4: Update cryptolib to use SHA fro lib Matt Mackall
2005-01-21 21:41 ` [PATCH 8/12] random pt4: Move halfmd4 to lib Matt Mackall
2005-01-21 21:41 ` [PATCH 9/12] random pt4: Kill duplicate halfmd4 in ext3 htree Matt Mackall
2005-01-21 21:41 ` [PATCH 10/12] random pt4: Simplify and shrink syncookie code Matt Mackall
2005-01-21 21:41 ` [PATCH 11/12] random pt4: Move syncookies to net/ Matt Mackall
2005-01-21 21:41 ` [PATCH 12/12] random pt4: Move other tcp/ip bits " Matt Mackall
2005-01-26 1:33 ` [PATCH 7/12] random pt4: Update cryptolib to use SHA fro lib Lee Revell
2005-01-26 1:42 ` Matt Mackall
2005-01-25 21:07 ` [PATCH 6/12] random pt4: Replace SHA with faster version Denis Vlasenko
2005-01-25 21:14 ` Matt Mackall
2005-01-25 21:31 ` Denis Vlasenko
2005-01-25 21:50 ` [PATCH] SHA1 clarify kerneldoc Matt Mackall
2005-01-27 18:22 ` Bill Davidsen [this message]
2005-01-27 19:28 ` Matt Mackall
2005-01-25 20:49 ` [PATCH 4/12] random pt4: Cleanup SHA interface Denis Vlasenko
2005-01-25 21:01 ` Matt Mackall
2005-01-25 21:02 ` [PATCH 1/12] random pt4: Create new rol32/ror32 bitops Denis Vlasenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41F93164.9000508@tmr.com \
--to=davidsen@tmr.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=tytso@mit.edu \
--cc=vda@port.imtp.ilyichevsk.odessa.ua \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome