October 2016 - tor-commits - lists.torproject.org

[depictor/master] Add the measured and consensus bandwidth weight
by tom＠torproject.org 16 Oct '16

16 Oct '16

commit 6061a7df37f1cca636875c328b5e953da09b952f Author: Tom Ritter <tom(a)ritter.vg> Date: Sat Oct 15 22:16:16 2016 -0400 Add the measured and consensus bandwidth weight --- website.py | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/website.py b/website.py index 9082387..23d48e1 100755 --- a/website.py +++ b/website.py @@ -934,6 +934,10 @@ class WebsiteWriter: elif consensusFlags and flag in vote.known_flags and flag in consensusFlags: self.site.write( "<span class=\"oic\">" + flag + "</span>") + if vote.routers[relay_fp].measured >= 0L: + self.site.write(" <br />" if flagsWritten > 0 else "") + self.site.write("bw=" + str(vote.routers[relay_fp].measured)) + self.site.write("</td>\n"); else: self.site.write(" <td></td>\n") @@ -948,6 +952,11 @@ class WebsiteWriter: if flag in consensusFlags: self.site.write(flag) + + if self.consensus.routers[relay_fp].bandwidth >= 0L: + self.site.write(" <br />" if flagsWritten > 0 else "") + self.site.write("bw=" + str(self.consensus.routers[relay_fp].bandwidth)) + self.site.write("</td>\n") else: self.site.write(" <td></td>\n")

1 0

[depictor/master] Rename the Relay Flags table to the Relay Info table
by tom＠torproject.org 16 Oct '16

16 Oct '16

commit cad41ec3b5d08d9410fa654298db1a0cc6aa7947 Author: Tom Ritter <tom(a)ritter.vg> Date: Sat Oct 15 22:15:56 2016 -0400 Rename the Relay Flags table to the Relay Info table --- website.py | 46 +++++++++++++++++++++++----------------------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/website.py b/website.py index bdc1d5e..9082387 100755 --- a/website.py +++ b/website.py @@ -21,9 +21,9 @@ class WebsiteWriter: consensus_expirey = datetime.timedelta(hours=3) directory_key_warning_time = datetime.timedelta(days=14) known_params = [] - def write_website(self, filename, include_relay_flags=True): + def write_website(self, filename, include_relay_info=True): self.site = open(filename, 'w') - self._write_page_header(include_relay_flags) + self._write_page_header(include_relay_info) self._write_valid_after_time() self._write_signatures() self._write_known_flags() @@ -35,11 +35,11 @@ class WebsiteWriter: self._write_bandwidth_scanner_status(True) self._write_authority_versions() self._write_download_statistics() - self._write_relay_flags_summary() - if include_relay_flags: - self._write_relay_flags_table() + self._write_relay_info_summary() + if include_relay_info: + self._write_relay_info_table() else: - self._write_relay_flags_pointer() + self._write_relay_info_pointer() self._write_page_footer() self.site.close() @@ -62,7 +62,7 @@ class WebsiteWriter: return self.consensus.valid_after #----------------------------------------------------------------------------------------- - def _write_page_header(self, include_relay_flags): + def _write_page_header(self, include_relay_info): """ Write the HTML page header including the metrics website navigation. """ @@ -105,10 +105,10 @@ class WebsiteWriter: + " <p>This page shows statistics about the current " + "consensus and votes to facilitate debugging of the " + "directory consensus process.") - if not include_relay_flags: + if not include_relay_info: self.site.write("<br />This is the abbreviated page. The " + "<a href=\"/consensus-health.html\">detailed page</a> " - + "which includes the (large) relay flags table is also " + + "which includes the (large) relay info table is also " + "available.") self.site.write("</p>\n") @@ -691,7 +691,7 @@ class WebsiteWriter: self.site.write("</table>\n"); #----------------------------------------------------------------------------------------- - def _write_relay_flags_summary(self): + def _write_relay_info_summary(self): """ Write the relay flag summary """ @@ -803,26 +803,26 @@ class WebsiteWriter: self.site.write("</table>\n") #----------------------------------------------------------------------------------------- - def _write_relay_flags_pointer(self): + def _write_relay_info_pointer(self): """ Write a pointer to where the huge table is located """ self.site.write("<br>\n\n\n" + " " - + "<a name=\"relayflags\">\n" - + "<h3><a href=\"#relayflags\" class=\"anchor\">Relay flags</a></h3>\n" + + "<a name=\"relayinfo\">\n" + + "<h3><a href=\"#relayinfo\" class=\"anchor\">Relay info</a></h3>\n" + "<br>\n" - + "<p>Looking for the (huge) relay flags table? It's been moved to the <a " + + "<p>Looking for the (huge) relay info table? It's been moved to the <a " + "href=\"/consensus-health.html\">detailed page</a> to speed up this page.</p>\n") - def _write_relay_flags_table(self): + def _write_relay_info_table(self): """ - Write the (huge) table containing relay flags contained in votes and + Write the (huge) table containing relay info contained in votes and the consensus for each relay. """ self.site.write("<br>\n\n\n" + " " - + "<a name=\"relayflags\">\n" - + "<h3><a href=\"#relayflags\" class=\"anchor\">Relay flags</a></h3>\n" + + "<a name=\"relayinfo\">\n" + + "<h3><a href=\"#relayinfo\" class=\"anchor\">Relay info</a></h3>\n" + "<br>\n" + "<p>The semantics of flags written in the table is similar to the table above:</p>\n" + "<ul>\n" @@ -857,14 +857,14 @@ class WebsiteWriter: sortedKeys.sort() for relay_fp in sortedKeys: if linesWritten % 10 == 0: - self._write_relay_flags_tableHeader() + self._write_relay_info_tableHeader() linesWritten += 1 - self._write_relay_flags_tableRow(relay_fp, allRelays[relay_fp]) + self._write_relay_info_tableRow(relay_fp, allRelays[relay_fp]) self.site.write("</table>\n") #----------------------------------------------------------------------------------------- - def _write_relay_flags_tableHeader(self): + def _write_relay_info_tableHeader(self): """ Write the table header that is repeated every ten relays and that contains the directory authority names. @@ -876,9 +876,9 @@ class WebsiteWriter: self.site.write(" <th>consensus</th>\n </tr>\n") #----------------------------------------------------------------------------------------- - def _write_relay_flags_tableRow(self, relay_fp, relay_nickname): + def _write_relay_info_tableRow(self, relay_fp, relay_nickname): """ - Write a single row in the table of relay flags. + Write a single row in the table of relay info. """ self.site.write(" <tr>\n") if relay_fp in self.consensus.routers and \

1 0

[depictor/master] Make the historical database available for download
by tom＠torproject.org 16 Oct '16

16 Oct '16

commit de52f15c1cbfbfd7cd54c88787a00f3762c8320c Author: Tom Ritter <tom(a)ritter.vg> Date: Sat Oct 15 21:35:17 2016 -0400 Make the historical database available for download --- write_website.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/write_website.py b/write_website.py index 87863d6..ddb5a47 100755 --- a/write_website.py +++ b/write_website.py @@ -145,6 +145,8 @@ def main(): #subprocess.call(["gzip", "-9", archived]) #subprocess.call(["ln", "-s", archived + ".gz", archived]) + subprocess.call(["cp", os.path.join('data', 'historical.db'), os.path.join('out', 'historical.db')]) + # remove old files weeks_to_keep = 3 files = [f for f in os.listdir(os.path.join(os.path.dirname(__file__), 'out'))]

1 0

[torspec/master] Merge remote-tracking branch 'origin/master' into 269-change-kdf
by isis＠torproject.org 15 Oct '16

15 Oct '16

commit 5d428fe9b889ea43f71aa0d5c9673de37d1ca7f0 Merge: e6ba76c 7c0ac12 Author: John M. Schanck <jschanck(a)securityinnovation.com> Date: Fri Oct 14 13:54:11 2016 -0400 Merge remote-tracking branch 'origin/master' into 269-change-kdf control-spec.txt | 34 +++- dir-spec.txt | 20 ++- proposals/000-index.txt | 14 +- proposals/220-ecc-id-keys.txt | 8 + proposals/224-rend-spec-ng.txt | 67 ++++---- proposals/244-use-rfc5705-for-tls-binding.txt | 6 +- proposals/264-subprotocol-versions.txt | 59 ++++--- proposals/272-valid-and-running-by-default.txt | 3 +- proposals/273-exit-relay-pinning.txt | 223 +++++++++++++++++++++++++ rend-spec.txt | 4 +- tor-spec.txt | 4 +- 11 files changed, 368 insertions(+), 74 deletions(-)

1 0

[torspec/master] prop269: Append PROTOID to TRANSCRIPT
by isis＠torproject.org 15 Oct '16

15 Oct '16

commit 045a8afb0c1b18b19fdc87b9b3aec3f498fcd859 Author: John M. Schanck <jschanck(a)securityinnovation.com> Date: Fri Oct 14 14:07:09 2016 -0400 prop269: Append PROTOID to TRANSCRIPT --- proposals/269-hybrid-handshake.txt | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/proposals/269-hybrid-handshake.txt b/proposals/269-hybrid-handshake.txt index eb35180..d2197da 100644 --- a/proposals/269-hybrid-handshake.txt +++ b/proposals/269-hybrid-handshake.txt @@ -174,7 +174,7 @@ Status: Draft The server derives the authentication tag: verify := EXPAND(seed, T_AUTH, MU) - TRANSCRIPT := ID | A | X | EPK | Y | C + TRANSCRIPT := ID | A | X | EPK | Y | C | PROTOID AUTH := HMAC(verify, TRANSCRIPT) The server sends a CREATED cell with contents: @@ -196,7 +196,7 @@ Status: Draft The client derives the authentication tag: verify := EXPAND(seed, T_AUTH, MU) - TRANSCRIPT := ID | A | X | EPK | Y | C + TRANSCRIPT := ID | A | X | EPK | Y | C | PROTOID AUTH := HMAC(verify, TRANSCRIPT) The client verifies that AUTH matches the tag received from the server. @@ -221,18 +221,18 @@ Status: Draft | | | --- CREATE_DATA ---> | | | - | y, Y := DH_GEN() | - | s0 := H(DH_MUL(X,a)) | - | s1 := DH_MUL(X,y) | - | s2, C := KEM_ENC(EPK) | - | SALT := ID | A | X | EPK | - | secret := s0 | s1 | s2 | - | seed := EXTRACT(SALT, secret) | - | verify := EXPAND(seed, T_AUTH, MU) | - | TRANSCRIPT := ID | A | X | Y | EPK | C | - | AUTH := HMAC(verify, TRANSCRIPT) | - | key := EXPAND(seed, T_KEY, KEY_LEN) | - | CREATED_DATA := Y | C | AUTH | + | y, Y := DH_GEN() | + | s0 := H(DH_MUL(X,a)) | + | s1 := DH_MUL(X,y) | + | s2, C := KEM_ENC(EPK) | + | SALT := ID | A | X | EPK | + | secret := s0 | s1 | s2 | + | seed := EXTRACT(SALT, secret) | + | verify := EXPAND(seed, T_AUTH, MU) | + | TRANSCRIPT := ID | A | X | Y | EPK | C | PROTOID | + | AUTH := HMAC(verify, TRANSCRIPT) | + | key := EXPAND(seed, T_KEY, KEY_LEN) | + | CREATED_DATA := Y | C | AUTH | | | | <-- CREATED_DATA --- | | | @@ -283,7 +283,7 @@ Status: Draft secret_input := H(EXP(X,a)) | EXP(X,y) seed := EXTRACT(SALT, secret_input) verify := EXPAND(seed, T_AUTH, MU) - TRANSCRIPT := ID | A | X | Y + TRANSCRIPT := ID | A | X | Y | PROTOID AUTH := HMAC(verify, TRANSCRIPT) key := EXPAND(seed, T_KEY, KEY_LEN)

1 0

[torspec/master] Merge remote-tracking branch 'jschanck/269-alt-kdf'
by isis＠torproject.org 15 Oct '16

15 Oct '16

commit 043eec0e26977b1e6e0080405ab3ba354a6c945a Merge: 7c0ac12 a5b0f57 Author: Isis Lovecruft <isis(a)torproject.org> Date: Sat Oct 15 00:51:17 2016 +0000 Merge remote-tracking branch 'jschanck/269-alt-kdf' proposals/269-hybrid-handshake.txt | 180 +++++++++++++++++++------------------ 1 file changed, 95 insertions(+), 85 deletions(-)

1 0

[torspec/master] prop269: Alternative KDF
by isis＠torproject.org 15 Oct '16

15 Oct '16

commit e6ba76c41f59d536e95ad69e934a23fe3342aea4 Author: John M. Schanck <jschanck(a)securityinnovation.com> Date: Fri Sep 2 17:09:35 2016 -0400 prop269: Alternative KDF This variant makes two theoretically interesting changes: 1) It only uses client provided inputs for the extractor salt, 2) It includes an additional HMAC step for deriving AUTH. The first change prevents someone who is attempting to impersonate the server from biasing the randomness extractor. We don't expect such a biasing attack to be possible, but there's no harm in eliminating the possibility. The second change eliminates the 2^lambda session collision attack mentioned in previous versions. --- proposals/269-hybrid-handshake.txt | 84 +++++++++++++++++++++----------------- 1 file changed, 47 insertions(+), 37 deletions(-) diff --git a/proposals/269-hybrid-handshake.txt b/proposals/269-hybrid-handshake.txt index 0fbaae0..76b32c0 100644 --- a/proposals/269-hybrid-handshake.txt +++ b/proposals/269-hybrid-handshake.txt @@ -3,7 +3,7 @@ Title: Transitionally secure hybrid handshakes Author: John Schanck, William Whyte, Zhenfei Zhang, Nick Mathewson, Isis Lovecruft, Peter Schwabe Created: 7 June 2016 -Updated: 22 July 2016 +Updated: 2 Sept 2016 Status: Draft @@ -147,9 +147,9 @@ Status: Draft - Client Init ------------------------------------------------------------ - The client generates ephemeral key pairs + The client generates ephemeral key pairs: x, X = DH_GEN() - esk, EPK = KEM_GEN(). + esk, EPK = KEM_GEN() The client sends a CREATE cell with contents: ID [ID_LEN bytes] @@ -159,18 +159,23 @@ Status: Draft - Server Response -------------------------------------------------------- - The server generates an ephemeral x25519 keypair, computes both DH - shares, and encrypts a secret under KEM: + The server generates an ephemeral DH keypair: y, Y := DH_GEN() + + The server computes the three secret shares: s0 := H(DH_MUL(X,a)) s1 := DH_MUL(X,y) s2, C := KEM_ENC(EPK) - The server then derives the pre-master secret and authentication tag: + The server extracts the seed: + SALT := H(ID | A | X | EPK) secret := s0 | s1 | s2 - SALT := ID | A | X | Y | EPK | C seed := EXTRACT(SALT, secret) - AUTH := EXPAND(seed, T_AUTH, MU) + + The server derives the authentication tag: + verify := EXPAND(seed, T_AUTH, MU) + TRANSCRIPT := ID | A | X | EPK | Y | C + AUTH := HMAC(verify, TRANSCRIPT) The server sends a CREATED cell with contents: Y [DH_LEN bytes] @@ -184,20 +189,24 @@ Status: Draft s1 := DH_MUL(Y,x) s2 := KEM_DEC(C, esk) - The client then derives the pre-master secret: + The client then derives the seed: + SALT := H(ID | A | X | EPK) secret := s0 | s1 | s2 - SALT := ID | A | X | Y | EPK | C seed := EXTRACT(SALT, secret); - The client verifies that AUTH == EXPAND(seed, T_AUTH, MU). + The client derives the authentication tag: + verify := EXPAND(seed, T_AUTH, MU) + TRANSCRIPT := ID | A | X | EPK | Y | C + AUTH := HMAC(verify, TRANSCRIPT) - If the authentication check passes the client expands the seed + The client verifies that AUTH matches the tag received from the server. - - Key derivation --------------------------------------------------------- + If the authentication check fails the client aborts the session. - Both parties derive the shared key by expanding seed: + - Key derivation --------------------------------------------------------- - KEY := EXPAND(seed, T_KEY, KEY_LEN) + Both parties derive the shared key from the seed: + key := EXPAND(seed, T_KEY, KEY_LEN). .--------------------------------------------------------------------------. | Fig. 1: The hybrid-DH-KEM handshake. | @@ -216,11 +225,13 @@ Status: Draft | s0 := H(DH_MUL(X,a)) | | s1 := DH_MUL(X,y) | | s2, C := KEM_ENC(EPK) | + | SALT := H(ID | A | X | EPK) | | secret := s0 | s1 | s2 | - | SALT := ID | A | X | Y | EPK | C | | seed := EXTRACT(SALT, secret) | - | AUTH := EXPAND(seed, T_AUTH, MU) | - | KEY := EXPAND(seed, T_KEY, KEY_LEN) | + | verify := EXPAND(seed, T_AUTH, MU) | + | TRANSCRIPT := ID | A | X | Y | EPK | C | + | AUTH := HMAC(verify, TRANSCRIPT) | + | key := EXPAND(seed, T_KEY, KEY_LEN) | | CREATED_DATA := Y | C | AUTH | | | | <-- CREATED_DATA --- | @@ -228,12 +239,14 @@ Status: Draft | s0 := H(DH_MUL(A,x)) | | s1 := DH_MUL(Y,x) | | s2 := KEM_DEC(C, esk) | + | SALT := H(ID | A | X | EPK) | | secret := s0 | s1 | s2 | - | SALT := ID | A | X | Y | EPK | C | | seed := EXTRACT(SALT, secret) | + | verify := EXPAND(seed, T_AUTH, MU) | + | TRANSCRIPT := ID | A | X | Y | EPK | C | | | - | assert AUTH == EXPAND(seed, T_AUTH, MU) | - | KEY := EXPAND(seed, T_KEY, KEY_LEN) | + | assert AUTH == HMAC(verify, TRANSCRIPT) | + | key := EXPAND(seed, T_KEY, KEY_LEN) | '--------------------------------------------------------------------------' @@ -254,7 +267,7 @@ Status: Draft hybrid-null T_AUTH PROTOID | ":auth". Then there are significant differences in how the authentication tag - (AUTH) and key (KEY) are derived. The following description uses the + (AUTH) and key (key) are derived. The following description uses the HMAC based definitions of EXTRACT and EXPAND. In ntor the server computes @@ -263,14 +276,16 @@ Status: Draft verify := HMAC(T_VERIFY, seed) auth_input := verify | ID | A | Y | X | PROTOID | "Server" AUTH := HMAC(T_MAC, auth_input) - KEY := EXPAND(seed, M_EXPAND, KEY_LEN). + key := EXPAND(seed, M_EXPAND, KEY_LEN) In hybrid-null the server computes + SALT := H(ID | A | X) secret_input := H(EXP(X,a)) | EXP(X,y) - SALT := ID | A | X | Y seed := EXTRACT(SALT, secret_input) - AUTH := EXPAND(seed, T_AUTH, MU) - KEY := EXPAND(seed, T_KEY, KEY_LEN). + verify := EXPAND(seed, T_AUTH, MU) + TRANSCRIPT := ID | A | X | Y + AUTH := HMAC(verify, TRANSCRIPT) + key := EXPAND(seed, T_KEY, KEY_LEN) First, note that hybrid-null hashes EXP(X,a). This is due to the fact that weaker assumptions were used to prove the security @@ -278,15 +293,11 @@ Status: Draft this may seem artificial we recommend keeping it. Second, ntor uses fixed HMAC keys for all sessions. This is unlikely - to be a security issue, but it makes a stronger assumption on HMAC - than if the order of the arguments were reversed. + to be a real-world security issue, but it requires stronger assumptions + about HMAC than if the order of the arguments were reversed. - Third, hybrid-null forgoes the use of auth_input (to see what we mean, - compare hybrid-null to ntor with auth_input := seed). The use of - auth_input in ntor is designed to prevent a certain type of collision - attack (see [Zav12, SZW16]). However the auth_input countermeasure is - unnecessary if the authentication tag is of length 2*LAMBDA. A collision - attack on a random function of output length 2*LAMBDA has cost 2^LAMBDA. + Finally, ntor uses a mixture of public and secret data in auth_input, + whereas the equivalent term in hybrid-null is the public transcript. 4. Instantiation with NTRUEncrypt @@ -325,6 +336,7 @@ Status: Draft Subroutines ----------- + HMAC(key, message) := SHAKE-128(key | message, MU) EXTRACT(salt, secret) := SHAKE-128(salt | secret, MU) EXPAND(seed, context, len) := SHAKE-128(seed | context, len) KEM_GEN() := EES443EP2_GEN() @@ -360,6 +372,7 @@ Status: Draft Subroutines ----------- + HMAC(key, message) := SHAKE-128(key | message, MU) EXTRACT(salt, secret) := SHAKE-128(salt | secret, MU) EXPAND(seed, context, len) -> SHAKE-128(seed | context, len) KEM_GEN() -> (sk, PK) @@ -397,9 +410,6 @@ Status: Draft 8. Bibliography -[Zav12] G.M. Zaverucha. Hybrid encryption in the multi-user setting. - Cryptology ePrint Archive, Report 2012/159, 2012. - http://eprint.iacr.org/2012/159. [SWZ16] Schanck, J., Whyte, W., and Z. Zhang, "Circuit extension handshakes for Tor achieving forward secrecy in a quantum world", PETS 2016, DOI 10.1515/popets-2016-0037, June 2016.

1 0

[torspec/master] dir-spec: Fix two typos and a missing comma from a subordinate clause.
by isis＠torproject.org 15 Oct '16

15 Oct '16

commit ea0d89ff6ceb083d2b4718f2afd35ac574949d0f Author: Isis Lovecruft <isis(a)torproject.org> Date: Fri Oct 14 18:16:49 2016 +0000 dir-spec: Fix two typos and a missing comma from a subordinate clause. --- dir-spec.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/dir-spec.txt b/dir-spec.txt index d5e8376..87e038d 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -1284,7 +1284,7 @@ At a future date, authorities will begin rejecting all descriptors whose RSA key was previously accompanied by an - Ed25519 key, if the descriptor does not list and Ed25519 key. + Ed25519 key, if the descriptor does not list an Ed25519 key. At a future date, authorities will begin rejecting all descriptors that do not list an Ed25519 key. @@ -1472,8 +1472,8 @@ Also, once an authority receives a vote from another authority, it examines it for new descriptors and fetches them from that authority. - This may the only way for an authority to hear about relays that didn't - publish their descriptor to all authorities, and while it's too late + This may be the only way for an authority to hear about relays that didn't + publish their descriptor to all authorities, and, while it's too late for the authority to include relays in its current vote, it can include them in its next vote. See section 3.6 below for details.

1 0

[torspec/master] prop269: Moved instantiations to appendix
by isis＠torproject.org 15 Oct '16

15 Oct '16

commit a5b0f57f0e3beace8d5c6a5fc305fe97e7928865 Author: John M. Schanck <jschanck(a)securityinnovation.com> Date: Fri Oct 14 14:08:46 2016 -0400 prop269: Moved instantiations to appendix --- proposals/269-hybrid-handshake.txt | 82 +++++++++++++++++++------------------- 1 file changed, 41 insertions(+), 41 deletions(-) diff --git a/proposals/269-hybrid-handshake.txt b/proposals/269-hybrid-handshake.txt index d2197da..a91a09e 100644 --- a/proposals/269-hybrid-handshake.txt +++ b/proposals/269-hybrid-handshake.txt @@ -300,7 +300,46 @@ Status: Draft whereas the equivalent term in hybrid-null is the public transcript. -4. Instantiation with NTRUEncrypt + +4. Versions + + [XXX rewrite section w/ new versioning proposal] + + Recognized handshake types are: + 0x0000 TAP -- the original Tor handshake; + 0x0001 reserved + 0x0002 ntor -- the ntor-x25519-sha256 handshake; + + Request for new handshake types: + 0x010X hybrid-XX -- a hybrid of a x25519 handshake + and a post-quantum key encapsulation mechanism + + where + 0x0101 hybrid-null -- No post-quantum key encapsulation mechanism. + + 0x0102 hybrid-ees443ep2 -- Using NTRUEncrypt parameter set ntrueess443ep2 + + 0x0103 hybrid-newhope -- Using the New Hope R-LWE scheme + + DEPENDENCY: + Proposal 249: Allow CREATE cells with >505 bytes of handshake data + + + +5. Bibliography + +[SWZ16] Schanck, J., Whyte, W., and Z. Zhang, "Circuit extension handshakes + for Tor achieving forward secrecy in a quantum world", PETS 2016, + DOI 10.1515/popets-2016-0037, June 2016. +[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, + "HMAC: Keyed-Hashing for Message Authentication", + RFC 2104, DOI 10.17487/RFC2104, February 1997 +[RFC5869] Krawczyk, H. and P. Eronen, + "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", + RFC 5869, DOI 10.17487/RFC5869, May 2010 + + +A1. Instantiation with NTRUEncrypt This example uses the NTRU parameter set EESS443EP2 [XXX cite] which is estimated at the 128 bit security level for both pre- and post-quantum @@ -346,7 +385,7 @@ Status: Draft KEM_DEC(C, sk) := EES443EP2_DECRYPT(C, sk) -5. Instantiation with NewHope +A2. Instantiation with NewHope [XXX write intro] @@ -381,42 +420,3 @@ Status: Draft PK := B | A_SEED KEM_ENC(PK) -> NEWHOPE_ENCAPS(PK) KEM_DEC(C, sk) -> NEWHOPE_DECAPS(C, sk) - - -7. Versions - - [XXX rewrite section w/ new versioning proposal] - - Recognized handshake types are: - 0x0000 TAP -- the original Tor handshake; - 0x0001 reserved - 0x0002 ntor -- the ntor-x25519-sha256 handshake; - - Request for new handshake types: - 0x010X hybrid-XX -- a hybrid of a x25519 handshake - and a post-quantum key encapsulation mechanism - - where - 0x0101 hybrid-null -- No post-quantum key encapsulation mechanism. - - 0x0102 hybrid-ees443ep2 -- Using NTRUEncrypt parameter set ntrueess443ep2 - - 0x0103 hybrid-newhope -- Using the New Hope R-LWE scheme - - DEPENDENCY: - Proposal 249: Allow CREATE cells with >505 bytes of handshake data - - - -8. Bibliography - -[SWZ16] Schanck, J., Whyte, W., and Z. Zhang, "Circuit extension handshakes - for Tor achieving forward secrecy in a quantum world", PETS 2016, - DOI 10.1515/popets-2016-0037, June 2016. -[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, - "HMAC: Keyed-Hashing for Message Authentication", - RFC 2104, DOI 10.17487/RFC2104, February 1997 -[RFC5869] Krawczyk, H. and P. Eronen, - "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", - RFC 5869, DOI 10.17487/RFC5869, May 2010 -

1 0

[torspec/master] prop269: Removed hash of initial XTR salt
by isis＠torproject.org 15 Oct '16

15 Oct '16

commit 8de17fa1b84c59a74178aba57c146bfb431801cf Author: John M. Schanck <jschanck(a)securityinnovation.com> Date: Fri Oct 14 14:05:18 2016 -0400 prop269: Removed hash of initial XTR salt --- proposals/269-hybrid-handshake.txt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/proposals/269-hybrid-handshake.txt b/proposals/269-hybrid-handshake.txt index 76b32c0..eb35180 100644 --- a/proposals/269-hybrid-handshake.txt +++ b/proposals/269-hybrid-handshake.txt @@ -168,7 +168,7 @@ Status: Draft s2, C := KEM_ENC(EPK) The server extracts the seed: - SALT := H(ID | A | X | EPK) + SALT := ID | A | X | EPK secret := s0 | s1 | s2 seed := EXTRACT(SALT, secret) @@ -190,7 +190,7 @@ Status: Draft s2 := KEM_DEC(C, esk) The client then derives the seed: - SALT := H(ID | A | X | EPK) + SALT := ID | A | X | EPK secret := s0 | s1 | s2 seed := EXTRACT(SALT, secret); @@ -225,7 +225,7 @@ Status: Draft | s0 := H(DH_MUL(X,a)) | | s1 := DH_MUL(X,y) | | s2, C := KEM_ENC(EPK) | - | SALT := H(ID | A | X | EPK) | + | SALT := ID | A | X | EPK | | secret := s0 | s1 | s2 | | seed := EXTRACT(SALT, secret) | | verify := EXPAND(seed, T_AUTH, MU) | @@ -239,7 +239,7 @@ Status: Draft | s0 := H(DH_MUL(A,x)) | | s1 := DH_MUL(Y,x) | | s2 := KEM_DEC(C, esk) | - | SALT := H(ID | A | X | EPK) | + | SALT := ID | A | X | EPK | | secret := s0 | s1 | s2 | | seed := EXTRACT(SALT, secret) | | verify := EXPAND(seed, T_AUTH, MU) | @@ -279,7 +279,7 @@ Status: Draft key := EXPAND(seed, M_EXPAND, KEY_LEN) In hybrid-null the server computes - SALT := H(ID | A | X) + SALT := ID | A | X secret_input := H(EXP(X,a)) | EXP(X,y) seed := EXTRACT(SALT, secret_input) verify := EXPAND(seed, T_AUTH, MU)

1 0