increase crypto_unittest key sizes to satisfy NSS 3.19.1

increase crypto_unittest key sizes to satisfy NSS 3.19.1

NSS version 3.19.1 added minimum key size constraints to avoid the Logjam attack:

> The minimum size of keys that NSS will generate has been raised:
>    The minimum modulus size for RSA keys is now 512 bits
>    The minimum modulus size for DSA keys is now 1023 bits
>    The minimum modulus size for Diffie-Hellman keys is now 1023 bits

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.19.1_release_notes

https://bugzilla.mozilla.org/show_bug.cgi?id=1138554

BUG=490240
Committed: https://crrev.com/93937caf120fed43de182e475822805afdbe3001
Cr-Commit-Position: refs/heads/master@{#333554}

[Mostyn Bramley-Moore, 2015-06-03 16:00:17]

mostynb@opera.com changed reviewers:
+ agl@chromium.org, haavardm@opera.com

[Mostyn Bramley-Moore, 2015-06-03 16:00:18]

@agl: this seems to be required if using NSS 3.19.1, to avoid one gtest crash
and a few failures.

[agl, 2015-06-03 17:51:39]

agl@chromium.org changed reviewers:
+ rsleevi@chromium.org

[agl, 2015-06-03 17:51:39]

Creating several 1024-bit RSA keys might be a non-trivial amount of CPU time,
esp on weaker platforms. It might be worth hardcoding a key for the cases where
key-generation isn't being specifically tested.

But Ryan's call—he's our NSS guy.

[Ryan Sleevi, 2015-06-03 18:21:22]

Not LGTM.

This isn't needed for 3.19.1 (contrary to the description). The size checks are
in libssl when accepting certs, but neither of these tests are related to this.

We had issues with these tests timing out on bots because of the size and other
instrumentation. Raising this would end up causing these tests to be disabled,
which is somewhat contrary to the goal :)

[Mostyn Bramley-Moore, 2015-06-03 19:08:32]

On 2015/06/03 18:21:22, Ryan Sleevi wrote:
> Not LGTM.
> 
> This isn't needed for 3.19.1 (contrary to the description). The size checks
are
> in libssl when accepting certs, but neither of these tests are related to
this.

Without this patch I get the following crypto_unittests failures with NSS 3.19.1
(and subsequent crashes due to assuming key generation succeeded):

RSAPrivateKeyNSSTest.FailedFindFromPublicKey
RSAPrivateKeyNSSTest.FindFromPublicKey
RSAPrivateKeyUnitTest.CreateFromKeyTest

RSAPrivateKey::CreateWithParams's call to PK11_GenerateKeyPair fails, and the
caller up the stack in the problem tests don't check this.  

If I switch in NSS 3.19 dynamic libraries, the tests pass.

> We had issues with these tests timing out on bots because of the size and
other
> instrumentation. Raising this would end up causing these tests to be disabled,
> which is somewhat contrary to the goal :)

Would you like to use pre-generated keys instead, as agl suggested?  Otherwise I
suppose I could ifdef these out when building with NSS 3.19.1, but that feels
wrong.

[Ryan Sleevi, 2015-06-03 21:16:02]

On 2015/06/03 19:08:32, Mostyn Bramley-Moore wrote:
> On 2015/06/03 18:21:22, Ryan Sleevi wrote:
> > Not LGTM.
> > 
> > This isn't needed for 3.19.1 (contrary to the description). The size checks
> are
> > in libssl when accepting certs, but neither of these tests are related to
> this.
> 
> Without this patch I get the following crypto_unittests failures with NSS
3.19.1
> (and subsequent crashes due to assuming key generation succeeded):
> 
> RSAPrivateKeyNSSTest.FailedFindFromPublicKey
> RSAPrivateKeyNSSTest.FindFromPublicKey
> RSAPrivateKeyUnitTest.CreateFromKeyTest
> 
> RSAPrivateKey::CreateWithParams's call to PK11_GenerateKeyPair fails, and the
> caller up the stack in the problem tests don't check this.  
> 
> If I switch in NSS 3.19 dynamic libraries, the tests pass.

Blah. https://bugzilla.mozilla.org/show_bug.cgi?id=1138554#c84

Until we can require a new enough version of NSS that we can be ensured that
there isn't any cross-DB contamination, then Adam's suggested fix (hardcoding)
could have inter-test effects and run the risk of passing when it shouldn't.
Requiring a new enough version of NSS is gated on convincing the Chrome project
managers to discontinue support for Linux OS's that aren't receiving security
updates (e.g. most of the ones currently listed in our minimum platform
requirements), which will apparently require at least two versions and "someone"
to do a bunch of analysis as to what our users are running, which no one is
owning and I haven't had the time to do. Sorry :(

[Ryan Sleevi, 2015-06-03 22:43:00]

Since I don't have the time to get involved in the NSS political discussion, I
think just bumping these to 512 bits should resolve the issue w/ 3.19.1 and,
though it'll cause a perf hit for the bots, be better than the 1024 alternative.

[Mostyn Bramley-Moore, 2015-06-04 06:28:44]

On 2015/06/03 22:43:00, Ryan Sleevi wrote:
> Since I don't have the time to get involved in the NSS political discussion, I
> think just bumping these to 512 bits should resolve the issue w/ 3.19.1 and,
> though it'll cause a perf hit for the bots, be better than the 1024
alternative.

I should have tested the lower limit earlier- sorry about that.  Upgrading to
512 bit keys WFM (and 511 bits still fails), done in the second patch set.

[Ryan Sleevi, 2015-06-08 23:31:42]

lgtm

[Mostyn Bramley-Moore, 2015-06-09 06:34:09]

The CQ bit was checked by mostynb@opera.com

[commit-bot: I haz the power, 2015-06-09 06:34:24]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1148193006/20001

[commit-bot: I haz the power, 2015-06-09 06:47:25]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-09 06:47:26]

Try jobs failed on following builders:
  linux_chromium_clobber_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Mostyn Bramley-Moore, 2015-06-09 19:22:23]

The CQ bit was checked by mostynb@opera.com

[Mostyn Bramley-Moore, 2015-06-09 19:22:23]

The patchset sent to the CQ was uploaded after l-g-t-m from rsleevi@chromium.org
Link to the patchset: https://codereview.chromium.org/1148193006/#ps40001
(title: "rebase on master")

[commit-bot: I haz the power, 2015-06-09 19:22:48]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1148193006/40001

[commit-bot: I haz the power, 2015-06-09 19:36:23]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-06-09 19:37:16]

Patchset 3 (id:??) landed as
https://crrev.com/93937caf120fed43de182e475822805afdbe3001
Cr-Commit-Position: refs/heads/master@{#333554}