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

[translation/tor-messenger-ircproperties] Update translations for tor-messenger-ircproperties
by translation＠torproject.org 09 May '16

09 May '16

commit 89fc7a1d1bbdc9f9a2ab1954ebd067950426e0e6 Author: Translation commit bot <translation(a)torproject.org> Date: Mon May 9 06:16:31 2016 +0000 Update translations for tor-messenger-ircproperties --- el/irc.properties | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/el/irc.properties b/el/irc.properties index 37809d1..02a09d8 100644 --- a/el/irc.properties +++ b/el/irc.properties @@ -95,7 +95,7 @@ message.usermode=Mode %1$S for %2$S set by %3$S. # %1$S is the new channel mode and %2$S is who set the mode. message.channelmode=Channel mode %1$S set by %2$S. # %S is the user's mode. -message.yourmode=Your mode is %S. +message.yourmode=Η κατάστασή σας είναι %S. # Could not change the nickname. %S is the user's nick. message.nick.fail=Δεν μπορείτε να χρησιμοποιήσετε το ψευδώνυμο που θέλετε. Το ψευδώνυμό σας παραμένει %S. # The parameter is the message.parted.reason, if a part message is given. @@ -163,7 +163,7 @@ error.unavailable=%S προσωρινά δεν είναι διαθέσιμο error.channelBanned=You have been banned from %S. error.cannotSendToChannel=Δεν μπορείτε να στείλετε μήνυμα σε %S. error.channelFull=The channel %S is full. -error.inviteOnly=You must be invited to join %S. +error.inviteOnly=Πρέπει να προσκληθείτε για να συμμετάσχετε %S. error.nonUniqueTarget=%S is not a unique user@host or shortname or you have tried to join too many channels at once. error.notChannelOp=You are not a channel operator on %S. error.notChannelOwner=You are not a channel owner of %S.

1 0

[torspec/master] questions from when i was reading through it
by arma＠torproject.org 09 May '16

09 May '16

commit 0cfe03bb4890463d12c9979b1c50eac38236ead4 Author: Roger Dingledine <arma(a)torproject.org> Date: Sun May 8 21:21:24 2016 -0400 questions from when i was reading through it --- proposals/224-rend-spec-ng.txt | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 8bcd9f8..989c741 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -152,6 +152,7 @@ Status: Draft RSA1024, DH1024, AES128, and SHA1, as discussed in rend-spec.txt. Except as noted, all RSA keys MUST have exponent values of 65537. + [XXX -- is this last sentence new? I think we don't require it now. -RD] As in [proposal 220], all signatures are generated not over strings themselves, but over those strings prefixed with a distinguishing @@ -390,6 +391,9 @@ Status: Draft the client must know the introduction point and know the service's per-introduction-point authentication key from the hidden service descriptor. + [XXX what exactly does the intro point check then? Seems like the + intro point should be able to send a cell down the circuit to the + service, even if the service doesn't like the cell. -RD] The final level of access control happens at the server itself, which may decide to respond or not respond to the client's request @@ -682,6 +686,7 @@ Status: Draft hsdir_spread_accept = an integer in range [1,128] with default value 12. +[XXX I think I obsoleted this spread_accept notion? -RD] To determine where a given hidden service descriptor will be stored in a given period, after the blinded public key for that period is @@ -706,6 +711,7 @@ Status: Draft where shared_random_value is the shared value generated by the authorities in section [PUB-SHAREDRANDOM], and node_identity_digest is a SHA1 digest of the node's RSA public key as described in tor-spec.txt. +[XXX Maybe include a sentence about why SHA1 isn't scary here? -RD] Finally, for replicanum in 1...hsdir_n_replicas, the hidden service host uploads descriptors to the first hsdir_spread_store nodes whose @@ -833,6 +839,9 @@ Status: Draft as the SRV for time period TIME_PERIOD_NUM. +[Ok, this says clients. What do servers do? The same, right? Or should + we let services choose to drop off in the disaster case? -RD] + 2.3.2. Hidden services and changing shared random values It's theoretically possible that the consensus shared random values will @@ -896,7 +905,6 @@ Status: Draft the hidden service host does not need to have its private blinded key online. - 2.5. Hidden service descriptors: encryption format [ENCRYPTED-DATA] The encrypted part of the hidden service descriptor is encrypted and @@ -951,6 +959,8 @@ Status: Draft 'ed25519'. See [INTRO-AUTH] below. At least once: +[XXX Why not permit descriptors that list 0 intro points? I think + they're permitted in the legacy rend design. -RD] "introduction-point" SP link-specifiers NL @@ -1083,6 +1093,11 @@ Status: Draft [TODO: The above will work fine with what we do today, but it will do quite badly if we ever freak out and want to go back to RSA2048 or bigger. Do we care?] + [Do we lose much by making AUTH_KEY_LEN and SIGLEN 2 bytes each? Or, + even crazier, do we lose much by making those two variable sizes, + defined by whichever value of AUTH_KEY_TYPE you pick? I guess we + don't know how big it is if we don't recognize the key type, but we + are already planning to refuse the intro request then. -RD] 3.1.2. Registering an introduction point on a legacy Tor node [LEGACY_EST_INTRO] @@ -1090,6 +1105,8 @@ Status: Draft cell, first documented in rend-spec.txt. New hidden service hosts must use this format when establishing introduction points at older Tor nodes that do not support the format above in [EST_INTRO]. + [If we roll out intro-point-side support early enough, then service + hosts can simply avoid making intro points to old relays? -RD] In this older protocol, an ESTABLISH_INTRO cell contains: @@ -1127,6 +1144,10 @@ Status: Draft EXT_FIELD_LEN [1 byte] EXT_FIELD [EXT_FIELD_LEN bytes] + [Worth mentioning that old-school Tor relays send back an empty + payload here? Or, even better, not mentioning it if we simplify + 3.1.2 to "don't do that". -RD] + 3.2. Sending an INTRODUCE1 cell to the introduction point. [SEND_INTRO1] In order to participate in the introduction protocol, a client must @@ -1164,7 +1185,7 @@ Status: Draft [TODO: Should we have a field to determine the type of ENCRYPTED, or should we instead assume that there is exactly one encryption key per - encryption method? The latter is probably safer.] + encryption method? The latter is probably safer.] [Agree -RD] Upon receiving an INTRODUCE1 cell, the introduction point checks whether AUTH_KEY and ENC_KEY match a configured introduction

1 0

[torspec/master] substantive changes that i hope aren't controversial
by arma＠torproject.org 09 May '16

09 May '16

commit 80d95af2c9e1e44d512c7247d8940cdf93d57651 Author: Roger Dingledine <arma(a)torproject.org> Date: Sun May 8 21:01:44 2016 -0400 substantive changes that i hope aren't controversial --- proposals/224-rend-spec-ng.txt | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index d732b27..8bcd9f8 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -205,20 +205,20 @@ Status: Draft 35 -- RELAY_COMMAND_INTRODUCE2 - Sent from client to introduction point; requests + Sent from introduction point to hidden service host; requests introduction. Same format as INTRODUCE1. Discussed in [FMT_INTRO1] and [PROCESS_INTRO2] 36 -- RELAY_COMMAND_RENDEZVOUS1 - Sent from introduction point to rendezvous point; - attempts to join introduction point's circuit to + Sent from hidden service host to rendezvous point; + attempts to join host's circuit to client's circuit. Discussed in [JOIN_REND] 37 -- RELAY_COMMAND_RENDEZVOUS2 - Sent from introduction point to rendezvous point; - reports join of introduction point's circuit to + Sent from rendezvous point to client; + reports join of host's circuit to client's circuit. Discussed in [JOIN_REND] 38 -- RELAY_COMMAND_INTRO_ESTABLISHED @@ -711,8 +711,8 @@ Status: Draft host uploads descriptors to the first hsdir_spread_store nodes whose indices immediately follow hs_index(replicanum). If any of those nodes have already been selected for a lower-numbered replica of the - service, any nodes already chosen are disregarded when choosing a - replica's hsdir_spread_store nodes. + service, any nodes already chosen are disregarded (i.e. skipped over) + when choosing a replica's hsdir_spread_store nodes. [ XX/teor - because the positions don't match the key, this might leak the fact that nodes from other replicas are nearby to a HSDir. @@ -1112,6 +1112,8 @@ Status: Draft authentication keys. Newer hidden services MAY use RSA keys up 1904 bits. Any more than that will not fit in a RELAY cell payload. +[There is no 3.1.3?] + 3.1.4. Acknowledging establishment of introduction point [INTRO_ESTABLISHED] After setting up an introduction circuit, the introduction point reports its

1 0

[torspec/master] easy typo/grammar/etc fixes on prop#224
by arma＠torproject.org 09 May '16

09 May '16

commit 13bb5f4a9460c3a7e465c2f384f7dc8baec69b60 Author: Roger Dingledine <arma(a)torproject.org> Date: Sun May 8 20:40:24 2016 -0400 easy typo/grammar/etc fixes on prop#224 --- proposals/224-rend-spec-ng.txt | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index bad3a47..d732b27 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -80,8 +80,8 @@ Status: Draft 1. A sequence of two-digit hexadecimal values in square brackets, as in [AB AD 1D EA]. - 2. A string of characters enclosed in quotes, as in "Hello". These - characters in these string are encoded in their ascii + 2. A string of characters enclosed in quotes, as in "Hello". The + characters in these strings are encoded in their ascii representations; strings are NOT nul-terminated unless explicitly described as NUL terminated. @@ -118,7 +118,7 @@ Status: Draft * A public key agreement system "PK", providing PK_KEYGEN()->seckey, pubkey; PK_VALID(pubkey) -> {"OK", "BAD"}; - and PK_HANDHAKE(seckey, pubkey)->output; where secret keys are + and PK_HANDSHAKE(seckey, pubkey)->output; where secret keys are of length PK_SECKEY_LEN bytes, public keys are of length PK_PUBKEY_LEN bytes, and the handshake produces outputs of length PK_OUTPUT_LEN bytes. @@ -409,8 +409,8 @@ Status: Draft collaboratively generated random value. (See section 2.3 for a description of how to incorporate this value into the voting practice; generating the value is described in other proposals, - including [TODO: add a reference]) That value, combined with hidden service - directories' public identity keys, determines each HSDirs' position + including [SHAREDRANDOM-REFS].) That value, combined with hidden service + directories' public identity keys, determines each HSDir's position in the hash ring for descriptors made in that period. Each hidden service's descriptors are placed into the ring in @@ -476,7 +476,7 @@ Status: Draft To avoid replays of an introduction request by an introduction point, a hidden service host must never accept the same request - twice. Earlier versions of the hidden service design used a + twice. Earlier versions of the hidden service design used an authenticated timestamp here, but including a view of the current time can create a problematic fingerprint. (See proposal 222 for more discussion.) @@ -497,7 +497,7 @@ Status: Draft address according to [NAMING]. Blinded signing key -- A keypair derived from the identity key, - used to sign descriptor signing keys. Changes periodically for + used to sign descriptor signing keys. It changes periodically for each service. Clients who know a 'credential' consisting of the service's public identity key and an optional secret can derive the public blinded identity key for a service. This key is used @@ -809,7 +809,7 @@ Status: Draft 2.3. Publishing shared random values [PUB-SHAREDRANDOM] Our design for limiting the predictability of HSDir upload locations - relies on a shared random value that isn't predictable in advance or + relies on a shared random value (SRV) that isn't predictable in advance or too influenceable by an attacker. The authorities must run a protocol to generate such a value at least once per hsdir period. Here we describe how they publish these values; the procedure they use to @@ -926,7 +926,7 @@ Status: Draft Before encryption, the plaintext must be padded to a multiple of ??? bytes with NUL bytes. The plaintext must not be longer than ??? bytes. [TODO: how much? Should this be a parameter? What values in - practice is needed to hide how many intro points we have, and how + practice are needed to hide how many intro points we have, and how many might be legacy ones? Note that Single Onion Services add extend intro points as well. ] @@ -1005,7 +1005,7 @@ Status: Draft First, a hidden service host builds an anonymous circuit to a Tor node and registers that circuit as an introduction point. - [Between these steps, the hidden service publishes its + [After 'First' and before 'Second', the hidden service publishes its introduction points and associated keys, and the client fetches them as described in section [HSDIR] above.] @@ -1021,7 +1021,7 @@ Status: Draft 3.1.1. Extensible ESTABLISH_INTRO protocol. [EST_INTRO] When a hidden service is establishing a new introduction point, it - sends a ESTABLISH_INTRO cell with the following contents: + sends an ESTABLISH_INTRO cell with the following contents: AUTH_KEY_TYPE [1 byte] AUTH_KEY_LEN [1 byte] @@ -1036,7 +1036,7 @@ Status: Draft SIG [SIGLEN bytes] The AUTH_KEY_TYPE field indicates the type of the introduction point - authentication key and the type of the MAC to use in for + authentication key and the type of the MAC to use in HANDSHAKE_AUTH. Recognized types are: [00, 01] -- Reserved for legacy introduction cells; see @@ -1499,7 +1499,7 @@ Status: Draft use on an existing circuit, the rendezvous point should reject it and destroy the circuit. - Upon receiving a ESTABLISH_RENDEZVOUS cell, the rendezvous point + Upon receiving an ESTABLISH_RENDEZVOUS cell, the rendezvous point associates the cookie with the circuit on which it was sent. It replies to the client with an empty RENDEZVOUS_ESTABLISHED cell to indicate success. [TODO: make this extensible] @@ -1767,3 +1767,4 @@ Appendix E. Reserved numbers public key. (Section 2.5) [XXXX list more] +

1 0

[torspec/master] prop224: Specify sane use of PRNG once and for all.
by asn＠torproject.org 08 May '16

08 May '16

commit 50b1937b2f59d29f5d31e8eadf9f991b821676e5 Author: George Kadianakis <desnacked(a)riseup.net> Date: Wed Apr 13 14:58:25 2016 +0300 prop224: Specify sane use of PRNG once and for all. Tor is doing the right thing anyway, and specs would look terrible if we have to refer to [RANDOM-REFS] everytime we use random bytes. --- proposals/224-rend-spec-ng.txt | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index a47be65..6526e05 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -97,6 +97,11 @@ Status: Draft This specification uses the following cryptographic building blocks: + * A pseudorandom number generator backed by a strong entropy source. + The output of the PRNG should always be hashed before being posted on + the network to avoid leaking raw PRNG bytes to the network + (see [PRNG-REFS]). + * A stream cipher STREAM(iv, k) where iv is a nonce of length S_IV_LEN bytes and k is a key of length S_KEY_LEN bytes. @@ -1487,9 +1492,7 @@ Status: Draft Pubkey [32 bytes] Signature [64 bytes] - Nonce is a random value. (Noncen should be derived from hashed PRNG - output, so that we don't leak the raw bytes returned by a PRNG to the - network. See [RANDOM-REFS].) Pubkey is the public key that will be used + Nonce is a random value. Pubkey is the public key that will be used to authenticate. [TODO: should this be an identifier for the public key instead?] Signature is the signature, using Ed25519, of: @@ -1532,9 +1535,7 @@ Status: Draft by the client. The client SHOULD choose a new rendezvous cookie for each new connection attempt. If the rendezvous cookie is already in use on an existing circuit, the rendezvous point should reject it and - destroy the circuit. RENDEZVOUS_COOKIE should be derived using hashed - PRNG output, so that we don't leak the raw bytes returned by a PRNG - to the network. See [RANDOM-REFS]. + destroy the circuit. Upon receiving a ESTABLISH_RENDEZVOUS cell, the rendezvous point associates the cookie with the circuit on which it was sent. It @@ -1673,7 +1674,7 @@ References: J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang. http://cr.yp.to/papers.html#ed25519 -[RANDOM-REFS]: +[PRNG-REFS]: http://projectbullrun.org/dual-ec/ext-rand.html https://lists.torproject.org/pipermail/tor-dev/2015-November/009954.html

1 0

[torspec/master] Revert "prop224: randomise revision-counter to avoid information leaks"
by asn＠torproject.org 08 May '16

08 May '16

commit 3eb33f626dae5d2c7002b0adc8dd4676a3d20779 Author: George Kadianakis <desnacked(a)riseup.net> Date: Tue Apr 12 15:14:15 2016 +0300 Revert "prop224: randomise revision-counter to avoid information leaks" This reverts commit 01119bf1291a40aa309dfb7d76edf790133f05b9. --- proposals/224-rend-spec-ng.txt | 54 ------------------------------------------ 1 file changed, 54 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 6526e05..384b941 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -855,60 +855,6 @@ Status: Draft prevents an attacker from replacing a newer descriptor signed by a given key with a copy of an older version.) - The revision-counter should be updated with each upload, regardless - of whether the descriptor has changed. This avoids leaking whether - the descriptor has changed. - - [ XX/teor - is the extra load on the HSDirs worth it? ] - - Services should randomise the start and increment values of - revision-counter for each replica, to avoid leaking service - stability, and avoid linking descriptor replicas via - revision-counter values. - - Say that our goal is for services to start the period at a - random value near zero, and end it at a random value that does - not exceed 2 ^ 32 (while the length of revision-counter isn't - specified, it's included in hashes as INT_4(revision-counter)). We'd - like the revision-counters of all services to increment at - approximately the same randomised rate, regardless of RendPostPeriod. - - revision-counter could be initialised and incremented using: - two-periods-time = (2 * 24 * 60 * 60) - elapsed-ratio = elapsed-since-last-post / two-periods-time - max-increment = 2^32 * elapsed-ratio - where elapsed-since-last-post is the time elapsed since descriptors - were last uploaded for the current blinded key. - - The first upload for a blinded key for the next period sets - elapsed-since-last-post equal to the time since the current period - started. Assuming the keys have just become valid, this is: - elapsed-since-period-start = key-validity-start - period-start - where key-validity-start is when the keys became valid, and - period-start is when the current period started. - - Then, each initialisation and increment is: - revision-counter += random(1, max-increment) - - (The random() function should be careful not to leak the raw bytes - returned by the PRNG to the network. See [RANDOM-REFS].) - - This scheme increments revision-counter at a maximum rate of: - 2 ^ 32 / (2 * 24 * 60 * 60) = 24855 per second - with an expected average value of 12428 per second. This appears - sufficient to blur the exact number of revisions. - - This scheme could leak the approximate time at which the descriptor - was uploaded, and the approximate RendPostPeriod. These are easily - guessed from the current time, and by checking when descriptors - arrive at the HSDirs. Tracking unique revision-counter values would - also reveal how many times a descriptor has been uploaded (without - decrypting "encrypted"). - - Regardless of the method used to generate the revision counter, - all that HSDirs need to do is verify that new descriptors for a key - have a higher counter than the current descriptor. - "encrypted" NL encrypted-string [Exactly once.]

1 0

[torspec/master] Revert "prop224: avoid replicas with the same blinded key"
by asn＠torproject.org 08 May '16

08 May '16

commit f4026eec6858ff9e085b6c46224d7b0367d93cff Author: George Kadianakis <desnacked(a)riseup.net> Date: Tue Apr 12 15:14:07 2016 +0300 Revert "prop224: avoid replicas with the same blinded key" This reverts commit 8df8c0584392240aa8fecbcd2164a4489be7ae1a. --- proposals/224-rend-spec-ng.txt | 99 +++++++++++++++--------------------------- 1 file changed, 34 insertions(+), 65 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 384b941..237ffdd 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -375,10 +375,9 @@ Status: Draft In order to download a descriptor, clients must know which blinded signing key was used to sign it. (See the next section for more info on key blinding.) This blinded signing key is derived from the - service's public key, the descriptor replica number, and, optionally, - an additional secret that is not part of the hidden service's onion - address. The public key, replica number, and this secret together - constitute the service's "credential". + service's public key and, optionally, an additional secret that is + not part of the hidden service's onion address. The public key and + this secret together constitute the service's "credential". When the secret is in use, the hidden service gains protections equivalent to the "stealth mode" in previous designs. @@ -418,19 +417,19 @@ Status: Draft positions based on the key that was used to sign them. Note that hidden service descriptors are not signed with the services' public keys directly. Instead, we use a key-blinding system [KEYBLIND] to - create new keys-of-the-day for the descriptor replicas for each - hidden service. Any client that knows the hidden service's credential - can derive these blinded signing keys for a given period. It should be - impossible to derive the blinded signing keys lacking that credential. + create a new key-of-the-day for each hidden service. Any client that + knows the hidden service's credential can derive these blinded + signing keys for a given period. It should be impossible to derive + the blinded signing key lacking that credential. The body of each descriptor is also encrypted with a key derived from the credential. To avoid a "thundering herd" problem where every service generates and uploads a new descriptor at the start of each period, each - descriptor replica comes online at a time during the period that - depends on its blinded signing key. The keys for the last period remain - valid until the new keys come online. + descriptor comes online at a time during the period that depends on + its blinded signing key. The keys for the last period remain valid + until the new keys come online. 1.5. In more detail: Scaling to multiple hosts @@ -468,9 +467,9 @@ Status: Draft in advance). [TODO: Define revocation mechanism?] - It's important to not send the private part of a blinded signing + It's important to not send the private part of the blinded signing key to the Hidden Service since an attacker can derive from it the - secret master identity key. A secret blinded signing key should + secret master identity key. The secret blinded signing key should only be used to create credentials for the descriptor signing keys. 1.8. In more detail: Encryption Keys And Replay Resistance @@ -503,16 +502,14 @@ Status: Draft service's public identity key and an optional secret can derive the public blinded identity key for a service. This key is used as an index in the DHT-like structure of the directory system - (see [SUBCRED]). Each descriptor replica may use a different - blinded signing key, based on its replicanum. + (see [SUBCRED]). Descriptor signing key -- A key used to sign hidden service descriptors. This is signed by blinded signing keys. Unlike blinded signing keys and master identity keys, the secret part of this key must be stored online by hidden service hosts. The public part of this key is included in the unencrypted section - of HS descriptors (see [DESC-OUTER]). Each descriptor replica must - use a different descriptor signing key. + of HS descriptors (see [DESC-OUTER]). Introduction point authentication key -- A short-term signing keypair used to identify a hidden service to a given @@ -533,8 +530,7 @@ Status: Draft Descriptor encryption keys -- A symmetric encryption key used to encrypt the body of hidden service descriptors. Derived from the - current period, the descriptor replica, the descriptor revision, - and the hidden service credential. + current period and the hidden service credential. Public/private keypairs defined elsewhere: @@ -565,8 +561,6 @@ Status: Draft periods), a hidden service host uses a different blinded private key to sign its directory information, and clients use a different blinded public key as the index for fetching that information. - Each descriptor replica for each service may use different blinded - keys. For a candidate for a key derivation method, see Appendix [KEYBLIND]. @@ -583,13 +577,7 @@ Status: Draft The subcredential for a period is derived as: H("subcredential" | credential | - blinded-public-key(replica-keynum)). - - Where replica-keynum = replicanum % hsdir_num_replica_keys. - (This ensures that each replica has a blinded key, even if - hsdir_num_replicas is higher than hsdir_num_replica_keys. This ensures - hidden services can't predict future values of hsdir_num_replicas at - key blinding time.) + blinded-public-key). 2.2. Locating, uploading, and downloading hidden service descriptors [HASHRING] @@ -597,9 +585,7 @@ Status: Draft To avoid attacks where a hidden service's descriptor is easily targeted for censorship, we store them at different directories over time, and use shared random values to prevent those directories from - being predictable far in advance. Each descriptor replica may use a - different blinded signing key, which prevents directories in one - replica locating directories in other replica(s). + being predictable far in advance. Which Tor servers hosts a hidden service depends on: @@ -660,8 +646,7 @@ Status: Draft The time at which a key from the next interval becomes valid is determined by taking the first two bytes of - OFFSET = H("interval-offset" | blinded-public-key(replica-keynum) | - INT_8(Next_Period_Num)) + OFFSET = H("interval-offset" | Key | INT_8(Next_Period_Num)) as a big-endian integer, dividing by 65536, and treating that as a fraction of the overlap interval. @@ -682,21 +667,11 @@ Status: Draft 2.2.3. Where to publish a service descriptor - The following constant controls how many blinded keys are created - per period for the different descriptor replicas: - - hsdir_num_replica_keys = an integer constant 2. - - (Since blinded keys can be generated ahead of time, a service can not - know the value of hsdir_n_replicas at the time the blinded keys will - be used. If hsdir_n_replicas is greater than hsdir_num_replica_keys, - some keys will be used for multiple replicas.) - The following consensus parameters control where a hidden service descriptor is stored; hsdir_n_replicas = an integer in range [1,16] - with default value hsdir_num_replica_keys. + with default value 2. hsdir_spread_fetch = an integer in range [1,128] with default value 3. @@ -708,12 +683,12 @@ Status: Draft with default value 12. To determine where a given hidden service descriptor will be stored - in a given period, after the blinded public key for that period and - replica is derived, the uploading or downloading party calculates: + in a given period, after the blinded public key for that period is + derived, the uploading or downloading party calculate for replicanum in 1...hsdir_n_replicas: hs_index(replicanum) = H("store-at-idx" | - blinded_public_key(replica-keynum) | + blinded_public_key | INT_8(replicanum) | INT_8(periodnum) ) @@ -721,8 +696,7 @@ Status: Draft periodnum is defined in section TIME-PERIODS. where n_replicas is determined by the consensus parameter - "hsdir_n_replicas", and replica-keynum is replicanum % - hsdir_num_replica_keys. + "hsdir_n_replicas". Then, for each node listed in the current consensus with the HSDir3 flag, we compute a directory index for that node as: @@ -772,7 +746,7 @@ Status: Draft /tor/rendezvous3/publish relative to the hidden service directory's root, and downloaded with an HTTP GET request for the URL /tor/rendezvous3/<z> where z is a base-64 encoding of the hidden - service's blinded public key for the replica. + service's blinded public key. [TODO: raw base64 is not super-nice for URLs, since it can have slashes. We already use it for microdescriptor URLs, though. Do we @@ -838,9 +812,8 @@ Status: Draft The 'certificate' field contains a certificate in the format from proposal 220, with the short-term ed25519 descriptor-signing key - for the replica, signed by the blinded public key for the replica. - It must contain a ed25519-signing-key extension containing the - blinded public key for the replica. + signed by the blinded public key. It must contain a + ed25519-signing-key extension containing the blinded public key. "revision-counter" SP Integer NL @@ -870,7 +843,7 @@ Status: Draft A signature of all previous fields, using the signing key in the hs-descriptor line. We use a separate key for signing, so that the hidden service host does not need to have its private blinded - keys online. + key online. 2.5. Hidden service descriptors: encryption format [ENCRYPTED-DATA] @@ -888,9 +861,8 @@ Status: Draft [ XX/teor - is the extra load on the HSDirs worth it? ] - secret_input = blinded_public_key(replica-keynum) | - subcredential | INT_4(revision_counter) - keys = KDF(secret_input | salt | "hsdir-encrypted-data", + secret_input = blinded_public_key | subcredential | INT_4(revision_counter) + keys = KDF(secret_input, salt, "hsdir-encrypted-data", S_KEY_LEN + S_IV_LEN + MAC_KEY_LEN) SECRET_KEY = first S_KEY_LEN bytes of keys @@ -949,10 +921,9 @@ Status: Draft Base-64 encoded introduction point authentication key that was used to establish introduction point circuit, cross-certifying - the blinded public key for the replica. This uses the - certificate format of proposal 220 with type [09]. The - signing-key extension is mandatory here to tell you what the - public key is. + the blinded public key. This uses the certificate format of + proposal 220 with type [09]. The signing-key extension is + mandatory here to tell you what the public key is. "enc-key" SP "ntor" SP key NL @@ -1686,10 +1657,8 @@ Appendix A. Signature scheme with key blinding [KEYBLIND] possible alternatives. Also, see [KEYBLIND-PROOF] for a security proof of this scheme. - (To use this with Tor, set N(replica-keynum) = "key-blind" | - INT_8(period-number) | INT_8(Start of period in seconds since epoch) | - INT_1(replica-keynum), where replica-keynum is from 1 to - hsdir_num_replica_keys.) + (To use this with Tor, set N = "key-blind" | INT_8(period-number) | + INT_8(Start of period in seconds since epoch).) Appendix B. Selecting nodes [PICKNODES]

1 0

[torspec/master] prop224: Clarify when we need fresh salt for descriptors.
by asn＠torproject.org 08 May '16

08 May '16

commit 0567494b3f1cd51cc6f5404fc8d84ec5f4434bc8 Author: George Kadianakis <desnacked(a)riseup.net> Date: Tue Apr 12 15:18:25 2016 +0300 prop224: Clarify when we need fresh salt for descriptors. --- proposals/224-rend-spec-ng.txt | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index 237ffdd..a3fb40b 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -851,15 +851,9 @@ Status: Draft The encrypted part of the hidden service descriptor is encrypted and authenticated with symmetric keys generated as follows: - SALT = 16 bytes from H(random), different for each post to each replica, - even if the content of the descriptor hasn't changed. - (This avoids leaking service stability, and linking replicas - via encrypted data comparison.) - - (We hash salt so that we don't leak the raw bytes returned by a PRNG - to the network. See [RANDOM-REFS].) - - [ XX/teor - is the extra load on the HSDirs worth it? ] + SALT = 16 bytes from H(random), changes each time we rebuld the + descriptor even if the content of the descriptor hasn't changed. + (So that we don't leak whether the intro point list etc. changed) secret_input = blinded_public_key | subcredential | INT_4(revision_counter) keys = KDF(secret_input, salt, "hsdir-encrypted-data",

1 0

[torspec/master] prop224: Time periods now start at 12:00UTC and last 24 hours.
by asn＠torproject.org 08 May '16

08 May '16

commit 14dd07742afef46baf5b597b09a3d7e431a55f7a Author: George Kadianakis <desnacked(a)riseup.net> Date: Wed Apr 13 14:37:21 2016 +0300 prop224: Time periods now start at 12:00UTC and last 24 hours. --- proposals/224-rend-spec-ng.txt | 31 +++++++++++++++++++------------ 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index a3fb40b..e270f1d 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -609,18 +609,25 @@ Status: Draft The length of a "time period" is controlled by the consensus parameter 'hsdir-interval', and is a number of minutes between 30 and - 14400 (10 days). The default time period length is 1500 (one day plus - one hour). - - Time periods start with the Unix epoch (Jan 1, 1970), and are - computed by taking the number of whole minutes since the epoch and - dividing by the time period. So if the current time is 2013-11-12 - 13:44:32 UTC, making the seconds since the epoch 1384281872, the - number of minutes since the epoch is 23071364. If the current time - period length is 1500 (the default), then the current time period - number is 15380. It began 15380*1500*60 seconds after the epoch at - 2013-11-11 20:00:00 UTC, and will end at (15380+1)*1500*60 seconds - after the epoch at 2013-11-12 21:00:00 UTC. + 14400 (10 days). The default time period length is 1440 (one day). + + Time periods start at the Unix epoch (Jan 1, 1970), and are computed by + taking the number of minutes since the epoch and dividing by the time + period. However, we want our time periods to start at 12:00UTC every day, so + we subtract a "rotation time offset" of 12*60 minutes from the number of + minutes since the epoch, before dividing by the time period (effectively + making "our" epoch start at Jan 1, 1970 12:00UTC). + + Example: If the current time is 2016-04-13 11:15:01 UTC, making the seconds + since the epoch 1460546101, and the number of minutes since the epoch + 24342435. We then subtract the "rotation time offset" of 12*60 minutes from + the minutes since the epoch, to get 24341715. If the current time period + length is 1440 minutes, by doing the division we see that we are currently + in time period number 16903. + + Specifically, time period #16903 began 16903*1440*60 + (12*60*60) seconds + after the epoch at 2016-04-12 12:00 UTC, and ended at (16904+1)*1500*60 + + (12*60*60) seconds after the epoch at 2016-04-13 12:00 UTC. 2.2.2. Overlapping time periods to avoid thundering herds [TIME-OVERLAP]

1 0

[torspec/master] prop224: Revisit how overlap periods work.
by asn＠torproject.org 08 May '16

08 May '16

commit 30aad19107646ddd8e4b44bb9cc2c3aece754c4f Author: George Kadianakis <desnacked(a)riseup.net> Date: Wed Apr 13 14:47:49 2016 +0300 prop224: Revisit how overlap periods work. Now overlap periods start 6 hours before the start of the next time period. --- proposals/224-rend-spec-ng.txt | 65 ++++++++++++++++++++++++------------------ 1 file changed, 37 insertions(+), 28 deletions(-) diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt index e270f1d..32d29de 100644 --- a/proposals/224-rend-spec-ng.txt +++ b/proposals/224-rend-spec-ng.txt @@ -639,38 +639,47 @@ Status: Draft the public key and the period. The time at which a key might first become valid is determined by the - consensus parameter "hsdir-overlap-begins", which is an integer in - range [1,100] with default value 80. This parameter denotes a - percentage of the interval for which no overlap occurs. So for the - default interval (1500 minutes) and default overlap-begins value - (80%), new keys do not become valid for the first 1200 minutes of the - interval. - - The new shared random value must be published *before* the start of - the next overlap interval by at least enough time to ensure that - clients all get it. [TODO: how much earlier?] + consensus parameter "hsdir-overlap-begins", which is an integer in range + [1,100] with default value 75. This parameter denotes a percentage of the + interval for which no overlap occurs. So for the default interval (24 + hours) and default overlap-begins value (75%), new keys do not become valid + for the first 18 hours of the interval. Instead, keys become valid at a + random point in the last 6 hours of the 24 hours interval. The time at which a key from the next interval becomes valid is determined by taking the first two bytes of - OFFSET = H("interval-offset" | Key | INT_8(Next_Period_Num)) + OFFSET = H("interval-offset" | KEY | INT_8(NEXT_PERIOD_NUM)) as a big-endian integer, dividing by 65536, and treating that as a fraction of the overlap interval. - For example, if the period is 1500 minutes long, and overlap interval - is 300 minutes long, and OFFSET begins with [90 50], then the next - key becomes valid at 1200 + 300 * (0x9050 / 65536) minutes, or - approximately 22 hours and 49 minutes after the beginning of the + For example, if the period is 1440 minutes long, and overlap interval + is 360 minutes long, and OFFSET begins with [90 50], then the next + key becomes valid at 1080 + 360 * (0x9050 / 65536) minutes, or + approximately 21 hours and 38 minutes after the beginning of the period. - Hidden service directories should accept descriptors at least [TODO: - how much?] minutes before they would become valid, and retain them - for at least [TODO: how much?] minutes after the end of the period. + The new shared random value MUST be published *before* the overlap interval + starts so that hidden services have access to the new shared random values + in time and can calculate the upcoming set of responsible HSDirs. In our + system, new shared random values get published at 00:00UTC every day, whereas + the overlap period starts at 06:00 and finishes at 12:00UTC. + + Here is an illustration of the system: + + +------------------------------------------------------------------+ + | | + | 00:00 12:00 00:00 12:00 00:00 12:00 | + | SRV#1 TP#1 SRV#2 TP#2 SRV#3 TP#3 | + | | + | $ |-----------$-----======|-----------$-----======| | + | overlap12 overlap23 | + | | + +------------------------------------------------------------------+ - When a client is looking for a service, it must calculate its key - both for the current and for the subsequent period, to decide whether - the next period's key is valid yet. + Legend: [TP#1 = Time Period #1] + [SRV#1 = Shared Random Value #1] 2.2.3. Where to publish a service descriptor @@ -737,14 +746,14 @@ Status: Draft Again, nodes from lower-numbered replicas are disregarded when choosing the spread for a replica. - An HSDir should reject a descriptor if that HSDir is not one of the - first hsdir_spread_accept HSDirs for that node. Since HSDirs can't - derive other replicas of a service, hsdir_spread_accept must be at - least hsdir_n_replicas * hsdir_spread_store. + HSDirs MUST retain hidden service descriptors for 33 hours before expiring + them. That's 24 hours for the time period duration, plus 6 hours for the + maximum overlap period span, plus 3 hours for the maximum acceptable client + clock skew. - [TODO: Incorporate the findings from proposal 143 here. But watch - out: proposal 143 did not analyze how much the set of nodes changes - over time, or how much client and host knowledge might diverge.] + Hidden services should keep their old introduction circuits open for at + least 3 hours after the descriptor expiration, so that clients with skewed + clocks can still visit them through outdated descriptors. 2.2.4. URLs for anonymous uploading and downloading

1 0