Fixing Wycheproof ECDH tests. There's no bug, the tests are incorrect.

First, background and history:

In Java, an ECDH public key can be encoded as a SubjectPublicKeyInfo spec [1]. This spec contains the public point, and a named curve or curve parameters [2]. To test ECDH libraries, Wycheproof generates public key specs with modified curve parameters, and checks that the libraries must reject them [3].

Android M and N (and possibly other versions) do not reject said public keys specs. Given a spec Android just takes the field ID, and derives the rest of the parameters. This leads to a somewhat interesting situation: not only Android accepts Wycheproof's modified public key specs, but it also computes the shared secrets correctly and securely. So we changed Wycheproof to accept Android's behavior, and added to each test case the expected shared secret, had the public key spec not been modified.

What went wrong:

The expected shared secrets for "modified prime" and "public key of order 3" test are incorrect. I found that the public key specs (the "public" field in the ecdh_test.json) don't contain the same public point as in other tests. I'm not sure this is intentional, but because the public point is different the expected shared secret must be different too.

Let's look at test case #336. Its expected shared secret is the same as test case #335. Yet two test cases contain two different public points, as shown below (
the public point is the last BIT STRING, it starts with 04):

# Test case 335

  0 304: SEQUENCE {
  4 233:   SEQUENCE {
  7   7:     OBJECT IDENTIFIER '1 2 840 10045 2 1'
 16 221:     SEQUENCE {
 19   1:       INTEGER 1
 22  44:       SEQUENCE {
 24   7:         OBJECT IDENTIFIER '1 2 840 10045 1 1'
 33  33:         INTEGER
       :           00 FF FF FF FF 00 00 00 01 00 00 00 00 00 00 00
       :           00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF
       :           FF
       :         }
 68  68:       SEQUENCE {
 70  32:         OCTET STRING
       :           FF FF FF FF 00 00 00 01 00 00 00 00 00 00 00 00
       :           00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FC
104  32:         OCTET STRING
       :           5A C6 35 D8 AA 3A 93 E7 B3 EB BD 55 76 98 86 BC
       :           65 1D 06 B0 CC 53 B0 F6 3B CE 3C 3E 27 D2 60 4B
       :         }
138  65:       OCTET STRING
       :         04 6B 17 D1 F2 E1 2C 42 47 F8 BC E6 E5 63 A4 40
       :         F2 77 03 7D 81 2D EB 33 A0 F4 A1 39 45 D8 98 C2
       :         96 4F E3 42 E2 FE 1A 7F 9B 8E E7 EB 4A 7C 0F 9E
       :         16 2B CE 33 57 6B 31 5E CE CB B6 40 68 37 BF 51
       :         F5
205  33:       INTEGER
       :         00 FF FF FF FF 00 00 00 00 FF FF FF FF FF FF FF
       :         FF BC E6 FA AD A7 17 9E 84 F3 B9 CA C2 FC 63 25
       :         51
       :       }
       :     }
240  66:   BIT STRING
       :     04 15 10 26 4C 18 9C 3D 52 3F F9 91 6A BD 70 69
       :     EF A6 96 8D 8D C7 DD B6 45 7D 78 69 B5 3E A6 0C
       :     DC FA FB 7E D4 78 6D A1 5D 29 EE 59 25 6F 53 6D
       :     A3 57 5A 48 88 C1 BB 0A 95 B2 56 F4 A7 E9 FD 76
       :     4A
       :   }

# Test case 336:

  0 307: SEQUENCE {
  4 236:   SEQUENCE {
  7   7:     OBJECT IDENTIFIER '1 2 840 10045 2 1'
 16 224:     SEQUENCE {
 19   1:       INTEGER 1
 22  44:       SEQUENCE {
 24   7:         OBJECT IDENTIFIER '1 2 840 10045 1 1'
 33  33:         INTEGER
       :           00 FD 09 10 59 A6 89 36 35 F9 00 E9 44 9D 63 F5
       :           72 B2 AE BC 4C FF 7B 4E 5E 33 F1 B2 00 E8 BB C1
       :           45
       :         }
 68  68:       SEQUENCE {
 70  32:         OCTET STRING
       :           02 F6 EF A5 59 76 C9 CB 06 FF 16 BB 62 9C 0A 8D
       :           4D 51 43 B4 00 84 B1 A1 CC 0E 4D FF 17 44 3E B7
104  32:         OCTET STRING
       :           5A C6 35 D8 AA 3A 93 E7 B3 EB BD 55 76 98 86 BC
       :           65 1D 06 B0 CC 53 B0 F6 3B CE 3C 3E 27 D2 60 4B
       :         }
138  65:       OCTET STRING
       :         04 00 00 00 00 00 00 00 00 00 00 06 59 7F A9 4B
       :         1F D9 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       :         02 1B 8C 7D D7 7F 9A 95 62 79 22 EC EE FE A7 3F
       :         02 8F 1E C9 5B A9 B8 FA 95 A3 AD 24 BD F9 FF F4
       :         14
205  33:       INTEGER
       :         00 FF FF FF FF 00 00 00 00 FF FF FF FF FF FF FF
       :         FF BC E6 FA AD A7 17 9E 84 F3 B9 CA C2 FC 63 25
       :         51
240   1:       INTEGER 1
       :       }
       :     }
243  66:   BIT STRING
       :     04 00 00 00 00 00 00 00 00 00 00 06 59 7F A9 4B
       :     1F D9 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       :     02 1B 8C 7D D7 7F 9A 95 62 79 22 EC EE FE A7 3F
       :     02 8F 1E C9 5B A9 B8 FA 95 A3 AD 24 BD F9 FF F4
       :     14
       :   }

[1] https://tools.ietf.org/html/rfc5280#section-4.1.2.7.
[2] https://tools.ietf.org/html/rfc3279#section-2.3.5
[3] Many libraries don't, and usually that leads to vulnerabilities that leak the private key.

PiperOrigin-RevId: 204515375
GitOrigin-RevId: 6a5a122b80d9664fa19f5497a2a5260f02c7ee5a