From d66c1c7e8160b2ea0c8ea94e15b58ce5f6588603 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Mon, 25 Mar 2024 21:10:24 -0400 Subject: Rename "text vectors" to "test vectors" for correctness. --- spec/SUMMARY.md | 2 +- spec/rend-spec/test-vectors.md | 101 +++++++++++++++++++++++++++++++++++++++++ spec/rend-spec/text-vectors.md | 101 ----------------------------------------- 3 files changed, 102 insertions(+), 102 deletions(-) create mode 100644 spec/rend-spec/test-vectors.md delete mode 100644 spec/rend-spec/text-vectors.md diff --git a/spec/SUMMARY.md b/spec/SUMMARY.md index ade9586..70fa46a 100644 --- a/spec/SUMMARY.md +++ b/spec/SUMMARY.md @@ -127,7 +127,7 @@ - [Appendix F: Hidden service directory format \[HIDSERVDIR-FORMAT\]](./rend-spec/fs-contents.md) - [Appendix G: Managing authorized client data \[CLIENT-AUTH-MGMT\]](./rend-spec/client-authorization.md) - [Appendix F: Two methods for managing revision counters.](./rend-spec/revision-counter-mgt.md) - - [Appendix G: Text vectors](./rend-spec/text-vectors.md) + - [Appendix G: Test vectors](./rend-spec/test-vectors.md) - [`Proof of Work for onion service introduction`](./hspow-spec/index.md) - [Motivation](./hspow-spec/motivation.md) - [Common protocol](./hspow-spec/common-protocol.md) diff --git a/spec/rend-spec/test-vectors.md b/spec/rend-spec/test-vectors.md new file mode 100644 index 0000000..d77049e --- /dev/null +++ b/spec/rend-spec/test-vectors.md @@ -0,0 +1,101 @@ + + +# Appendix G: Test vectors + +G.1. Test vectors for hs-ntor / NTOR-WITH-EXTRA-DATA + +```text + Here is a set of test values for the hs-ntor handshake, called + [NTOR-WITH-EXTRA-DATA] in this document. They were generated by + instrumenting Tor's code to dump the values for an INTRODUCE/RENDEZVOUS + handshake, and then by running that code on a Chutney network. + + We assume an onion service with: + + KP_hs_ipd_sid = 34E171E4358E501BFF21ED907E96AC6B + FEF697C779D040BBAF49ACC30FC5D21F + KP_hss_ntor = 8E5127A40E83AABF6493E41F142B6EE3 + 604B85A3961CD7E38D247239AFF71979 + KS_hss_ntor = A0ED5DBF94EEB2EDB3B514E4CF6ABFF6 + 022051CC5F103391F1970A3FCD15296A + N_hs_subcred = 0085D26A9DEBA252263BF0231AEAC59B + 17CA11BAD8A218238AD6487CBAD68B57 + + The client wants to make in INTRODUCE request. It generates + the following header (everything before the ENCRYPTED portion) + of its INTRODUCE1 message: + + H = 000000000000000000000000000000000000000002002034E171E4358E501BFF + 21ED907E96AC6BFEF697C779D040BBAF49ACC30FC5D21F00 + + It generates the following plaintext body to encrypt. (This + is the "decrypted plaintext body" from [PROCESS_INTRO2]. + + P = 6BD364C12638DD5C3BE23D76ACA05B04E6CE932C0101000100200DE6130E4FCA + C4EDDA24E21220CC3EADAE403EF6B7D11C8273AC71908DE565450300067F0000 + 0113890214F823C4F8CC085C792E0AEE0283FE00AD7520B37D0320728D5DF39B + 7B7077A0118A900FF4456C382F0041300ACF9C58E51C392795EF870000000000 + 0000000000000000000000000000000000000000000000000000000000000000 + 000000000000000000000000000000000000000000000000000000000000 + + (Note! This should in fact be padded to be longer; when these + test vectors were generated, the target INTRODUCE1 length in C + Tor was needlessly short.) + + The client now begins the hs-ntor handshake. It generates + a curve25519 keypair: + + x = 60B4D6BF5234DCF87A4E9D7487BDF3F4 + A69B6729835E825CA29089CFDDA1E341 + X = BF04348B46D09AED726F1D66C618FDEA + 1DE58E8CB8B89738D7356A0C59111D5D + + Then it calculates: + + ENC_KEY = 9B8917BA3D05F3130DACCE5300C3DC27 + F6D012912F1C733036F822D0ED238706 + MAC_KEY = FC4058DA59D4DF61E7B40985D122F502 + FD59336BC21C30CAF5E7F0D4A2C38FD5 + + With these, it encrypts the plaintext body P with ENC_KEY, getting + an encrypted value C. It computes MAC(MAC_KEY, H | X | C), + getting a MAC value M. It then assembles the final INTRODUCE1 + body as H | X | C | M: + + 000000000000000000000000000000000000000002002034E171E4358E501BFF + 21ED907E96AC6BFEF697C779D040BBAF49ACC30FC5D21F00BF04348B46D09AED + 726F1D66C618FDEA1DE58E8CB8B89738D7356A0C59111D5DADBECCCB38E37830 + 4DCC179D3D9E437B452AF5702CED2CCFEC085BC02C4C175FA446525C1B9D5530 + 563C362FDFFB802DAB8CD9EBC7A5EE17DA62E37DEEB0EB187FBB48C63298B0E8 + 3F391B7566F42ADC97C46BA7588278273A44CE96BC68FFDAE31EF5F0913B9A9C + 7E0F173DBC0BDDCD4ACB4C4600980A7DDD9EAEC6E7F3FA3FC37CD95E5B8BFB3E + 35717012B78B4930569F895CB349A07538E42309C993223AEA77EF8AEA64F25D + DEE97DA623F1AEC0A47F150002150455845C385E5606E41A9A199E7111D54EF2 + D1A51B7554D8B3692D85AC587FB9E69DF990EFB776D8 +``` + +Later the service receives that body in an INTRODUCE2 message. It +processes it according to the hs-ntor handshake, and recovers +the client's plaintext P. To continue the hs-ntor handshake, +the service chooses a curve25519 keypair: + +```text + y = 68CB5188CA0CD7924250404FAB54EE13 + 92D3D2B9C049A2E446513875952F8F55 + Y = 8FBE0DB4D4A9C7FF46701E3E0EE7FD05 + CD28BE4F302460ADDEEC9E93354EE700 + + From this and the client's input, it computes: + + AUTH_INPUT_MAC = 4A92E8437B8424D5E5EC279245D5C72B + 25A0327ACF6DAF902079FCB643D8B208 + NTOR_KEY_SEED = 4D0C72FE8AFF35559D95ECC18EB5A368 + 83402B28CDFD48C8A530A5A3D7D578DB +``` + +The service sends back Y | AUTH_INPUT_MAC in its RENDEZVOUS1 message +body. From these, the client finishes the handshake, validates +AUTH_INPUT_MAC, and computes the same NTOR_KEY_SEED. + +Now that both parties have the same NTOR_KEY_SEED, they can derive +the shared key material they will use for their circuit. diff --git a/spec/rend-spec/text-vectors.md b/spec/rend-spec/text-vectors.md deleted file mode 100644 index eadaee2..0000000 --- a/spec/rend-spec/text-vectors.md +++ /dev/null @@ -1,101 +0,0 @@ - - -# Appendix G: Text vectors - -G.1. Test vectors for hs-ntor / NTOR-WITH-EXTRA-DATA - -```text - Here is a set of test values for the hs-ntor handshake, called - [NTOR-WITH-EXTRA-DATA] in this document. They were generated by - instrumenting Tor's code to dump the values for an INTRODUCE/RENDEZVOUS - handshake, and then by running that code on a Chutney network. - - We assume an onion service with: - - KP_hs_ipd_sid = 34E171E4358E501BFF21ED907E96AC6B - FEF697C779D040BBAF49ACC30FC5D21F - KP_hss_ntor = 8E5127A40E83AABF6493E41F142B6EE3 - 604B85A3961CD7E38D247239AFF71979 - KS_hss_ntor = A0ED5DBF94EEB2EDB3B514E4CF6ABFF6 - 022051CC5F103391F1970A3FCD15296A - N_hs_subcred = 0085D26A9DEBA252263BF0231AEAC59B - 17CA11BAD8A218238AD6487CBAD68B57 - - The client wants to make in INTRODUCE request. It generates - the following header (everything before the ENCRYPTED portion) - of its INTRODUCE1 message: - - H = 000000000000000000000000000000000000000002002034E171E4358E501BFF - 21ED907E96AC6BFEF697C779D040BBAF49ACC30FC5D21F00 - - It generates the following plaintext body to encrypt. (This - is the "decrypted plaintext body" from [PROCESS_INTRO2]. - - P = 6BD364C12638DD5C3BE23D76ACA05B04E6CE932C0101000100200DE6130E4FCA - C4EDDA24E21220CC3EADAE403EF6B7D11C8273AC71908DE565450300067F0000 - 0113890214F823C4F8CC085C792E0AEE0283FE00AD7520B37D0320728D5DF39B - 7B7077A0118A900FF4456C382F0041300ACF9C58E51C392795EF870000000000 - 0000000000000000000000000000000000000000000000000000000000000000 - 000000000000000000000000000000000000000000000000000000000000 - - (Note! This should in fact be padded to be longer; when these - test vectors were generated, the target INTRODUCE1 length in C - Tor was needlessly short.) - - The client now begins the hs-ntor handshake. It generates - a curve25519 keypair: - - x = 60B4D6BF5234DCF87A4E9D7487BDF3F4 - A69B6729835E825CA29089CFDDA1E341 - X = BF04348B46D09AED726F1D66C618FDEA - 1DE58E8CB8B89738D7356A0C59111D5D - - Then it calculates: - - ENC_KEY = 9B8917BA3D05F3130DACCE5300C3DC27 - F6D012912F1C733036F822D0ED238706 - MAC_KEY = FC4058DA59D4DF61E7B40985D122F502 - FD59336BC21C30CAF5E7F0D4A2C38FD5 - - With these, it encrypts the plaintext body P with ENC_KEY, getting - an encrypted value C. It computes MAC(MAC_KEY, H | X | C), - getting a MAC value M. It then assembles the final INTRODUCE1 - body as H | X | C | M: - - 000000000000000000000000000000000000000002002034E171E4358E501BFF - 21ED907E96AC6BFEF697C779D040BBAF49ACC30FC5D21F00BF04348B46D09AED - 726F1D66C618FDEA1DE58E8CB8B89738D7356A0C59111D5DADBECCCB38E37830 - 4DCC179D3D9E437B452AF5702CED2CCFEC085BC02C4C175FA446525C1B9D5530 - 563C362FDFFB802DAB8CD9EBC7A5EE17DA62E37DEEB0EB187FBB48C63298B0E8 - 3F391B7566F42ADC97C46BA7588278273A44CE96BC68FFDAE31EF5F0913B9A9C - 7E0F173DBC0BDDCD4ACB4C4600980A7DDD9EAEC6E7F3FA3FC37CD95E5B8BFB3E - 35717012B78B4930569F895CB349A07538E42309C993223AEA77EF8AEA64F25D - DEE97DA623F1AEC0A47F150002150455845C385E5606E41A9A199E7111D54EF2 - D1A51B7554D8B3692D85AC587FB9E69DF990EFB776D8 -``` - -Later the service receives that body in an INTRODUCE2 message. It -processes it according to the hs-ntor handshake, and recovers -the client's plaintext P. To continue the hs-ntor handshake, -the service chooses a curve25519 keypair: - -```text - y = 68CB5188CA0CD7924250404FAB54EE13 - 92D3D2B9C049A2E446513875952F8F55 - Y = 8FBE0DB4D4A9C7FF46701E3E0EE7FD05 - CD28BE4F302460ADDEEC9E93354EE700 - - From this and the client's input, it computes: - - AUTH_INPUT_MAC = 4A92E8437B8424D5E5EC279245D5C72B - 25A0327ACF6DAF902079FCB643D8B208 - NTOR_KEY_SEED = 4D0C72FE8AFF35559D95ECC18EB5A368 - 83402B28CDFD48C8A530A5A3D7D578DB -``` - -The service sends back Y | AUTH_INPUT_MAC in its RENDEZVOUS1 message -body. From these, the client finishes the handshake, validates -AUTH_INPUT_MAC, and computes the same NTOR_KEY_SEED. - -Now that both parties have the same NTOR_KEY_SEED, they can derive -the shared key material they will use for their circuit. -- cgit v1.2.3-54-g00ecf