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

130 lines
9.7 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 59 02 00 00 55 03 01 8e e5 cd c8 24 |....Y...U......$|
00000010 aa 56 53 50 51 e2 d3 6f 6d 8a 03 11 e8 f1 ff f5 |.VSPQ..om.......|
00000020 7c f4 30 9c fb 39 cb c5 18 79 cf 20 04 38 5d d9 ||.0..9...y. .8].|
00000030 d4 68 64 85 e7 5a 6d bb 0c de 1e 42 e0 78 57 67 |.hd..Zm....B.xWg|
00000040 9c 75 3c 47 42 1f a7 06 24 8f 18 11 c0 09 00 00 |.u<GB...$.......|
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
00000050 0d ff 01 00 01 00 00 0b 00 04 03 00 01 02 16 03 |................|
00000060 01 02 0e 0b 00 02 0a 00 02 07 00 02 04 30 82 02 |.............0..|
00000070 00 30 82 01 62 02 09 00 b8 bf 2d 47 a0 d2 eb f4 |.0..b.....-G....|
00000080 30 09 06 07 2a 86 48 ce 3d 04 01 30 45 31 0b 30 |0...*.H.=..0E1.0|
00000090 09 06 03 55 04 06 13 02 41 55 31 13 30 11 06 03 |...U....AU1.0...|
000000a0 55 04 08 13 0a 53 6f 6d 65 2d 53 74 61 74 65 31 |U....Some-State1|
000000b0 21 30 1f 06 03 55 04 0a 13 18 49 6e 74 65 72 6e |!0...U....Intern|
000000c0 65 74 20 57 69 64 67 69 74 73 20 50 74 79 20 4c |et Widgits Pty L|
000000d0 74 64 30 1e 17 0d 31 32 31 31 32 32 31 35 30 36 |td0...1211221506|
000000e0 33 32 5a 17 0d 32 32 31 31 32 30 31 35 30 36 33 |32Z..22112015063|
000000f0 32 5a 30 45 31 0b 30 09 06 03 55 04 06 13 02 41 |2Z0E1.0...U....A|
00000100 55 31 13 30 11 06 03 55 04 08 13 0a 53 6f 6d 65 |U1.0...U....Some|
00000110 2d 53 74 61 74 65 31 21 30 1f 06 03 55 04 0a 13 |-State1!0...U...|
00000120 18 49 6e 74 65 72 6e 65 74 20 57 69 64 67 69 74 |.Internet Widgit|
00000130 73 20 50 74 79 20 4c 74 64 30 81 9b 30 10 06 07 |s Pty Ltd0..0...|
00000140 2a 86 48 ce 3d 02 01 06 05 2b 81 04 00 23 03 81 |*.H.=....+...#..|
00000150 86 00 04 00 c4 a1 ed be 98 f9 0b 48 73 36 7e c3 |...........Hs6~.|
00000160 16 56 11 22 f2 3d 53 c3 3b 4d 21 3d cd 6b 75 e6 |.V.".=S.;M!=.ku.|
00000170 f6 b0 dc 9a df 26 c1 bc b2 87 f0 72 32 7c b3 64 |.....&.....r2|.d|
00000180 2f 1c 90 bc ea 68 23 10 7e fe e3 25 c0 48 3a 69 |/....h#.~..%.H:i|
00000190 e0 28 6d d3 37 00 ef 04 62 dd 0d a0 9c 70 62 83 |.(m.7...b....pb.|
000001a0 d8 81 d3 64 31 aa 9e 97 31 bd 96 b0 68 c0 9b 23 |...d1...1...h..#|
000001b0 de 76 64 3f 1a 5c 7f e9 12 0e 58 58 b6 5f 70 dd |.vd?.\....XX._p.|
000001c0 9b d8 ea d5 d7 f5 d5 cc b9 b6 9f 30 66 5b 66 9a |...........0f[f.|
000001d0 20 e2 27 e5 bf fe 3b 30 09 06 07 2a 86 48 ce 3d | .'...;0...*.H.=|
000001e0 04 01 03 81 8c 00 30 81 88 02 42 01 88 a2 4f eb |......0...B...O.|
000001f0 e2 45 c5 48 7d 1b ac f5 ed 98 9d ae 47 70 c0 5e |.E.H}.......Gp.^|
00000200 1b b6 2f bd f1 b6 4d b7 61 40 d3 11 a2 ce ee 0b |../...M.a@......|
00000210 7e 92 7e ff 76 9d c3 3b 7e a5 3f ce fa 10 e2 59 |~.~.v..;~.?....Y|
00000220 ec 47 2d 7c ac da 4e 97 0e 15 a0 6f d0 02 42 01 |.G-|..N....o..B.|
00000230 4d fc be 67 13 9c 2d 05 0e bd 3f a3 8c 25 c1 33 |M..g..-...?..%.3|
00000240 13 83 0d 94 06 bb d4 37 7a f6 ec 7a c9 86 2e dd |.......7z..z....|
00000250 d7 11 69 7f 85 7c 56 de fb 31 78 2b e4 c7 78 0d |..i..|V..1x+..x.|
00000260 ae cb be 9e 4e 36 24 31 7b 6a 0f 39 95 12 07 8f |....N6$1{j.9....|
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
00000270 2a 16 03 01 00 d6 0c 00 00 d2 03 00 17 41 04 9e |*............A..|
00000280 7c 82 c3 eb d9 2f 1a 2c 35 32 70 b3 64 7f dd 16 ||..../.,52p.d...|
00000290 0d 28 91 0b b0 b0 30 a8 c7 4c 4f 10 b3 42 84 a4 |.(....0..LO..B..|
000002a0 b7 a1 f6 38 e6 63 47 95 1a 0a 3e f0 96 4a 10 10 |...8.cG...>..J..|
000002b0 45 fd 66 27 e5 ef 0b 44 d8 da 20 61 47 e3 b8 00 |E.f'...D.. aG...|
000002c0 8b 30 81 88 02 42 01 b9 39 36 f9 73 6d 2c f1 1f |.0...B..96.sm,..|
000002d0 5f 8d 1d 49 d4 8c f9 19 7c 18 f8 ed 41 77 01 40 |_..I....|...Aw.@|
000002e0 30 27 a0 64 a8 c9 08 fb 09 69 eb 13 24 1f cf af |0'.d.....i..$...|
000002f0 d2 32 c6 ae 76 52 ac 96 31 4b 63 2c 56 55 af f8 |.2..vR..1Kc,VU..|
00000300 c6 cc 56 07 f5 8b fa 82 02 42 01 9e a8 fd 78 34 |..V......B....x4|
00000310 f3 d1 53 8c e2 19 37 df 05 8e b7 46 84 ee 66 cc |..S...7....F..f.|
00000320 48 d9 8e 22 c0 70 bf 98 3a 40 37 82 a2 bb df 75 |H..".p..:@7....u|
00000330 84 4b dc 31 e9 57 70 98 7f 50 81 9b 75 55 9c f6 |.K.1.Wp..P..uU..|
00000340 9f ad 69 e6 2b 05 6a 0d 48 7b 99 83 16 03 01 00 |..i.+.j.H{......|
00000350 0e 0d 00 00 06 03 01 02 40 00 00 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)
00000000 16 03 01 02 0a 0b 00 02 06 00 02 03 00 02 00 30 |...............0|
00000010 82 01 fc 30 82 01 5e 02 09 00 9a 30 84 6c 26 35 |...0..^....0.l&5|
00000020 d9 17 30 09 06 07 2a 86 48 ce 3d 04 01 30 45 31 |..0...*.H.=..0E1|
00000030 0b 30 09 06 03 55 04 06 13 02 41 55 31 13 30 11 |.0...U....AU1.0.|
00000040 06 03 55 04 08 13 0a 53 6f 6d 65 2d 53 74 61 74 |..U....Some-Stat|
00000050 65 31 21 30 1f 06 03 55 04 0a 13 18 49 6e 74 65 |e1!0...U....Inte|
00000060 72 6e 65 74 20 57 69 64 67 69 74 73 20 50 74 79 |rnet Widgits Pty|
00000070 20 4c 74 64 30 1e 17 0d 31 32 31 31 31 34 31 33 | Ltd0...12111413|
00000080 32 35 35 33 5a 17 0d 32 32 31 31 31 32 31 33 32 |2553Z..221112132|
00000090 35 35 33 5a 30 41 31 0b 30 09 06 03 55 04 06 13 |553Z0A1.0...U...|
000000a0 02 41 55 31 0c 30 0a 06 03 55 04 08 13 03 4e 53 |.AU1.0...U....NS|
000000b0 57 31 10 30 0e 06 03 55 04 07 13 07 50 79 72 6d |W1.0...U....Pyrm|
000000c0 6f 6e 74 31 12 30 10 06 03 55 04 03 13 09 4a 6f |ont1.0...U....Jo|
000000d0 65 6c 20 53 69 6e 67 30 81 9b 30 10 06 07 2a 86 |el Sing0..0...*.|
000000e0 48 ce 3d 02 01 06 05 2b 81 04 00 23 03 81 86 00 |H.=....+...#....|
000000f0 04 00 95 8c 91 75 14 c0 5e c4 57 b4 d4 c3 6f 8d |.....u..^.W...o.|
00000100 ae 68 1e dd 6f ce 86 e1 7e 6e b2 48 3e 81 e5 4e |.h..o...~n.H>..N|
00000110 e2 c6 88 4b 64 dc f5 30 bb d3 ff 65 cc 5b f4 dd |...Kd..0...e.[..|
00000120 b5 6a 3e 3e d0 1d de 47 c3 76 ad 19 f6 45 2c 8c |.j>>...G.v...E,.|
00000130 bc d8 1d 01 4c 1f 70 90 46 76 48 8b 8f 83 cc 4a |....L.p.FvH....J|
00000140 5c 8f 40 76 da e0 89 ec 1d 2b c4 4e 30 76 28 41 |\.@v.....+.N0v(A|
00000150 b2 62 a8 fb 5b f1 f9 4e 7a 8d bd 09 b8 ae ea 8b |.b..[..Nz.......|
00000160 18 27 4f 2e 70 fe 13 96 ba c3 d3 40 16 cd 65 4e |.'O.p......@..eN|
00000170 ac 11 1e e6 f1 30 09 06 07 2a 86 48 ce 3d 04 01 |.....0...*.H.=..|
00000180 03 81 8c 00 30 81 88 02 42 00 e0 14 c4 60 60 0b |....0...B....``.|
00000190 72 68 b0 32 5d 61 4a 02 74 5c c2 81 b9 16 a8 3f |rh.2]aJ.t\.....?|
000001a0 29 c8 36 c7 81 ff 6c b6 5b d9 70 f1 38 3b 50 48 |).6...l.[.p.8;PH|
000001b0 28 94 cb 09 1a 52 f1 5d ee 8d f2 b9 f0 f0 da d9 |(....R.]........|
000001c0 15 3a f9 bd 03 7a 87 a2 23 35 ec 02 42 01 a3 d4 |.:...z..#5..B...|
000001d0 8a 78 35 1c 4a 9a 23 d2 0a be 2b 10 31 9d 9c 5f |.x5.J.#...+.1.._|
000001e0 be e8 91 b3 da 1a f5 5d a3 23 f5 26 8b 45 70 8d |.......].#.&.Ep.|
000001f0 65 62 9b 7e 01 99 3d 18 f6 10 9a 38 61 9b 2e 57 |eb.~..=....8a..W|
00000200 e4 fa cc b1 8a ce e2 23 a0 87 f0 e1 67 51 eb 16 |.......#....gQ..|
00000210 03 01 00 46 10 00 00 42 41 04 1e 18 37 ef 0d 19 |...F...BA...7...|
00000220 51 88 35 75 71 b5 e5 54 5b 12 2e 8f 09 67 fd a7 |Q.5uq..T[....g..|
00000230 24 20 3e b2 56 1c ce 97 28 5e f8 2b 2d 4f 9e f1 |$ >.V...(^.+-O..|
00000240 07 9f 6c 4b 5b 83 56 e2 32 42 e9 58 b6 d7 49 a6 |..lK[.V.2B.X..I.|
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
00000250 b5 68 1a 41 03 56 6b dc 5a 89 16 03 01 00 91 0f |.h.A.Vk.Z.......|
00000260 00 00 8d 00 8b 30 81 88 02 42 01 3a 26 83 6d 4a |.....0...B.:&.mJ|
00000270 e0 87 d4 5e 54 98 f1 8e a5 23 5f be ce 7b 31 76 |...^T....#_..{1v|
00000280 9e f9 93 53 3f b7 a2 4a 80 9f cf ab 64 dc ed 91 |...S?..J....d...|
00000290 14 26 27 07 f9 00 64 76 06 a3 84 ea 5f f2 43 f7 |.&'...dv...._.C.|
000002a0 35 e1 db ff 53 af 9d 18 00 7f fb ad 02 42 01 fe |5...S........B..|
000002b0 56 93 31 ad c3 c3 dc 35 02 66 76 4e 8f 70 f2 10 |V.1....5.fvN.p..|
000002c0 84 9c 4b e1 93 7d 7a 7a 0b 4e 0e ae 82 17 17 dd |..K..}zz.N......|
000002d0 8a d0 ba 97 7a 6f 9d 2d d3 20 88 a5 2f 3a 01 ff |....zo.-. ../:..|
000002e0 14 17 94 d0 81 dc 9d 36 52 72 e9 47 57 4b f4 e5 |.......6Rr.GWK..|
000002f0 14 03 01 00 01 01 16 03 01 00 30 68 55 dd 97 80 |..........0hU...|
00000300 5b 94 75 02 9c c1 19 f6 c4 04 c1 8a ad 8f 16 f2 |[.u.............|
00000310 b6 d6 c1 3b 35 f6 13 ab e3 d1 b7 e4 f9 a9 d5 5f |...;5.........._|
00000320 37 9c 3b d8 39 95 2b 66 73 e6 54 |7.;.9.+fs.T|
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 4 (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 14 03 01 00 01 01 16 03 01 00 30 92 07 14 a3 fa |..........0.....|
00000010 a6 8f 52 9b bf ae 2b 87 b6 c4 74 44 0f d2 c4 32 |..R...+...tD...2|
00000020 70 02 a3 48 a5 d0 e5 4d 3c c0 2e 56 e1 45 df b7 |p..H...M<..V.E..|
00000030 8a fb 84 7e 32 2c 94 cc 37 66 66 |...~2,..7ff|
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 5 (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 17 03 01 00 20 89 e2 cc e6 b6 9f 3f 60 b4 c6 88 |.... ......?`...|
00000010 33 4d 0e 05 e6 0f 31 3c 87 7c a1 d5 2b 96 1e b6 |3M....1<.|..+...|
00000020 e1 dd 72 5e a1 17 03 01 00 20 f7 53 3e de 51 fc |..r^..... .S>.Q.|
00000030 f0 dd 93 88 62 25 c0 d4 4f dd 4a ea c5 3c d7 51 |....b%..O.J..<.Q|
00000040 68 72 50 fc be ed 57 80 c5 10 15 03 01 00 20 68 |hrP...W....... h|
00000050 6f f8 4e c9 c0 cd 9b ab 71 41 b3 97 87 5c 00 99 |o.N.....qA...\..|
00000060 50 46 20 a2 48 29 14 30 63 46 84 5b 96 7e 79 |PF .H).0cF.[.~y|
Reference in New Issue Copy Permalink