Update to NSS 3.14.3 Beta 1 for the TLS CBC constant-time

Update to NSS 3.14.3 Beta 1 for the TLS CBC constant-time
decoding fix.

R=agl@chromium.org,rsleevi@chromium.org
BUG=172658
TEST=none

[wtc, 2013-02-08 02:17:52]

https://codereview.chromium.org/12207073/diff/1/mozilla/security/nss/lib/free...
File mozilla/security/nss/lib/freebl/hmacct.h (right):

https://codereview.chromium.org/12207073/diff/1/mozilla/security/nss/lib/free...
mozilla/security/nss/lib/freebl/hmacct.h:6: #define _ALGHMACCT_H_

The header include guard macro doesn't match the file name.
I can fix this in the NSS upstream.

https://codereview.chromium.org/12207073/diff/1/mozilla/security/nss/lib/free...
File mozilla/security/nss/lib/freebl/md5.c (right):

https://codereview.chromium.org/12207073/diff/1/mozilla/security/nss/lib/free...
mozilla/security/nss/lib/freebl/md5.c:551: memcpy(cv, cx->cv, sizeof(cv));

Why do the <Hash>_EndRaw functions need to copy the
result in the |cx| to a local buffer and swap the bytes
there?

https://codereview.chromium.org/12207073/diff/1/mozilla/security/nss/lib/free...
File mozilla/security/nss/lib/freebl/sha_fast.h (left):

https://codereview.chromium.org/12207073/diff/1/mozilla/security/nss/lib/free...
mozilla/security/nss/lib/freebl/sha_fast.h:154: ctx->u.w[4] =
SHA_HTONL(ctx->H[4]); \

Why is it OK to change SHA_STORE_RESULT to *not* modify
the ctx->u.w array?

[agl, 2013-02-08 02:26:03]

https://codereview.chromium.org/12207073/diff/1/mozilla/security/nss/lib/free...
File mozilla/security/nss/lib/freebl/md5.c (right):

https://codereview.chromium.org/12207073/diff/1/mozilla/security/nss/lib/free...
mozilla/security/nss/lib/freebl/md5.c:551: memcpy(cv, cx->cv, sizeof(cv));
On 2013/02/08 02:17:52, wtc wrote:
> 
> Why do the <Hash>_EndRaw functions need to copy the
> result in the |cx| to a local buffer and swap the bytes
> there?

(Late - brain may not be working.)

The EndRaw functions are called multiple times on a given hash and they cannot
be destructive. When hashing a message we'll hash most of it, EndRaw, hash
another block, EndRaw, etc.

That's because the point where we stop taking EndRaw is secret, so we always
EndRaw for every block that might contain the end and pick the result from the
right one (in constant time).

https://codereview.chromium.org/12207073/diff/1/mozilla/security/nss/lib/free...
File mozilla/security/nss/lib/freebl/sha_fast.h (left):

https://codereview.chromium.org/12207073/diff/1/mozilla/security/nss/lib/free...
mozilla/security/nss/lib/freebl/sha_fast.h:154: ctx->u.w[4] =
SHA_HTONL(ctx->H[4]); \
On 2013/02/08 02:17:52, wtc wrote:
> 
> Why is it OK to change SHA_STORE_RESULT to *not* modify
> the ctx->u.w array?

SHA_STORE_RESULT is used in End and EndRaw. Previously, End was destructive -
once you called it, you couldn't add more data to the hash. (Not the mention
that it appends the hash padding). Making it non-destructive is thus making it
more general.

[wtc, 2013-02-08 17:33:01]

Thanks for answering my questions. Could you approve
the CL if it looks correct? Thanks.

[agl, 2013-02-08 18:29:08]

Opps, sorry. Forgot the LGTM.

LGTM.

[commit-bot: I haz the power, 2013-02-08 18:40:17]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/wtc@chromium.org/12207073/11002

[commit-bot: I haz the power, 2013-02-08 18:40:43]

Change committed as 181529