Use HMAC SHA-256, since SHA-1 won't work inside the Windows sandbox.

Use HMAC SHA-256, since SHA-1 won't work inside the Windows sandbox.

BUG=91878
TEST=Can connect remoting Client on Windows, with sandbox active, to a Host.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=95946

[Wez, 2011-08-09 00:31:29]

PTAL

[Jamie, 2011-08-09 00:32:39]

Wasn't there some talk of bumping the protocol version number as well?

[Wez, 2011-08-09 01:25:55]

On 2011/08/09 00:32:39, Jamie wrote:
> Wasn't there some talk of bumping the protocol version number as well?

There was, and I'll do that.  However, there is currently no way to make the
client reflect that particular reason for failing.

[Sergey Ulanov, 2011-08-09 01:51:12]

LGTM

On 2011/08/09 01:25:55, Wez wrote:
> On 2011/08/09 00:32:39, Jamie wrote:
> > Wasn't there some talk of bumping the protocol version number as well?
> 
> There was, and I'll do that.  However, there is currently no way to make the
> client reflect that particular reason for failing.

[wtc, 2011-08-09 16:37:23]

This CL will prevent us from changing the HMAC SHA-256 implementation
to use Windows CryptoAPI in the future.  (The current HMAC SHA-256
implementation doesn't use Windows CryptoAPI because CryptoAPI doesn't
support SHA-256 in Windows XP SP2 or earlier.)

I wonder if our Windows sandbox can be relaxed to allow CryptoAPI
to work without accessing persistent keys.

[Alpha Left Google, 2011-08-09 16:49:59]

How does persistent keys get used? I thought we use CRYPT_VERIFYCONTEXT most of
the time.

[wtc, 2011-08-09 17:00:46]

On 2011/08/09 16:49:59, Alpha wrote:
> How does persistent keys get used? I thought we use CRYPT_VERIFYCONTEXT most
of
> the time.

hclam: yes, you are right.

I meant that we should relax the Windows sandbox so that we
can call CryptAcquireContext with the CRYPT_VERIFYCONTEXT flag.
(The CRYPT_VERIFYCONTEXT flag means we do NOT need access to
persistent keys.)

[Wez, 2011-08-09 17:09:55]

On 2011/08/09 16:37:23, wtc wrote:
> This CL will prevent us from changing the HMAC SHA-256 implementation
> to use Windows CryptoAPI in the future.  (The current HMAC SHA-256
> implementation doesn't use Windows CryptoAPI because CryptoAPI doesn't
> support SHA-256 in Windows XP SP2 or earlier.)
> 
> I wonder if our Windows sandbox can be relaxed to allow CryptoAPI
> to work without accessing persistent keys.

What is the motivation for switching to the CryptoAPI version?

[wtc, 2011-08-10 01:14:15]

On 2011/08/09 17:09:55, Wez wrote:
>
> What is the motivation for switching to the CryptoAPI version?

The crypto module in CryptoAPI in every version of Windows has been
validated for conformance to the FIPS 140-2 standard.  FIPS 140-2
validation is required by US Federal and Canadian government agencies.
I'd like to have the option of using CryptoAPI available because
that is one way for Chrome to achieve FIPS 140-2 conformance.

[Wez, 2011-08-10 03:03:01]

On 2011/08/10 01:14:15, wtc wrote:
> On 2011/08/09 17:09:55, Wez wrote:
> >
> > What is the motivation for switching to the CryptoAPI version?
> 
> The crypto module in CryptoAPI in every version of Windows has been
> validated for conformance to the FIPS 140-2 standard.  FIPS 140-2
> validation is required by US Federal and Canadian government agencies.
> I'd like to have the option of using CryptoAPI available because
> that is one way for Chrome to achieve FIPS 140-2 conformance.

OK; so we'll need to arrange to load CryptoAPI ahead of time, or allow for this
code to choose the NSS implementation.