Align OpenSSL and NSS ChannelID formats.

Align OpenSSL and NSS ChannelID formats.

NSS would use "" as the password while OpenSSL would use "\0\0" (UCS-2 encoding
of a NUL-terminated string) because of how PKCS#12 recommended encoding
passwords. Make the OpenSSL code use the same format so that we can freely switch
back and forth between NSS and OpenSSL.

(This is in case we need to roll back an OpenSSL cutover and the release has
hit some early release channel already.)

BUG=399121
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=287890

[davidben, 2014-08-04 17:25:21]

https://codereview.chromium.org/435593003/diff/20001/crypto/ec_private_key_un...
File crypto/ec_private_key_unittest.cc (right):

https://codereview.chromium.org/435593003/diff/20001/crypto/ec_private_key_un...
crypto/ec_private_key_unittest.cc:194: 0x49, 0xf6, 0x7e, 0xd0, 0x42, 0xaa, 0x14,
0x3c, 0x24, 0x77, 0xb4};
I believe this is slightly larger than the NSS ones because OpenSSL defaults to
a salt length.

https://codereview.chromium.org/435593003/diff/20001/crypto/ec_private_key_un...
crypto/ec_private_key_unittest.cc:220: static const unsigned char openssl_key[]
= {
The /huge/ difference in size between this and the one I newly generated is
confusing, perhaps something funny happened in dumping these out? Perhaps they
contain the data as a prefix or something? In any case, I've just left it as-is.
The new ones are more consistent when the NSS size.

[Ryan Sleevi, 2014-08-06 02:24:48]

https://codereview.chromium.org/435593003/diff/20001/crypto/ec_private_key_op...
File crypto/ec_private_key_openssl.cc (right):

https://codereview.chromium.org/435593003/diff/20001/crypto/ec_private_key_op...
crypto/ec_private_key_openssl.cc:176: #endif
I'm not sure I understand this bit. That is, why do you need to preserve
encrypting them like this? We're not going back on BoringSSL on Android (we've
crossed that rubicon, have we not?)

https://codereview.chromium.org/435593003/diff/20001/crypto/ec_private_key_op...
crypto/ec_private_key_openssl.cc:178: NID_pbe_WithSHA1And3_Key_TripleDES_CBC,
Document why this constant is what it is.

https://codereview.chromium.org/435593003/diff/20001/crypto/ec_private_key_un...
File crypto/ec_private_key_unittest.cc (right):

https://codereview.chromium.org/435593003/diff/20001/crypto/ec_private_key_un...
crypto/ec_private_key_unittest.cc:194: 0x49, 0xf6, 0x7e, 0xd0, 0x42, 0xaa, 0x14,
0x3c, 0x24, 0x77, 0xb4};
On 2014/08/04 17:25:21, David Benjamin wrote:
> I believe this is slightly larger than the NSS ones because OpenSSL defaults
to
> a salt length.

Not sure I understand?

https://codereview.chromium.org/435593003/diff/20001/crypto/ec_private_key_un...
crypto/ec_private_key_unittest.cc:220: static const unsigned char openssl_key[]
= {
On 2014/08/04 17:25:21, David Benjamin wrote:
> The /huge/ difference in size between this and the one I newly generated is
> confusing, perhaps something funny happened in dumping these out? Perhaps they
> contain the data as a prefix or something? In any case, I've just left it
as-is.
> The new ones are more consistent when the NSS size.

What's the ASN.1 dump say?

[davidben, 2014-08-06 18:34:36]

https://codereview.chromium.org/435593003/diff/20001/crypto/ec_private_key_op...
File crypto/ec_private_key_openssl.cc (right):

https://codereview.chromium.org/435593003/diff/20001/crypto/ec_private_key_op...
crypto/ec_private_key_openssl.cc:176: #endif
On 2014/08/06 02:24:48, Ryan Sleevi wrote:
> I'm not sure I understand this bit. That is, why do you need to preserve
> encrypting them like this? We're not going back on BoringSSL on Android (we've
> crossed that rubicon, have we not?)

It was more about jumping back and forth across
https://codereview.chromium.org/205333002. But it looks like that's even in
stable, and we generally don't let you downgrade profiles anyway, so it probably
doesn't matter. I've removed it.

https://codereview.chromium.org/435593003/diff/20001/crypto/ec_private_key_op...
crypto/ec_private_key_openssl.cc:178: NID_pbe_WithSHA1And3_Key_TripleDES_CBC,
On 2014/08/06 02:24:48, Ryan Sleevi wrote:
> Document why this constant is what it is.

Isn't it documented up in "Encrypt the object"?

https://codereview.chromium.org/435593003/diff/20001/crypto/ec_private_key_un...
File crypto/ec_private_key_unittest.cc (right):

https://codereview.chromium.org/435593003/diff/20001/crypto/ec_private_key_un...
crypto/ec_private_key_unittest.cc:194: 0x49, 0xf6, 0x7e, 0xd0, 0x42, 0xaa, 0x14,
0x3c, 0x24, 0x77, 0xb4};
On 2014/08/06 02:24:48, Ryan Sleevi wrote:
> On 2014/08/04 17:25:21, David Benjamin wrote:
> > I believe this is slightly larger than the NSS ones because OpenSSL defaults
> to
> > a salt length.
> 
> Not sure I understand?

openssl_key is 4 bytes longer than nss_key. Was making a note as to why.

https://codereview.chromium.org/435593003/diff/20001/crypto/ec_private_key_un...
crypto/ec_private_key_unittest.cc:220: static const unsigned char openssl_key[]
= {
On 2014/08/06 02:24:48, Ryan Sleevi wrote:
> On 2014/08/04 17:25:21, David Benjamin wrote:
> > The /huge/ difference in size between this and the one I newly generated is
> > confusing, perhaps something funny happened in dumping these out? Perhaps
they
> > contain the data as a prefix or something? In any case, I've just left it
> as-is.
> > The new ones are more consistent when the NSS size.
> 
> What's the ASN.1 dump say?

Interesting. It's actually full-length. The difference appears to be that this
one writes out the curve parameters in full.

$ openssl pkcs8 -in openssl.old.der -inform der -passin 'pass:' | openssl
asn1parse
    0:d=0  hl=4 l= 377 cons: SEQUENCE          
    4:d=1  hl=2 l=   1 prim: INTEGER           :00
    7:d=1  hl=4 l= 259 cons: SEQUENCE          
   11:d=2  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
   20:d=2  hl=3 l= 247 cons: SEQUENCE          
   23:d=3  hl=2 l=   1 prim: INTEGER           :01
   26:d=3  hl=2 l=  44 cons: SEQUENCE          
   28:d=4  hl=2 l=   7 prim: OBJECT            :prime-field
   37:d=4  hl=2 l=  33 prim: INTEGER          
:FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFF
   72:d=3  hl=2 l=  91 cons: SEQUENCE          
   74:d=4  hl=2 l=  32 prim: OCTET STRING      [HEX
DUMP]:FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFC
  108:d=4  hl=2 l=  32 prim: OCTET STRING      [HEX
DUMP]:5AC635D8AA3A93E7B3EBBD55769886BC651D06B0CC53B0F63BCE3C3E27D2604B
  142:d=4  hl=2 l=  21 prim: BIT STRING        
  165:d=3  hl=2 l=  65 prim: OCTET STRING      [HEX
DUMP]:046B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C2964FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5
  232:d=3  hl=2 l=  33 prim: INTEGER          
:FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551
  267:d=3  hl=2 l=   1 prim: INTEGER           :01
  270:d=1  hl=2 l= 109 prim: OCTET STRING      [HEX
DUMP]:306B02010104204309C0677521479DA8FA16DF15736134686FE38E479195AB794A7214CBE2494FA14403420004DE090807032E8F379AD5ADE5C69DD463C74AE720CB90A01F181872B5218838C0DBBAF699D8A53B83E9E3D561997342C66CE80A9540413B0D10A74A93DB5AE7EC

(Note: this won't work on any of the other keys. As far as I can tell, you can't
actually tell openssl pkcs8 to decrypt one of the PKCS#12 CBE methods without it
first doing an ascii_to_ucs2 + trailing NUL on the password. And so it can't use
the empty byte string.)

[Ryan Sleevi, 2014-08-06 21:02:20]

lgtm

https://codereview.chromium.org/435593003/diff/20001/crypto/ec_private_key_op...
File crypto/ec_private_key_openssl.cc (right):

https://codereview.chromium.org/435593003/diff/20001/crypto/ec_private_key_op...
crypto/ec_private_key_openssl.cc:178: NID_pbe_WithSHA1And3_Key_TripleDES_CBC,
On 2014/08/06 18:34:35, David Benjamin wrote:
> On 2014/08/06 02:24:48, Ryan Sleevi wrote:
> > Document why this constant is what it is.
> 
> Isn't it documented up in "Encrypt the object"?

Oh, I'm blind because of the ifdef. Ignore :)

[davidben, 2014-08-06 21:35:57]

The CQ bit was checked by davidben@chromium.org

[commit-bot: I haz the power, 2014-08-06 21:38:15]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/davidben@chromium.org/435593003/40001

[commit-bot: I haz the power, 2014-08-06 23:11:22]

Change committed as 287890