Closed Bug 775337 Opened 13 years ago Closed 13 years ago

<Hash>_HashBuf should zero its local context variable before returning

Categories

(NSS :: Libraries, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wtc, Assigned: wtc)

References

Details

Attachments

(1 file)

Attached patch Proposed patchSplinter Review
This was originally suggested by David Cooper in bug 590515 comment 8. The <Hash>_HashBuf functions, such as SHA256_HashBuf, should zero their local context variables before returning because we often hash secret data. This matches the behavior of <Hash>_DestroyContext. I also discovered that most <Hash>_DestroyContext functions zero their context arguments only if the 'freeit' argument is true. I also changed them to always zero their context arguments, matching the behavior of SHA1_DestroyContext.
Attachment #643635 - Flags: superreview?(rrelyea)
Attachment #643635 - Flags: review?(dcooper16)
Comment on attachment 643635 [details] [diff] [review] Proposed patch r+ rrelyea. I suspect this was a nelson optimization to get a few extra percent. bob
Attachment #643635 - Flags: superreview?(rrelyea) → superreview+
Attachment #643635 - Flags: review?(dcooper16) → review+
Patch checked in on the NSS trunk (NSS 3.14). Checking in md5.c; /cvsroot/mozilla/security/nss/lib/freebl/md5.c,v <-- md5.c new revision: 1.16; previous revision: 1.15 done Checking in sha512.c; /cvsroot/mozilla/security/nss/lib/freebl/sha512.c,v <-- sha512.c new revision: 1.21; previous revision: 1.20 done Checking in sha_fast.c; /cvsroot/mozilla/security/nss/lib/freebl/sha_fast.c,v <-- sha_fast.c new revision: 1.15; previous revision: 1.14 done
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: