kris/th5
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
a1363d2ed9
th5/testdata/Client-TLSv10-ECDHE-ECDSA-AES

65 lines
4.8 KiB
Plaintext
Raw Normal View History

crypto/tls: rework reference tests. The practice of storing reference connections for testing has worked reasonably well, but the large blocks of literal data in the .go files is ugly and updating the tests is a real problem because their number has grown. This CL changes the way that reference tests work. It's now possible to automatically update the tests and the test data is now stored in testdata/. This should make it easier to implement changes that affect all connections, like implementing the renegotiation extension. R=golang-codereviews, r CC=golang-codereviews https://golang.org/cl/42060044
2013-12-20 16:37:05 +00:00
>>> Flow 1 (client to server)
crypto/tls: support renegotiation extension. The renegotiation extension was introduced[1] due to an attack by Ray in which a client's handshake was spliced into a connection that was renegotiating, thus giving an attacker the ability to inject an arbitary prefix into the connection. Go has never supported renegotiation as a server and so this attack doesn't apply. As a client, it's possible that at some point in the future the population of servers will be sufficiently updated that it'll be possible to reject connections where the server hasn't demonstrated that it has been updated to address this problem. We're not at that point yet, but it's good for Go servers to support the extension so that it might be possible to do in the future. [1] https://tools.ietf.org/search/rfc5746 R=golang-codereviews, mikioh.mikioh CC=golang-codereviews https://golang.org/cl/48580043
2014-01-09 18:38:11 +00:00
00000000 16 03 01 00 75 01 00 00 71 03 03 00 00 00 00 00 |....u...q.......|
crypto/tls: rework reference tests. The practice of storing reference connections for testing has worked reasonably well, but the large blocks of literal data in the .go files is ugly and updating the tests is a real problem because their number has grown. This CL changes the way that reference tests work. It's now possible to automatically update the tests and the test data is now stored in testdata/. This should make it easier to implement changes that affect all connections, like implementing the renegotiation extension. R=golang-codereviews, r CC=golang-codereviews https://golang.org/cl/42060044
2013-12-20 16:37:05 +00:00
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 1a c0 2f |.............../|
00000030 c0 2b c0 11 c0 07 c0 13 c0 09 c0 14 c0 0a 00 05 |.+..............|
crypto/tls: support renegotiation extension. The renegotiation extension was introduced[1] due to an attack by Ray in which a client's handshake was spliced into a connection that was renegotiating, thus giving an attacker the ability to inject an arbitary prefix into the connection. Go has never supported renegotiation as a server and so this attack doesn't apply. As a client, it's possible that at some point in the future the population of servers will be sufficiently updated that it'll be possible to reject connections where the server hasn't demonstrated that it has been updated to address this problem. We're not at that point yet, but it's good for Go servers to support the extension so that it might be possible to do in the future. [1] https://tools.ietf.org/search/rfc5746 R=golang-codereviews, mikioh.mikioh CC=golang-codereviews https://golang.org/cl/48580043
2014-01-09 18:38:11 +00:00
00000040 00 2f 00 35 c0 12 00 0a 01 00 00 2e 00 05 00 05 |./.5............|
crypto/tls: rework reference tests. The practice of storing reference connections for testing has worked reasonably well, but the large blocks of literal data in the .go files is ugly and updating the tests is a real problem because their number has grown. This CL changes the way that reference tests work. It's now possible to automatically update the tests and the test data is now stored in testdata/. This should make it easier to implement changes that affect all connections, like implementing the renegotiation extension. R=golang-codereviews, r CC=golang-codereviews https://golang.org/cl/42060044
2013-12-20 16:37:05 +00:00
00000050 01 00 00 00 00 00 0a 00 08 00 06 00 17 00 18 00 |................|
00000060 19 00 0b 00 02 01 00 00 0d 00 0a 00 08 04 01 04 |................|
crypto/tls: support renegotiation extension. The renegotiation extension was introduced[1] due to an attack by Ray in which a client's handshake was spliced into a connection that was renegotiating, thus giving an attacker the ability to inject an arbitary prefix into the connection. Go has never supported renegotiation as a server and so this attack doesn't apply. As a client, it's possible that at some point in the future the population of servers will be sufficiently updated that it'll be possible to reject connections where the server hasn't demonstrated that it has been updated to address this problem. We're not at that point yet, but it's good for Go servers to support the extension so that it might be possible to do in the future. [1] https://tools.ietf.org/search/rfc5746 R=golang-codereviews, mikioh.mikioh CC=golang-codereviews https://golang.org/cl/48580043
2014-01-09 18:38:11 +00:00
00000070 03 02 01 02 03 ff 01 00 01 00 |..........|
crypto/tls: rework reference tests. The practice of storing reference connections for testing has worked reasonably well, but the large blocks of literal data in the .go files is ugly and updating the tests is a real problem because their number has grown. This CL changes the way that reference tests work. It's now possible to automatically update the tests and the test data is now stored in testdata/. This should make it easier to implement changes that affect all connections, like implementing the renegotiation extension. R=golang-codereviews, r CC=golang-codereviews https://golang.org/cl/42060044
2013-12-20 16:37:05 +00:00
>>> Flow 2 (server to client)
crypto/ecdsa: make Sign safe with broken entropy sources ECDSA is unsafe to use if an entropy source produces predictable output for the ephemeral nonces. E.g., [Nguyen]. A simple countermeasure is to hash the secret key, the message, and entropy together to seed a CSPRNG, from which the ephemeral key is derived. Fixes #9452 -- This is a minimalist (in terms of patch size) solution, though not the most parsimonious in its use of primitives: - csprng_key = ChopMD-256(SHA2-512(priv.D||entropy||hash)) - reader = AES-256-CTR(k=csprng_key) This, however, provides at most 128-bit collision-resistance, so that Adv will have a term related to the number of messages signed that is significantly worse than plain ECDSA. This does not seem to be of any practical importance. ChopMD-256(SHA2-512(x)) is used, rather than SHA2-256(x), for two sets of reasons: *Practical:* SHA2-512 has a larger state and 16 more rounds; it is likely non-generically stronger than SHA2-256. And, AFAIK, cryptanalysis backs this up. (E.g., [Biryukov] gives a distinguisher on 47-round SHA2-256 with cost < 2^85.) This is well below a reasonable security-strength target. *Theoretical:* [Coron] and [Chang] show that Chop-MD(F(x)) is indifferentiable from a random oracle for slightly beyond the birthday barrier. It seems likely that this makes a generic security proof that this construction remains UF-CMA is possible in the indifferentiability framework. -- Many thanks to Payman Mohassel for reviewing this construction; any mistakes are mine, however. And, as he notes, reusing the private key in this way means that the generic-group (non-RO) proof of ECDSA's security given in [Brown] no longer directly applies. -- [Brown]: http://www.cacr.math.uwaterloo.ca/techreports/2000/corr2000-54.ps "Brown. The exact security of ECDSA. 2000" [Coron]: https://www.cs.nyu.edu/~puniya/papers/merkle.pdf "Coron et al. Merkle-Damgard revisited. 2005" [Chang]: https://www.iacr.org/archive/fse2008/50860436/50860436.pdf "Chang and Nandi. Improved indifferentiability security analysis of chopMD hash function. 2008" [Biryukov]: http://www.iacr.org/archive/asiacrypt2011/70730269/70730269.pdf "Biryukov et al. Second-order differential collisions for reduced SHA-256. 2011" [Nguyen]: ftp://ftp.di.ens.fr/pub/users/pnguyen/PubECDSA.ps "Nguyen and Shparlinski. The insecurity of the elliptic curve digital signature algorithm with partially known nonces. 2003" New tests: TestNonceSafety: Check that signatures are safe even with a broken entropy source. TestINDCCA: Check that signatures remain non-deterministic with a functional entropy source. Updated "golden" KATs in crypto/tls/testdata that use ECDSA suites. Change-Id: I55337a2fbec2e42a36ce719bd2184793682d678a Reviewed-on: https://go-review.googlesource.com/3340 Reviewed-by: Adam Langley <agl@golang.org>
2015-01-27 07:00:21 +00:00
00000000 16 03 01 00 51 02 00 00 4d 03 01 54 c7 34 52 b0 |....Q...M..T.4R.|
00000010 47 c3 7d 3d 1f 16 7f 5c 8c 6e 05 0a d5 85 19 2a |G.}=...\.n.....*|
00000020 9a d3 1e 8f dc ed 92 53 fd dd 40 20 af 90 44 e7 |.......S..@ ..D.|
00000030 2d 28 15 7e 45 50 0c b6 a6 15 a7 cf 99 19 85 a8 |-(.~EP..........|
00000040 1b df 61 c1 d5 7e 51 e6 80 d4 75 66 c0 09 00 00 |..a..~Q...uf....|
00000050 05 ff 01 00 01 00 16 03 01 02 0e 0b 00 02 0a 00 |................|
00000060 02 07 00 02 04 30 82 02 00 30 82 01 62 02 09 00 |.....0...0..b...|
00000070 b8 bf 2d 47 a0 d2 eb f4 30 09 06 07 2a 86 48 ce |..-G....0...*.H.|
00000080 3d 04 01 30 45 31 0b 30 09 06 03 55 04 06 13 02 |=..0E1.0...U....|
00000090 41 55 31 13 30 11 06 03 55 04 08 13 0a 53 6f 6d |AU1.0...U....Som|
000000a0 65 2d 53 74 61 74 65 31 21 30 1f 06 03 55 04 0a |e-State1!0...U..|
000000b0 13 18 49 6e 74 65 72 6e 65 74 20 57 69 64 67 69 |..Internet Widgi|
000000c0 74 73 20 50 74 79 20 4c 74 64 30 1e 17 0d 31 32 |ts Pty Ltd0...12|
000000d0 31 31 32 32 31 35 30 36 33 32 5a 17 0d 32 32 31 |1122150632Z..221|
000000e0 31 32 30 31 35 30 36 33 32 5a 30 45 31 0b 30 09 |120150632Z0E1.0.|
000000f0 06 03 55 04 06 13 02 41 55 31 13 30 11 06 03 55 |..U....AU1.0...U|
00000100 04 08 13 0a 53 6f 6d 65 2d 53 74 61 74 65 31 21 |....Some-State1!|
00000110 30 1f 06 03 55 04 0a 13 18 49 6e 74 65 72 6e 65 |0...U....Interne|
00000120 74 20 57 69 64 67 69 74 73 20 50 74 79 20 4c 74 |t Widgits Pty Lt|
00000130 64 30 81 9b 30 10 06 07 2a 86 48 ce 3d 02 01 06 |d0..0...*.H.=...|
00000140 05 2b 81 04 00 23 03 81 86 00 04 00 c4 a1 ed be |.+...#..........|
00000150 98 f9 0b 48 73 36 7e c3 16 56 11 22 f2 3d 53 c3 |...Hs6~..V.".=S.|
00000160 3b 4d 21 3d cd 6b 75 e6 f6 b0 dc 9a df 26 c1 bc |;M!=.ku......&..|
00000170 b2 87 f0 72 32 7c b3 64 2f 1c 90 bc ea 68 23 10 |...r2|.d/....h#.|
00000180 7e fe e3 25 c0 48 3a 69 e0 28 6d d3 37 00 ef 04 |~..%.H:i.(m.7...|
00000190 62 dd 0d a0 9c 70 62 83 d8 81 d3 64 31 aa 9e 97 |b....pb....d1...|
000001a0 31 bd 96 b0 68 c0 9b 23 de 76 64 3f 1a 5c 7f e9 |1...h..#.vd?.\..|
000001b0 12 0e 58 58 b6 5f 70 dd 9b d8 ea d5 d7 f5 d5 cc |..XX._p.........|
000001c0 b9 b6 9f 30 66 5b 66 9a 20 e2 27 e5 bf fe 3b 30 |...0f[f. .'...;0|
000001d0 09 06 07 2a 86 48 ce 3d 04 01 03 81 8c 00 30 81 |...*.H.=......0.|
000001e0 88 02 42 01 88 a2 4f eb e2 45 c5 48 7d 1b ac f5 |..B...O..E.H}...|
000001f0 ed 98 9d ae 47 70 c0 5e 1b b6 2f bd f1 b6 4d b7 |....Gp.^../...M.|
00000200 61 40 d3 11 a2 ce ee 0b 7e 92 7e ff 76 9d c3 3b |a@......~.~.v..;|
00000210 7e a5 3f ce fa 10 e2 59 ec 47 2d 7c ac da 4e 97 |~.?....Y.G-|..N.|
00000220 0e 15 a0 6f d0 02 42 01 4d fc be 67 13 9c 2d 05 |...o..B.M..g..-.|
00000230 0e bd 3f a3 8c 25 c1 33 13 83 0d 94 06 bb d4 37 |..?..%.3.......7|
00000240 7a f6 ec 7a c9 86 2e dd d7 11 69 7f 85 7c 56 de |z..z......i..|V.|
00000250 fb 31 78 2b e4 c7 78 0d ae cb be 9e 4e 36 24 31 |.1x+..x.....N6$1|
00000260 7b 6a 0f 39 95 12 07 8f 2a 16 03 01 00 c0 0c 00 |{j.9....*.......|
00000270 00 bc 03 00 03 2b 04 02 35 e1 56 0b 72 c9 4b e8 |.....+..5.V.r.K.|
00000280 69 29 75 1d ff a3 f4 06 73 72 f2 e2 07 2e 9e 66 |i)u.....sr.....f|
00000290 73 7b 7f 62 b1 ed 0d 84 2b d7 d7 32 22 25 92 4c |s{.b....+..2"%.L|
000002a0 d9 00 8b 30 81 88 02 42 01 23 24 db 0a d5 ab e5 |...0...B.#$.....|
000002b0 a7 11 31 ce fb 36 89 54 8c d1 65 14 bc a2 5c 42 |..1..6.T..e...\B|
000002c0 08 c9 a2 6f 24 b2 f2 aa bc 02 5c 44 98 2d 95 91 |...o$.....\D.-..|
000002d0 98 22 69 fc c3 52 c5 60 ca f2 9c 67 ce 96 2b bf |."i..R.`...g..+.|
000002e0 66 73 d5 ac 96 bf 0f 92 6d 1d 02 42 00 a6 7d 0d |fs......m..B..}.|
000002f0 c9 78 f6 35 7b 19 9c 25 82 48 52 9c 11 b7 06 5b |.x.5{..%.HR....[|
00000300 f8 a7 30 cd ee bf 37 af 23 f2 06 23 d9 77 da 76 |..0...7.#..#.w.v|
00000310 12 2a da f9 34 1f f0 4f f9 94 2e 4d e6 c4 eb bb |.*..4..O...M....|
00000320 b2 55 23 70 ae 55 de a5 68 bd a6 a4 d7 c4 16 03 |.U#p.U..h.......|
00000330 01 00 04 0e 00 00 00 |.......|
crypto/tls: rework reference tests. The practice of storing reference connections for testing has worked reasonably well, but the large blocks of literal data in the .go files is ugly and updating the tests is a real problem because their number has grown. This CL changes the way that reference tests work. It's now possible to automatically update the tests and the test data is now stored in testdata/. This should make it easier to implement changes that affect all connections, like implementing the renegotiation extension. R=golang-codereviews, r CC=golang-codereviews https://golang.org/cl/42060044
2013-12-20 16:37:05 +00:00
>>> Flow 3 (client to server)
crypto/ecdsa: make Sign safe with broken entropy sources ECDSA is unsafe to use if an entropy source produces predictable output for the ephemeral nonces. E.g., [Nguyen]. A simple countermeasure is to hash the secret key, the message, and entropy together to seed a CSPRNG, from which the ephemeral key is derived. Fixes #9452 -- This is a minimalist (in terms of patch size) solution, though not the most parsimonious in its use of primitives: - csprng_key = ChopMD-256(SHA2-512(priv.D||entropy||hash)) - reader = AES-256-CTR(k=csprng_key) This, however, provides at most 128-bit collision-resistance, so that Adv will have a term related to the number of messages signed that is significantly worse than plain ECDSA. This does not seem to be of any practical importance. ChopMD-256(SHA2-512(x)) is used, rather than SHA2-256(x), for two sets of reasons: *Practical:* SHA2-512 has a larger state and 16 more rounds; it is likely non-generically stronger than SHA2-256. And, AFAIK, cryptanalysis backs this up. (E.g., [Biryukov] gives a distinguisher on 47-round SHA2-256 with cost < 2^85.) This is well below a reasonable security-strength target. *Theoretical:* [Coron] and [Chang] show that Chop-MD(F(x)) is indifferentiable from a random oracle for slightly beyond the birthday barrier. It seems likely that this makes a generic security proof that this construction remains UF-CMA is possible in the indifferentiability framework. -- Many thanks to Payman Mohassel for reviewing this construction; any mistakes are mine, however. And, as he notes, reusing the private key in this way means that the generic-group (non-RO) proof of ECDSA's security given in [Brown] no longer directly applies. -- [Brown]: http://www.cacr.math.uwaterloo.ca/techreports/2000/corr2000-54.ps "Brown. The exact security of ECDSA. 2000" [Coron]: https://www.cs.nyu.edu/~puniya/papers/merkle.pdf "Coron et al. Merkle-Damgard revisited. 2005" [Chang]: https://www.iacr.org/archive/fse2008/50860436/50860436.pdf "Chang and Nandi. Improved indifferentiability security analysis of chopMD hash function. 2008" [Biryukov]: http://www.iacr.org/archive/asiacrypt2011/70730269/70730269.pdf "Biryukov et al. Second-order differential collisions for reduced SHA-256. 2011" [Nguyen]: ftp://ftp.di.ens.fr/pub/users/pnguyen/PubECDSA.ps "Nguyen and Shparlinski. The insecurity of the elliptic curve digital signature algorithm with partially known nonces. 2003" New tests: TestNonceSafety: Check that signatures are safe even with a broken entropy source. TestINDCCA: Check that signatures remain non-deterministic with a functional entropy source. Updated "golden" KATs in crypto/tls/testdata that use ECDSA suites. Change-Id: I55337a2fbec2e42a36ce719bd2184793682d678a Reviewed-on: https://go-review.googlesource.com/3340 Reviewed-by: Adam Langley <agl@golang.org>
2015-01-27 07:00:21 +00:00
00000000 15 03 01 00 02 02 0a |.......|
Reference in New Issue Copy Permalink