tor-commits November 2011

tor-commits@lists.torproject.org

16 participants
987 discussions

[torspec/master] some more cleanups
by nickm＠torproject.org 01 Nov '11

01 Nov '11

commit d85f694f89249f4870bd24ad1c64bcb8f1d38d25 Author: Roger Dingledine <arma(a)torproject.org> Date: Mon Oct 31 20:59:04 2011 -0400 some more cleanups --- proposals/ideas/xxx-new-crypto-sketch.txt | 23 ++++++++++++----------- 1 files changed, 12 insertions(+), 11 deletions(-) diff --git a/proposals/ideas/xxx-new-crypto-sketch.txt b/proposals/ideas/xxx-new-crypto-sketch.txt index 551b403..9fbdbd2 100644 --- a/proposals/ideas/xxx-new-crypto-sketch.txt +++ b/proposals/ideas/xxx-new-crypto-sketch.txt @@ -20,7 +20,7 @@ Author: Nick Mathewson [*] and subsequent discussion on the tor-dev mailing list. Not considered here. RELAY CRYPTO - Addressed here in Section 6 + Addressed here in Section 6. DIRECTORY SYSTEM Addressed here. HIDDEN SERVICE SYSTEM @@ -58,7 +58,7 @@ Author: Nick Mathewson to tell whether it looks good or not; the existing attacks against it don't look like very bad news to me, but who knows whether it's getting enough attention that we can read. See also ChaCha; see also - the other eSTREAM winners/ finalists; see also SHA3 if the SHA3 winner + the other eSTREAM winners/finalists; see also SHA3 if the SHA3 winner specifies a way to use it as a stream cipher, or specifies an underlying stream/block cipher. @@ -115,7 +115,7 @@ Author: Nick Mathewson make any major free software distribution decide not to include us. I seem to recall seeing that one or two of the big ones had at one point decided to ship OpenSSL only with ECC disabled, either because of real - patent concerns, or because of an opinion that the certicom license + patent concerns, or because of an opinion that the Certicom license for ECC use in TLS was problematic for free software, or something like that. We should check that out. @@ -290,7 +290,7 @@ Author: Nick Mathewson Right now we compute fingerprints by taking the SHA1 hash of an ASN1 encoding of the RSA1024 identity key. We encode this in hex almost - everywhere, and prefix it with a $. + everywhere, and sometimes prefix it with a $. I propose that fingerprints of the future be determined by taking a digest using SHA256 or SHA3 of: @@ -353,8 +353,8 @@ Author: Nick Mathewson that Bob understands the ID key type and the fingerprint algorithm. So for every node, Alice must not only know a fingerprint that *she* - can use for that node, but also a set fingerprint such that every node - can understand at least one fingerprint in the set. + can use for that node, but also a set of fingerprints such that every + node can understand at least one fingerprint in the set. This implies a proliferation of fingerprints! We should tread carefully here. To prevent proliferation, the easiest solution is not @@ -363,7 +363,7 @@ Author: Nick Mathewson 3.4. Implications for EXTEND cells - As mentioned in 3.3, when a client Alice can tell node Bob to extend + As mentioned in 3.3, when a client Alice tells node Bob to extend to node Carol, she needs to give Bob a fingerprint for Carol that Bob will understand: one where Bob understands the digest algorithm, and understands the identity key type. @@ -393,7 +393,7 @@ Author: Nick Mathewson Router descriptors and extrainfo descriptors: - One problematic case is in in determining node families. If node A + One problematic case is in determining node families. If node A and node B want to list each other as being in the same family, they need to do so in a way that clients can interpret. That could mean listing SHA1-RSA1024 fingerprints so old clients understand, @@ -415,7 +415,7 @@ Author: Nick Mathewson fraction of authority bw usage. Adding more hashes is easy. For consensus documents, we ought to have flavors that you can - download depending on what set of fingerprints types you + download depending on what set of fingerprint types you understand. For integrity purposes, consensuses can refer to microdescriptors @@ -458,7 +458,7 @@ Author: Nick Mathewson We should however look to longer link keys, bigger DH groups, etc. - Once TLS versiosn 1.1/1.2 is available in OpenSSL, we should move to + Once TLS versions 1.1/1.2 are available in OpenSSL, we should move to use them, I think. We should also look into how quickly we can deprecate TLS 1.0 and SSL <= 3 usage. @@ -483,7 +483,7 @@ Author: Nick Mathewson technically slightly more difficult than xor-based tagging, and it could be useful to boost our defense-in-depth a little bit, just in case other active end-to-end attacks turn out to be harder than we'd - thought.) + thought. 6.1. Option 1: Use AES-CTR in a less scary mode @@ -762,3 +762,4 @@ ACKS Lots of the good ideas and concerns here are due to Robert Ransom. Michael Stone helped some with "relay option 4" above. +

1 0

[torspec/master] Merge branch 'newcrypto'
by nickm＠torproject.org 01 Nov '11

01 Nov '11

commit 7a8bcfeed2c59933b42a75da4662936fa5114e15 Merge: 075e215 2fcc5ca Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Oct 31 21:24:50 2011 -0400 Merge branch 'newcrypto' proposals/ideas/xxx-new-crypto-sketch.txt | 766 +++++++++++++++++++++++++++++ proposals/ideas/xxx-ntor-handshake.txt | 17 +- 2 files changed, 779 insertions(+), 4 deletions(-)

1 0

[torspec/master] Note that ntor changes need to be verified
by nickm＠torproject.org 01 Nov '11

01 Nov '11

commit ef5b059e31c7d574115cd4d21e9a813574ab4799 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Oct 31 21:23:05 2011 -0400 Note that ntor changes need to be verified --- proposals/ideas/xxx-ntor-handshake.txt | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/proposals/ideas/xxx-ntor-handshake.txt b/proposals/ideas/xxx-ntor-handshake.txt index 1f988fc..081d6af 100644 --- a/proposals/ideas/xxx-ntor-handshake.txt +++ b/proposals/ideas/xxx-ntor-handshake.txt @@ -71,7 +71,8 @@ Protocol: PARMS: -- PARAMSLEN byets (The "PARAMS" component is used to encode any additional authenticated - information that's needed for establishing the right kind of circuit.) + information that's needed for establishing the right kind of circuit. + XXXXX nickm added it; we need to ask if it's safe!!!!) The server generates a keypair of y,Y = KEYGEN(), and computes

1 0

[torspec/master] read sec 6 also
by nickm＠torproject.org 01 Nov '11

01 Nov '11

commit 2fcc5ca4cba8b80fa6ed8770a3c5533690c3c6f9 Author: Roger Dingledine <arma(a)torproject.org> Date: Mon Oct 31 21:18:07 2011 -0400 read sec 6 also did not check pseudocode for well-formedness --- proposals/ideas/xxx-new-crypto-sketch.txt | 11 ++++++----- 1 files changed, 6 insertions(+), 5 deletions(-) diff --git a/proposals/ideas/xxx-new-crypto-sketch.txt b/proposals/ideas/xxx-new-crypto-sketch.txt index 9fbdbd2..ab2e987 100644 --- a/proposals/ideas/xxx-new-crypto-sketch.txt +++ b/proposals/ideas/xxx-new-crypto-sketch.txt @@ -645,8 +645,9 @@ Author: Nick Mathewson Otherwise add the entire cell to cells_i, and decrypt it, MAC included, with the stream keyed with Kb[i], IVb[i]. - If no node sent this cell: it's junk and somebody is probably - messing with us! Destroy the circuit. + If no node sent this cell: it's junk and somebody is probably + messing with us! Destroy the circuit. + When the client *sends* a cell outbound to node N: @@ -664,10 +665,10 @@ Author: Nick Mathewson CELL_DATA_LEN-5-MACLEN-len(Data) bytes] Let PAD[i] = the next MACBYTESf[i] bytes from the PRNG keyed - with SEEDf[i], for i in 1...N. + with SEEDf[i], for i in 1...N Let STREAM[i] = the next CELL_DATA_LEN bytes of - the stream keyed by Kf[i],IV[i], for i in 1...N. + the stream keyed by Kf[i],IV[i], for i in 1...N Let PADSEEN[1] == "" @@ -753,7 +754,7 @@ Author: Nick Mathewson "recognized" field. I note in passing that we need at most 9 bits for the length - field, and most 6 bits for the command field, yet we're using a + field, and at most 6 bits for the command field, yet we're using a total of 3 bytes for those 15 bits. That's an opportunity to save another byte.

1 0

[torbrowser/maint-2.2] update build-firefox target on windows to have the right patching script name
by erinn＠torproject.org 01 Nov '11

01 Nov '11

commit afc8f006615e94688bf4955628d72c05017d8b83 Author: Erinn Clark <erinn(a)torproject.org> Date: Tue Nov 1 00:32:21 2011 +0000 update build-firefox target on windows to have the right patching script name --- build-scripts/windows.mk | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/build-scripts/windows.mk b/build-scripts/windows.mk index 3e44b13..a0c3541 100644 --- a/build-scripts/windows.mk +++ b/build-scripts/windows.mk @@ -111,9 +111,9 @@ build-tor: FIREFOX_DIR=/c/mozilla-build/mozilla-release build-firefox: cp ../src/current-patches/firefox/* $(FIREFOX_DIR) - cp patch-firefox-src.sh $(FIREFOX_DIR) + cp patch-any-src.sh $(FIREFOX_DIR) cp $(CONFIG_SRC)/dot_mozconfig $(FIREFOX_DIR)/mozconfig - cd $(FIREFOX_DIR) && ./patch-firefox-src.sh + cd $(FIREFOX_DIR) && ./patch-any-src.sh # cmd /c C:/mozilla-build/start-msvc9 build-all-binaries: build-zlib build-openssl build-vidalia build-libevent build-tor

1 0

[torbrowser/master] update build-firefox target on windows to have the right patching script name
by erinn＠torproject.org 01 Nov '11

01 Nov '11

1 0

[torbrowser/maint-2.3] update build-firefox target on windows to have the right patching script name
by erinn＠torproject.org 01 Nov '11

01 Nov '11

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits November 2011