Skip to content
Snippets Groups Projects
Select Git revision
  • upstream/master
  • upstream/1.3
  • upstream/gh-pages
  • master default
  • upstream/thaidn-patch-1
  • upstream/1.2
  • upstream/merge_test
  • upstream/master_backup
  • v1.3.0-rc3
  • v1.3.0-rc2
  • v1.3.0-rc1
  • v1.2.2
  • v1.2.1
  • v1.2.0
  • v1.2.0-rc4
  • v1.2.0-rc3
  • v1.2.0-rc2
  • v1.1.1
  • v1.1.0
  • v1.0.0
20 results
Search by author
  • Any Author
  • banggua banggua banggua
1 author
  1. Jul 27, 2018
  3. Jul 20, 2018
  5. Jul 16, 2018
  7. Jul 14, 2018
  9. Jul 13, 2018
    • Thai Duong's avatar
      Note that C++ and Obj-C are also ready for production, also adding Haris and... · e76fa741
      Thai Duong authored 
      Note that C++ and Obj-C are also ready for production, also adding Haris and Charles to list of maintainers.

PiperOrigin-RevId: 204533189
GitOrigin-RevId: 9ae90e72ca30baa3e6efa9783ab8f3b7d14ec690
      v1.2.0-rc2
      e76fa741
    • Charles Lee's avatar
      Update version references to 1.2.0-rc2. · e68edc7b
      Charles Lee authored 
      Also, remove stale references to v1.1.0 in TinkConfig.register() documentation.

PiperOrigin-RevId: 204529434
GitOrigin-RevId: a99dbe6bb14b02c1411e7baa6ef017ec72d89baf
      e68edc7b
    • Thai Duong's avatar
      Fixing Wycheproof ECDH tests. There's no bug, the tests are incorrect. · d9d164a2
      Thai Duong authored 
      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
      d9d164a2
    • Bartosz Przydatek's avatar
      Fixing a merge error in BUILD-file. · c0f8be5c
      Bartosz Przydatek authored 
      PiperOrigin-RevId: 204478709
GitOrigin-RevId: 945a523d16fbe1b784174e2aedb488d7a89ba643
      c0f8be5c
    • Bartosz Przydatek's avatar
      Reducing size of libtink.so by removing dead code. · 3fc5742b
      Bartosz Przydatek authored 
      PiperOrigin-RevId: 204477406
GitOrigin-RevId: 46569424ee4847c93bd6f82c28611bc0b00a1834
      3fc5742b
    • Rafael Lerm's avatar
      Update boringssl version to the latest on the master-with-bazel branch. · 0c0f60f4
      Rafael Lerm authored 
      This is necessary to use some newer functions in the upcoming RsaSignBoringSsl class.

PiperOrigin-RevId: 204469656
GitOrigin-RevId: ad1183ca8adc93ce12d15e9eb655aeba5fa4b700
      0c0f60f4
    • Bartosz Przydatek's avatar
      Removing deprecated C++ Tink APIs. · 809f78fa
      Bartosz Przydatek authored 
      PiperOrigin-RevId: 204468964
GitOrigin-RevId: 0a4a28740dbdfd6b20872792de5adb78a2fbe676
      809f78fa
    • Haris Andrianakis's avatar
      objc: Upgrade protobuf, add ios_static_framework rule for Bazel, update docs. · e3521eaa
      Haris Andrianakis authored 
      PiperOrigin-RevId: 204394015
GitOrigin-RevId: d0fa0c36798ffbed7b3381909d88631ef1743318
      e3521eaa
    • Thai Duong's avatar
      Fixing typo. · 34b3c074
      Thai Duong authored 
      PiperOrigin-RevId: 204391980
GitOrigin-RevId: ba9666fbf61c6a39d68c6fa323fed282d2a5a60f
      34b3c074