September 2015 - tor-commits - lists.torproject.org

[torspec/master] Add proposal for padding negotiation.
by isis＠torproject.org 25 Sep '15

25 Sep '15

commit d159f9a820a2793f402de89782446e0833795267 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Wed Sep 9 18:11:05 2015 -0700 Add proposal for padding negotiation. This is the version initially posted to tor-dev@lists. --- proposals/xxx-padding-negotiation.txt | 392 +++++++++++++++++++++++++++++++++ 1 file changed, 392 insertions(+) diff --git a/proposals/xxx-padding-negotiation.txt b/proposals/xxx-padding-negotiation.txt new file mode 100644 index 0000000..66d8991 --- /dev/null +++ b/proposals/xxx-padding-negotiation.txt @@ -0,0 +1,392 @@ +Filename: xxx-padding-negotiation.txt +Title: Padding Negotiation +Authors: Mike Perry +Created: 01 September 2015 +Status: Draft + + +0. Overview + +This proposal aims to describe mechanisms for requesting various types +of padding from relays. + +These padding primitives are general enough to use to defend against +both website traffic fingerprinting as well as hidden service circuit +setup fingerprinting. + + +1. Motivation + +Tor already supports both link-level padding via (CELL_PADDING cell +types), as well as circuit-level padding (via RELAY_COMMAND_DROP relay +cells). + +Unfortunately, there is no way for clients to request padding from +relays, or request that relays not send them padding to conserve +bandwidth. This proposal aims to create a mechanism for clients to do +both of these. + + +2. Link-level padding + +Padding is most urgently needed to defend against a malicious or +compromised guard node. However, link-level padding is still useful to +defend against an adversary that can merely observe a Guard node +externally. Right now, the only case where link-level padding is known +to defend against any realistic attacker is for low-resolution +netflow-based attacks. + +In that scenario, the primary mechanism we need is a way for mobile +clients to tell their Guards to stop padding, or to pad less often. The +following Trunnel payloads should cover the needed parameters: + + const CELL_PADDING_COMMAND_STOP = 1; + const CELL_PADDING_COMMAND_START = 2; + + /* This command tells the relay to stop sending any periodic + CELL_PADDING cells. */ + struct cell_padding_stop { + u8 command IN [CELL_PADDING_COMMAND_STOP]; + }; + + /* This command tells the relay to alter its min and max timeout + range values, and if needed, send + struct cell_padding_start { + u8 command IN [CELL_PADDING_COMMAND_START]; + + /* Min must not be lower than the current consensus parameter + nf_ito_low. */ + u16 ito_low_ms; + + /* Max must not be lower than ito_low_ms */ + u16 ito_high_ms; + }; + +If more scenarios are discovered, future command numbers could be used +to include the end-to-end padding command payloads below, or other +defense parameterizations. + + +3. End-to-end circuit padding + +For end-to-end padding, we need two types of additional features: the +ability to schedule additional incoming cells at one or more fixed +points in the future, and the ability to schedule a statistical +distribution of arbitrary padding to overlay on top of non-padding +traffic (aka "Adaptive Padding"). + +In both cases, these messages will be sent from clients to middle nodes +using "leaky pipe" property of the 'recognized' field of RELAY cells, +allowing padding to originate from middle nodes on a circuit in a way +that is not detectable from the Guard node. + +3.1. Fixed-schedule padding message (RELAY_COMMAND_PADDING_SCHEDULE) + +The fixed schedule padding will be encoded in a +RELAY_COMMAND_PADDING_SCHEDULE cell. It specifies a set of up to 80 +fixed time points in the future to send cells. + +XXX: 80 timers is a lot to allow every client to create. We may want to +have something that checks this structure to ensure it actually +schedules no more than N in practice, until we figure out how to +optimize either libevent or timer scheduling/packet delivery. + +The RELAY_COMMAND_PADDING_SCHEDULE body is specified in Trunnel as +follows: + + struct relay_padding_schedule { + /* Number of microseconds before sending cells (cumulative) */ + u32 when_send[80]; + + /* Number of cells to send at time point sum(when_send[0..i]) */ + u16 num_cells[80]; + + /* Adaptivity: If 1, and server-originating cells arrive before the + next when_send time, then decrement the next non-zero when_send + index, so we don't send a padding cell then, too */ + u8 adaptive IN [0,1]; + }; + +To allow both high-resolution time values, and the ability to specify +timeout values far in the future, the time values are cumulative. In +other words, sending a cell with when_send = [MAX_INT, MAX_INT, MAX_INT, +0...] and num_cells = [0, 0, 100, 0...] would cause the relay to reply +with 100 cells in 3*MAX_INT microseconds from the receipt of this cell. + +3.2. Adaptive Padding message (RELAY_COMMAND_PADDING_ADAPTIVE) + +The following message is derived from the Adaptive Padding defense +specified in "Timing Attacks and Defenses"[1]. + +The message encodes either one or two state machines, each of which +contain two histograms ("Burst" and "Gap") governing their behavior. + +The "Burst" histogram specifies the delay probabilities for sending a +padding packet after the arrival of a non-padding data packet. + +The "Gap" histogram specifies the delay probabilities for sending +another padding packet after a padding packet was just sent from this +node. This self-triggering property of the "Gap" histogram allows the +construction of multi-packet padding trains using a simple statistical +distribution. + +Both "Gap" and "Burst" histograms each have a special "Infinity" bin, +which means "We have decided not to send a packet". + +Each histograms is combined with state transition information, which +allows a client to specify the types of incoming packets that cause the +state machine to decide to schedule padding cells (and/or when to cease +scheduling them). + +The histograms and the associated state machines are specified in +Trunnel as follows: + + /* These constants form a bitfield to specify the types of events + * that can cause padding to start or stop from a given state. */ + const RELAY_PADDING_TRANSITION_EVENT_INFINITY_BIN = 0; // "Always set" + const RELAY_PADDING_TRANSITION_EVENT_NONPADDING_RECV = 1; + const RELAY_PADDING_TRANSITION_EVENT_NONPADDING_SENT = 2; + const RELAY_PADDING_TRANSITION_EVENT_PADDING_SENT = 4; + const RELAY_PADDING_TRANSITION_EVENT_PADDING_RECV = 8; + + const RELAY_PADDING_HISTOGRAM_INFINITY_BIN = 50; + /* + This encodes a histogram delay distribution representing the + probability of sending a single RELAY_DROP cell after a given + delay in response to a non-padding cell. + */ + struct burst_state { + u16 histogram[51]; + u32 start_usec; + u16 max_sec; + + /* This is a bitfield that specifies which direction and types + of traffic should cause us to schedule a padding packet + (and potentially transition to the Gap state). */ + u8 transition_events; + + /* Should we remove tokens from the histogram as packets are sent? */ + u8 remove_toks IN [0,1]; + }; + + /* + This histogram encodes a delay distribution representing the + probability of sending a single additional padding packet after + sending a padding packet that originated at this hop. + */ + struct gap_state { + u16 histogram[51]; + u32 start_usec; + u16 max_sec; + + /* + Integer value to add to the "Infinity" bin after each successive + padding packet is sent. Used to create an increasing likelihood + of hitting the termination condition with each successive padding + packet. */ + u16 decay_by; + + /* This is a bitfield which specifies which direction and types + of traffic should cause us to transition back to the burst + state. */ + u8 transition_events; + + /* Should we remove tokens from the histogram as packets are sent? */ + u8 remove_toks IN [0,1]; + }; + + struct adaptive_padding_machine { + struct burst_state burst; + struct gap_state gap; + }; + + /* This is the full payload of a RELAY_COMMAND_PADDING_ADAPTIVE + cell. */ + struct relay_command_padding_adaptive { + u8 num_machines IN [1,2]; + + struct adaptive_padding_machine machines[num_machines]; + }; + +3.2.1. Histogram state machine operation + +Each of pair of histograms ("Burst" and "Gap") together form a state +machine whose transitions are governed by incoming traffic and/or +locally generated padding traffic. + +Each state machine has a Start state S, a Burst state B, and a Gap state +G. + +The state machine starts idle (state S) until it receives a packet of a +type that matches the bitmask in burst.transition_events. + +This causes it to enter burst mode (state B), in which a delay t is +sampled from the Burst histogram, and a timer is scheduled to count down +until either another matching packet arrives, or t expires. + +If a matching packet arrives before t expires, a new delay is sampled +and the process is repeated again, i.e. it remains in burst mode. + +Otherwise, a padding message is sent to the other end and the machine +switches to state G (Gap mode). In state G, the machine samples from the +Gap histogram and sends padding messages when the time it samples +expires. An infinite delay can be sampled from the histograms. When an +infinite delay is sampled while being in state G we jump back to state +B. Similarly, a transition to S occurs when we sample an infinite time +in B. + +Optionally, a transition from G to B can also occur upon receiving a +packet, as specified by gap.transition_events bitmask. + +Clients are expected to maintain their own local version of the state +machines, for reacting to their own locally generated traffic, in +addition to sending one or more state machines to the middle relay. + +The histograms that the client uses locally will likely differ from the +ones it sends to the upstream relay. + +3.2.2. Histogram decoding/representation + +Each of the histograms' fields represent a probability distribution that +is expanded into bins representing time periods a[i]..b[i] as follows: + +start_usec,max_sec initialized from appropriate histogram type. + +a[0] = start_usec; +n = RELAY_PADDING_HISTOGRAM_INFINITY_BIN; + +a[i] = start_usec + max_sec*USEC_PER_SEC/2^(n-i) +b[i] = start_usec + max_sec*USEC_PER_SEC/2^(n-i-1) + +To sample the delay time to send a padding packet, perform the +following: + + i = 0; + curr_weight = histogram[0]; + + tot_weight = sum(histogram); + bin_choice = crypto_rand_int(tot_weight); + + while (curr_weight < bin_choice) { + curr_weight += histogram[i]; + i++; + } + + if (i == RELAY_PADDING_HISTOGRAM_INFINITY_BIN) + return; // Don't send a padding packet + + // Sample uniformly between a[i] and b[i] + send_padding_packet_at = a[i] + crypto_rand_int(b[i] - a[i]); + +In this way, the bin widths are exponentially increasing in width, where +the width is set at max_sec/2^(n-i) seconds. This exponentially +increasing bin width allows the histograms to most accurately represent +small interpacket delay (where accuracy is needed), and devote less +accuracy to larger timescales (where accuracy is not as important). + +3.2.3. Token removal and refill + +If the remove_tok field is set to true for a given state's histogram, +then whenever a padding packet is sent, the corresponding histogram +bin's token count is decremented by one. + +If a non-padding packet arrives from the server before the chosen +padding timer expires, then a token is removed from the nearest +non-empty bin corresponding to the delay since the last packet was sent, +and the padding packet timer is re-sampled from the histogram. + +If the entire histogram becomes empty, it is then refilled to the +original values. + +3.2.4. Constructing the histograms + +Care must be taken when constructing the histograms themselves, since +their non-uniform widths means that the actual underlying probability +distribution needs to be both normalized for total number of tokens, as +well as the non-uniform histogram bin widths. + +Care should also be taken with interaction with the token removal rules +from Section 3.2.3. Obviously using a large number of tokens will cause +token removal to have much less of an impact upon the adaptive nature of +the padding in the face of existing traffic. + +Actual optimal histogram construction for different traffic types is +expected to be a topic for further research. + + +4. Security considerations and mitigations + +The risks from this proposal are primarily DoS/resource exhaustion, and +side channels. + +4.1. Traffic handling + +Fully client-requested padding introduces a vector for resource +amplification attacks and general network overload due to +overly-aggressive client implementations requesting too much padding. + +Current research indicates that this form of statistical padding should +be effective at overhead rates of 50-60%. This suggests that clients +that use more padding than this are likely to be overly aggressive in +their behavior. + +We recommend that three consensus parameters be used in the event that +the network is being overloaded from padding to such a degree that +padding requests should be ignored: + + * CircuitPaddingMaxRatio + - The maximum ratio of padding traffic to non-padding traffic + (expressed as a percent) to allow on a circuit before ceasing + to pad. Ex: 75 means 75 padding packets for every 100 non-padding + packets. + - Default: 100 + * CircuitPaddingLimitCount + - The number of padding cells that must be transmitted before the + ratio limit is applied. + - Default: 500 + * CircuitPaddingLimitTime + - The time period in seconds over which to count padding cells for + application of the ratio limit. + - Default: 60 + +XXX: Should we cap padding at these rates, or fully disable it once +they're crossed? + +Proposal 251 introduced extra-info accounting at relays to enable us to +measure the total overhead of both link and circuit-level padding at +various relays. + +4.2. Libevent timer exhaustion + +As mentioned in section 3.1, scheduled padding may create an excessive +number of libevent timers. Care should be taken in the implementation to +devise a way to prevent clients from sending padding requests +specifically designed to impact the ability of relays to function by +causing too many timers to be scheduled at once. + +XXX: Can we suggest any specifics here? I can imagine a few ways of +lazily scheduling timers only when they are close to their expiry time, +and other ways of minimizing the number of pending timer callbacks at a +given time, but I am not sure which would be best for libevent. + +4.3. Side channels + +In order to prevent relays from introducing side channels by requesting +padding from clients, all of these commands should only be valid in the +outgoing (from the client/OP) direction. + +Clients should perform accounting on the amount of padding that they +receive, and if it exceeds the amount that they have requested, they +alert the user of a potentially misbehaving node, and/or close the +circuit. + +Similarly, if RELAY_DROP cells arrive from the last hop of a circuit, +rather than from the expected interior node, clients should alert the +user of the possibility of that circuit endpoint introducing a +side-channel attack, and/or close the circuit. + + +------------------- + + +1. http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf

1 0

[torspec/master] Generalize state transition capability.
by isis＠torproject.org 25 Sep '15

25 Sep '15

commit 9703c86274bdeac3e7dde5c571210660e782dc5d Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Fri Sep 11 15:12:24 2015 -0700 Generalize state transition capability. Also allow the histograms to be variable in size. --- proposals/xxx-padding-negotiation.txt | 261 ++++++++++++++++++++++++--------- 1 file changed, 192 insertions(+), 69 deletions(-) diff --git a/proposals/xxx-padding-negotiation.txt b/proposals/xxx-padding-negotiation.txt index 66d8991..005045a 100644 --- a/proposals/xxx-padding-negotiation.txt +++ b/proposals/xxx-padding-negotiation.txt @@ -34,7 +34,7 @@ compromised guard node. However, link-level padding is still useful to defend against an adversary that can merely observe a Guard node externally. Right now, the only case where link-level padding is known to defend against any realistic attacker is for low-resolution -netflow-based attacks. +netflow-based attacks (see Proposal 251[1]). In that scenario, the primary mechanism we need is a way for mobile clients to tell their Guards to stop padding, or to pad less often. The @@ -50,7 +50,8 @@ following Trunnel payloads should cover the needed parameters: }; /* This command tells the relay to alter its min and max timeout - range values, and if needed, send + range values, and send padding at that rate (resuming if + stopped). */ struct cell_padding_start { u8 command IN [CELL_PADDING_COMMAND_START]; @@ -62,9 +63,10 @@ following Trunnel payloads should cover the needed parameters: u16 ito_high_ms; }; -If more scenarios are discovered, future command numbers could be used -to include the end-to-end padding command payloads below, or other -defense parameterizations. +More complicated forms of link padding can still be specified using +the primitives in Section 3, by using "leaky pipe" topology to send +the RELAY commands to the Guard node instead of to later nodes in the +circuit. 3. End-to-end circuit padding @@ -78,7 +80,8 @@ traffic (aka "Adaptive Padding"). In both cases, these messages will be sent from clients to middle nodes using "leaky pipe" property of the 'recognized' field of RELAY cells, allowing padding to originate from middle nodes on a circuit in a way -that is not detectable from the Guard node. +that is not detectable from the Guard node. This same mechanism can also +be used to request padding from the Guard node itself. 3.1. Fixed-schedule padding message (RELAY_COMMAND_PADDING_SCHEDULE) @@ -100,7 +103,7 @@ follows: /* Number of cells to send at time point sum(when_send[0..i]) */ u16 num_cells[80]; - + /* Adaptivity: If 1, and server-originating cells arrive before the next when_send time, then decrement the next non-zero when_send index, so we don't send a padding cell then, too */ @@ -112,11 +115,11 @@ timeout values far in the future, the time values are cumulative. In other words, sending a cell with when_send = [MAX_INT, MAX_INT, MAX_INT, 0...] and num_cells = [0, 0, 100, 0...] would cause the relay to reply with 100 cells in 3*MAX_INT microseconds from the receipt of this cell. - + 3.2. Adaptive Padding message (RELAY_COMMAND_PADDING_ADAPTIVE) -The following message is derived from the Adaptive Padding defense -specified in "Timing Attacks and Defenses"[1]. +The following message is a generalization of the Adaptive Padding +defense specified in "Timing Attacks and Defenses"[2]. The message encodes either one or two state machines, each of which contain two histograms ("Burst" and "Gap") governing their behavior. @@ -133,37 +136,57 @@ distribution. Both "Gap" and "Burst" histograms each have a special "Infinity" bin, which means "We have decided not to send a packet". -Each histograms is combined with state transition information, which +Each histogram is combined with state transition information, which allows a client to specify the types of incoming packets that cause the state machine to decide to schedule padding cells (and/or when to cease scheduling them). -The histograms and the associated state machines are specified in -Trunnel as follows: +Note that our generalization of the Adaptive Padding state machine +actually gives clients full control over the state transition events, +even allowing them to specify a single-state state machine if desired. +See Sections 3.2.1 and 3.2.2 for details. + +The histograms and the associated state machine packet layout is +specified in Trunnel as follows: /* These constants form a bitfield to specify the types of events * that can cause padding to start or stop from a given state. */ - const RELAY_PADDING_TRANSITION_EVENT_INFINITY_BIN = 0; // "Always set" const RELAY_PADDING_TRANSITION_EVENT_NONPADDING_RECV = 1; const RELAY_PADDING_TRANSITION_EVENT_NONPADDING_SENT = 2; const RELAY_PADDING_TRANSITION_EVENT_PADDING_SENT = 4; const RELAY_PADDING_TRANSITION_EVENT_PADDING_RECV = 8; - const RELAY_PADDING_HISTOGRAM_INFINITY_BIN = 50; - /* + /* This encodes a histogram delay distribution representing the probability of sending a single RELAY_DROP cell after a given delay in response to a non-padding cell. */ struct burst_state { - u16 histogram[51]; + u8 histogram_len IN [2..51]; + u16 histogram[histogram_len]; u32 start_usec; u16 max_sec; - /* This is a bitfield that specifies which direction and types - of traffic should cause us to schedule a padding packet - (and potentially transition to the Gap state). */ - u8 transition_events; + /* + This is a bitfield that specifies which direction and types + of traffic that cause us to abort our scheduled packet and + return to waiting for another event from transition_burst_events. + */ + u8 transition_start_events; + + /* + This is a bitfield that specifies which direction and types + of traffic that cause us to remain in the burst state: Cancel the + pending padding packet (if any), and schedule another padding + packet from our histogram. + */ + u8 transition_reschedule_events; + + /* + This is a bitfield that specifies which direction and types + of traffic that cause us to transition to the Gap state. + */ + u8 transition_gap_events; /* Should we remove tokens from the histogram as packets are sent? */ u8 remove_toks IN [0,1]; @@ -175,27 +198,39 @@ Trunnel as follows: sending a padding packet that originated at this hop. */ struct gap_state { - u16 histogram[51]; + u8 histogram_len IN [2..51]; + u16 histogram[histogram_len]; u32 start_usec; u16 max_sec; - /* - Integer value to add to the "Infinity" bin after each successive - padding packet is sent. Used to create an increasing likelihood - of hitting the termination condition with each successive padding - packet. */ - u16 decay_by; + /* This is a bitfield which specifies which direction and types + of traffic should cause us to transition back to the start + state (ie: abort scheduling packets completely). */ + u8 transition_start_events; /* This is a bitfield which specifies which direction and types of traffic should cause us to transition back to the burst - state. */ - u8 transition_events; + state (and schedule a packet from the burst histogram). */ + u8 transition_burst_events; + + /* + This is a bitfield that specifies which direction and types + of traffic that cause us to remain in the gap state: Cancel the + pending padding packet (if any), and schedule another padding + packet from our histogram. + */ + u8 transition_reschedule_events; /* Should we remove tokens from the histogram as packets are sent? */ u8 remove_toks IN [0,1]; }; struct adaptive_padding_machine { + /* This is a bitfield which specifies which direction and types + of traffic should cause us to transition to the burst + state (and schedule a packet from the burst histogram). */ + u8 transition_burst_events; + struct burst_state burst; struct gap_state gap; }; @@ -218,25 +253,57 @@ Each state machine has a Start state S, a Burst state B, and a Gap state G. The state machine starts idle (state S) until it receives a packet of a -type that matches the bitmask in burst.transition_events. +type that matches the bitmask in machines[i].transition_burst_events. This causes it to enter burst mode (state B), in which a delay t is sampled from the Burst histogram, and a timer is scheduled to count down -until either another matching packet arrives, or t expires. +until either another matching packet arrives, or t expires. If the +"Infinity" time is sampled from this histogram, the machine returns to +the Start state. -If a matching packet arrives before t expires, a new delay is sampled -and the process is repeated again, i.e. it remains in burst mode. +If a packet that matches machines[i].burst.transition_start_events +arrives before t expires, the machine transitions back to the Start +state. -Otherwise, a padding message is sent to the other end and the machine -switches to state G (Gap mode). In state G, the machine samples from the -Gap histogram and sends padding messages when the time it samples -expires. An infinite delay can be sampled from the histograms. When an -infinite delay is sampled while being in state G we jump back to state -B. Similarly, a transition to S occurs when we sample an infinite time -in B. +If a packet that matches machines[i].burst.transition_reschedule_events +arrives before t expires, a new delay is sampled and the process is +repeated again, i.e. it remains in burst mode. -Optionally, a transition from G to B can also occur upon receiving a -packet, as specified by gap.transition_events bitmask. +Otherwise, if t expires, a padding message is sent to the other end. + +If a packet that matches machines[i].burst.transition_gap_events +arrives (or is sent), the machine transitions to the Gap state G. + +In state G, the machine samples from the Gap histogram and sends padding +messages when the time it samples expires. If an infinite delay is +sampled while being in state G we jump back to state B. + +If a packet arrives that matches gap.transition_start_events, the +machine transitions back to the Start state. + +If a packet arrives that matches gap.transition_burst_events, the +machine transitions back to the Burst state. + +If a packet arrives that matches +machines[i].gap.transition_reschedule_events, the machine remains in G +but schedules a new padding time from its Gap histogram. + +In the event that a malicious or buggy client specifies conflicting +state transition rules with the same bits in multiple transition +bitmasks, the transition rules of a state that specify transition to +earlier states take priority. So burst.transition_start_events +takes priority over burst.transition_reschedule_events, and both of +these take priority over burst.transition_gap_events. + +Similarly, gap.transition_start_events takes priority over +gap.transition_burst_events, and gap.transition_burst_events takes +priority over gap.transition_reschedule_events. + +In our generalization of Adaptive Padding, either histogram may actually +be self-scheduling (by setting the bit +RELAY_PADDING_TRANSITION_EVENT_PADDING_SENT in their +transition_reschedule_events). This allows the client to create a +single-state machine if desired. Clients are expected to maintain their own local version of the state machines, for reacting to their own locally generated traffic, in @@ -245,18 +312,49 @@ addition to sending one or more state machines to the middle relay. The histograms that the client uses locally will likely differ from the ones it sends to the upstream relay. -3.2.2. Histogram decoding/representation +3.2.2. The original Adaptive Padding algorithm + +As we have noted, the state machines above represent a generalization of +the original Adaptive Padding algorithm. To implement the original +behavior, the following flags should be set: + + machines[0].transition_burst_events = + RELAY_PADDING_TRANSITION_EVENT_NONPADDING_SENT; + + machines[0].burst.transition_reschedule_events = + RELAY_PADDING_TRANSITION_EVENT_NONPADDING_SENT; + + machines[0].burst.transition_gap_events = + RELAY_PADDING_TRANSITION_EVENT_PADDING_SENT; + + machines[0].gap.transition_reschedule_events = + RELAY_PADDING_TRANSITION_EVENT_PADDING_SENT; + + machines[0].gap.transition_burst_events = + RELAY_PADDING_TRANSITION_EVENT_NONPADDING_SENT; + +The rest of the transition fields would be 0. + +Adding additional transition flags will either increase or decrease the +amount of padding sent, depending on their placement. + +3.2.3. Histogram decoding/representation Each of the histograms' fields represent a probability distribution that is expanded into bins representing time periods a[i]..b[i] as follows: -start_usec,max_sec initialized from appropriate histogram type. +start_usec,max_sec,histogram_len initialized from appropriate histogram +body. -a[0] = start_usec; -n = RELAY_PADDING_HISTOGRAM_INFINITY_BIN; +n = histogram_len-1 +INFINITY_BIN = n -a[i] = start_usec + max_sec*USEC_PER_SEC/2^(n-i) -b[i] = start_usec + max_sec*USEC_PER_SEC/2^(n-i-1) +a[0] = start_usec; +b[0] = start_usec + max_sec*USEC_PER_SEC/2^(n); +for(i=1; i < n; i++) { + a[i] = start_usec + max_sec*USEC_PER_SEC/2^(n-i) + b[i] = start_usec + max_sec*USEC_PER_SEC/2^(n-i-1) +} To sample the delay time to send a padding packet, perform the following: @@ -272,11 +370,11 @@ following: i++; } - if (i == RELAY_PADDING_HISTOGRAM_INFINITY_BIN) + if (i == INFINITY_BIN) return; // Don't send a padding packet // Sample uniformly between a[i] and b[i] - send_padding_packet_at = a[i] + crypto_rand_int(b[i] - a[i]); + send_padding_packet_at = a[i] + crypto_rand_int(b[i] - a[i]); In this way, the bin widths are exponentially increasing in width, where the width is set at max_sec/2^(n-i) seconds. This exponentially @@ -284,21 +382,22 @@ increasing bin width allows the histograms to most accurately represent small interpacket delay (where accuracy is needed), and devote less accuracy to larger timescales (where accuracy is not as important). -3.2.3. Token removal and refill +3.2.4. Token removal and refill If the remove_tok field is set to true for a given state's histogram, then whenever a padding packet is sent, the corresponding histogram bin's token count is decremented by one. -If a non-padding packet arrives from the server before the chosen -padding timer expires, then a token is removed from the nearest -non-empty bin corresponding to the delay since the last packet was sent, -and the padding packet timer is re-sampled from the histogram. +If a packet matching the current state's transition_reschedule_events +bitmask arrives from the server before the chosen padding timer expires, +then a token is removed from the nearest non-empty bin corresponding to +the delay since the last packet was sent, and the padding packet timer +is re-sampled from the histogram. If the entire histogram becomes empty, it is then refilled to the original values. -3.2.4. Constructing the histograms +3.2.5. Constructing the histograms Care must be taken when constructing the histograms themselves, since their non-uniform widths means that the actual underlying probability @@ -306,12 +405,19 @@ distribution needs to be both normalized for total number of tokens, as well as the non-uniform histogram bin widths. Care should also be taken with interaction with the token removal rules -from Section 3.2.3. Obviously using a large number of tokens will cause +from Section 3.2.4. Obviously using a large number of tokens will cause token removal to have much less of an impact upon the adaptive nature of the padding in the face of existing traffic. -Actual optimal histogram construction for different traffic types is -expected to be a topic for further research. +Actual optimal histogram and state transition construction for different +traffic types is expected to be a topic for further research. + +Intuitively, the burst state is used to detect when the line is idle +(and should therefore have few or no tokens in low histogram bins), and +the gap state is used to fill in otherwise idle periods with artificial +payloads from the server (and should have many tokens in low bins, and +possibly some also at higher bins). However, more complicated +interactions are also possible. 4. Security considerations and mitigations @@ -356,8 +462,26 @@ Proposal 251 introduced extra-info accounting at relays to enable us to measure the total overhead of both link and circuit-level padding at various relays. -4.2. Libevent timer exhaustion - +4.2. Malicious state machines + +The state machine capabilities of RELAY_COMMAND_PADDING_ADAPTIVE are +very flexible, and as a result may specify conflicting or +non-deterministic state transitions. + +We believe that the rules in Section 3.2.1 for prioritizing transitions +towards lower states remove any possibility of non-deterministic +transitions. + +However, because of self-triggering property that allows the state +machines to schedule more padding packets after sending their own +locally generated padding packets, care must be taken with the +interaction with the rate limiting rules in Section 4.1. If the limits +in section 4.1 are exceeded, the state machines should stop, rather than +continually poll themselves trying to transmit packets and being blocked +by the rate limiter at another layer. + +4.3. Libevent timer exhaustion + As mentioned in section 3.1, scheduled padding may create an excessive number of libevent timers. Care should be taken in the implementation to devise a way to prevent clients from sending padding requests @@ -369,7 +493,7 @@ lazily scheduling timers only when they are close to their expiry time, and other ways of minimizing the number of pending timer callbacks at a given time, but I am not sure which would be best for libevent. -4.3. Side channels +4.4. Side channels In order to prevent relays from introducing side channels by requesting padding from clients, all of these commands should only be valid in the @@ -384,9 +508,8 @@ Similarly, if RELAY_DROP cells arrive from the last hop of a circuit, rather than from the expected interior node, clients should alert the user of the possibility of that circuit endpoint introducing a side-channel attack, and/or close the circuit. - - -------------------- - - -1. http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf + +------------------- + +1. https://gitweb.torproject.org/torspec.git/tree/proposals/251-netflow-paddin… +2. http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf

1 0

[torspec/master] Allow infinity transitions to be programmable.
by isis＠torproject.org 25 Sep '15

25 Sep '15

commit ec84f2c788a1b08047fea854b2ed71d08eb94076 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Fri Sep 11 18:37:32 2015 -0700 Allow infinity transitions to be programmable. Forgetting to specify the infinity transitions causes the state machine to just shut down. --- proposals/xxx-padding-negotiation.txt | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/proposals/xxx-padding-negotiation.txt b/proposals/xxx-padding-negotiation.txt index 4202540..0292f22 100644 --- a/proposals/xxx-padding-negotiation.txt +++ b/proposals/xxx-padding-negotiation.txt @@ -174,6 +174,7 @@ specified in Trunnel as follows: const RELAY_PADDING_TRANSITION_EVENT_NONPADDING_SENT = 2; const RELAY_PADDING_TRANSITION_EVENT_PADDING_SENT = 4; const RELAY_PADDING_TRANSITION_EVENT_PADDING_RECV = 8; + const RELAY_PADDING_TRANSITION_EVENT_INFINITY = 16; /* This payload encodes a histogram delay distribution representing * the probability of sending a single RELAY_DROP cell after a @@ -273,7 +274,7 @@ This causes it to enter burst mode (state B), in which a delay t is sampled from the Burst histogram, and a timer is scheduled to count down until either another matching packet arrives, or t expires. If the "Infinity" time is sampled from this histogram, the machine returns to -the Start state. +the lowest state with the INFINITY event bit set. If a packet that matches machines[i].burst.transition_start_events arrives before t expires, the machine transitions back to the Start @@ -290,7 +291,8 @@ arrives (or is sent), the machine transitions to the Gap state G. In state G, the machine samples from the Gap histogram and sends padding messages when the time it samples expires. If an infinite delay is -sampled while being in state G we jump back to state B. +sampled while being in state G we jump back to state B or S, +depending upon the usage of the infinity event bitmask. If a packet arrives that matches gap.transition_start_events, the machine transitions back to the Start state. @@ -349,11 +351,15 @@ the relay state machines: machines[0].burst.transition_gap_events = RELAY_PADDING_TRANSITION_EVENT_PADDING_SENT; + machines[0].burst.transition_start_events = + RELAY_PADDING_TRANSITION_EVENT_INFINITY; + machines[0].gap.transition_reschedule_events = RELAY_PADDING_TRANSITION_EVENT_PADDING_SENT; machines[0].gap.transition_burst_events = - RELAY_PADDING_TRANSITION_EVENT_NONPADDING_SENT; + RELAY_PADDING_TRANSITION_EVENT_NONPADDING_SENT | + RELAY_PADDING_TRANSITION_EVENT_INFINITY; The rest of the transition fields would be 0.

1 0

[translation/tor-messenger-ircproperties_completed] Update translations for tor-messenger-ircproperties_completed
by translation＠torproject.org 25 Sep '15

25 Sep '15

commit 5f8a59696807c1cb76547374f491d938c443cc61 Author: Translation commit bot <translation(a)torproject.org> Date: Fri Sep 25 07:16:31 2015 +0000 Update translations for tor-messenger-ircproperties_completed --- id/irc.properties | 205 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 205 insertions(+) diff --git a/id/irc.properties b/id/irc.properties new file mode 100644 index 0000000..4fc394a --- /dev/null +++ b/id/irc.properties @@ -0,0 +1,205 @@ +# This Source Code Form is subject to the terms of the Mozilla Public +# License, v. 2.0. If a copy of the MPL was not distributed with this +# file, You can obtain one at http://mozilla.org/MPL/2.0/. + +# LOCALIZATION NOTE (irc.usernameHint): +# This is displayed inside the accountUsernameInfoWithDescription +# string defined in imAccounts.properties when the user is +# configuring an IRC account. +irc.usernameHint=nick + +# LOCALIZATION NOTE (connection.error.*): +# These will show in the account manager if the account is +# disconnected because of an error. +connection.error.lost=Sambungan dengan server terputus +connection.error.timeOut=Sambungan melewati batas waktu +connection.error.invalidUsername=%S bukan nama pengguna yang diizinkan +connection.error.invalidPassword=Sandi server tidak valid +connection.error.passwordRequired=Membutuhkan sandi + +# LOCALIZATION NOTE (joinChat.*): +# These show up on the join chat menu. An underscore is for the access key. +joinChat.channel=Sa_luran +joinChat.password=_Sandi + +# LOCALIZATION NOTE (options.*): +# These are the protocol specific options shown in the account manager and +# account wizard windows. +options.server=Server +options.port=Port +options.ssl=Gunakan SSL +options.encoding=Set Karakter +options.quitMessage=Pesan keluar +options.partMessage=Bagian pesan +options.showServerTab=Tampilkan pesan dari server +options.alternateNicks=Nick alternatif + +# LOCALIZATION NOTE (ctcp.version): +# %1$S is the nickname of the user whose version was requested. +# %2$S is the version response from the client. +ctcp.version=%1$S menggunakan "%2$S". +# LOCALIZATION NOTE (ctcp.time): +# %1$S is the nickname of the user whose time was requested. +# %2$S is the time response. +ctcp.time=Waktu untuk %1$S adalah %2$S. + +# LOCALZIATION NOTE (command.*): +# These are the help messages for each command, the %S is the command name +# Each command first gives the parameter it accepts and then a description of +# the command. +command.action=%S <action to perform>: melakukan tindakan +command.ctcp=%S <nick> <msg>: mengirim CTCP ke nama samaran. +command.chanserv=%S <command>: mengirim perintah ke ChanSrv. +command.deop=%S <nick1>[,<nick2>]*: Membuang status operator kanal seseorang. Anda harus menjadi operator kanal untuk melakukan hal ini. +command.devoice=%S <nick1>[,<nick2>]*: Membuang status kanal suara seseorang, mencegahnya berbicara jika kanal dimoderasi (+m). Anda harus menjadi operator kanal untuk melakukan hal ini. +command.invite2=%S <nick>[ <nick>]* [<channel>]: mengundang satu atau lebih nama samaran untuk bergabung denganmu di kanal ini, atau bergabung dengan kanal tertentu. +command.join=%S <room1>[ <key1>][,<room2>[ <key2>]]*: Memasukan satu atau lebih kanal, optional menyediakan kunci kanal masing-masing jika dibutuhkan. +command.kick=%S <nick> [<message>]: Menghapus seseorang dari kanal. Anda harus menjadi operator kanal untuk melakukan hal ini. +command.list=%S: Menampilkan daftar ruang ngobrol di jaringan. Awas, beberapa server mungkin memutus koneksimu jika melakukan hal ini. +command.memoserv=%S <command>: mengirim perintah ke MemoServ. +command.modeUser=%S (+|-)<new mode> [<nick>]: membuat atau merubah moda pemakai. +command.modeChannel=%S <channel>[ (+|-)<new mode> [<parameter>][,<parameter>]*]: Mengambil, menyusun atau merombak moda kanal. +command.msg=%S <nick> <message>: Mengirim pesan pribadi kepada pengguna (sebagai kebalikan dari pesan ke kanal) +command.nick=%S <new nickname>: Merubah nama samaran. +command.nickserv=%S <command>: Mengirim perintah ke NickServ. +command.notice=%S <target> <message>: Mengirim pemberitahuan ke pengguna atau kanal. +command.op=%S <nick1>[,<nick2>]*: Memberi status operator kanal pada seseorang. Anda harus menjadi operator kanal agar bisa melakukan hal ini. +command.operserv=%S <command>: mengirim satu perintah ke OperServ. +command.part=%S [message]: Meninggalkan kanal ini dengan pesan pilihan. +command.ping=%S [<nick>]: Menanyakan berapa banyak pengguna (atau server jika tidak ada pengguna) yang tertinggal, +command.quit=%S <message>: Memutus koneksi server, dengan pilihan pesan. +command.quote=%S <command>: Mengirim pesan belum terolah ke server. +command.time=%S: Menampilkan waktu setempat saat ini di server IRC. +command.topic=%S [<new topic>]: Membuat judul kanal. +command.umode=%S (+|-)<new mode>: membuat atau merubah moda pengguna. +command.version=%S <nick>: Meminta versi klien pengguna. +command.voice=%S <nick1>[,<nick2>]*: Memberi status kanal suara pada seseorang. Anda harus menjadi operator kanal untuk dapat melakukan hal ini. +command.whois2=%S [<nick>]: Meminta informasi pengguna. + +# LOCALIZATION NOTE (message.*): +# These are shown as system messages in the conversation. +# %1$S is the nick and %2$S is the nick and host of the user who joined. +message.join=%1$S [%2$S] masuk ke ruang. +message.rejoined=Anda telah bergabung kembali. +# %1$S is the nick of who kicked you. +# %2$S is message.kicked.reason, if a kick message was given. +message.kicked.you=Anda telah dikeluarkan oleh %1$S%2$S. +# %1$S is the nick that is kicked, %2$S the nick of the person who kicked +# %1$S. %3$S is message.kicked.reason, if a kick message was given. +message.kicked=%1$S telah dikeluarkan oleh %2$S%3$S. +# %S is the kick message +message.kicked.reason=: %S +# %1$S is the new mode, %2$S is the nickname of the user whose mode +# was changed, and %3$S is who set the mode. +message.usermode=Mode %1$S untuk %2$S ditetapkan oleh %3$S. +# %1$S is the new channel mode and %2$S is who set the mode. +message.channelmode=Mode saluran %1$S ditetapkan oleh %2$S. +# %S is the user's mode. +message.yourmode=Mode Anda adalah %S. +# Could not change the nickname. %S is the user's nick. +message.nick.fail=Nickname tidak dapat digunakan. Nick Anda masih %S. +# The parameter is the message.parted.reason, if a part message is given. +message.parted.you=Anda sudah keluar (Bagian%1$S). +# %1$S is the user's nick, %2$S is message.parted.reason, if a part message is given. +message.parted=%1$S sudah keluar (Bagian%2$S). +# %S is the part message supplied by the user. +message.parted.reason=: %S +# %1$S is the user's nick, %2$S is message.quit2 if a quit message is given. +message.quit=%1$S sudah keluar (Keluar%2$S). +# The parameter is the quit message given by the user. +message.quit2=: %S +# %1$S is the nickname of the user that invited us, %2$S is the conversation +# name. +message.inviteReceived=%1$S telah mengundang Anda ke %2$S. +# %1$S is the nickname of the invited user, %2$S is the conversation name +# they were invited to. +message.invited=%1$S telah dengan sukses diundang ke %2$S. +# %1$S is the nickname of the invited user, %2$S is the conversation name +# they were invited to but are already in +message.alreadyInChannel=%1$S sudah ada di dalam %2$S. +# %S is the nickname of the user who was summoned. +message.summoned=%S telah dipanggil. +# %S is the nickname of the user whose WHOIS information follows this message. +message.whois=Informasi WHOIS untuk %S: +# %1$S is the nickname of the (offline) user whose WHOWAS information follows this message. +message.whowas=%1$S sedang luring. Informasi WHOWAS untuk %1$S: +# %1$S is the entry description (from tooltip.*), %2$S is its value. +message.whoisEntry=\\ua0\\ua0\\ua0\\ua0%1$S: %2$S +# %S is the nickname that is not known to the server. +message.unknownNick=Nickname %S tidak diketahui. +# %1$S is the nickname of the user who changed the mode and %2$S is the new +# channel key (password). +message.channelKeyAdded=%1$S mengubah sandi saluran menjadi %2$S. +message.channelKeyRemoved=%S membuang sandi saluran. +# This will be followed by a list of ban masks. +message.banMasks=Pengguna yang terhubung dari lokasi berikut dicekal dari %S: +message.noBanMasks=Tidak ada lokasi yang dicekal untuk %S. +message.banMaskAdded=Pengguna tersambung dari lokasi %1$S yang telah dicekal oleh %2$S. +message.banMaskRemoved=Pengguna tersambung dari lokasi %1$S yang tidak lagi dicekal oleh %2$S. +# LOCALIZATION NOTE (message.ping): Semi-colon list of plural forms. +# See: http://developer.mozilla.org/en/docs/Localization_and_Plurals +# %1$S is the nickname of the user or the server that was pinged. +# #2 is the delay (in milliseconds). +message.ping=Balasan ping dari %1$S dalam #2 milidetik.;Balasan ping dari %1$S dalam #2 milidetik. + + +# LOCALIZATION NOTE (error.*): +# These are shown as error messages in the conversation or server tab. +# %S is the channel name. +error.noChannel=Tidak ada saluran: %S. +error.tooManyChannels=Tidak dapat bergabung ke %S; Anda telah bergabung dengan terlalu banyak saluran. +# %1$S is your new nick, %2$S is the kill message from the server. +error.nickCollision=Nick sudah dipakai, mengubah nick menjadi %1$S [%2$S]. +error.erroneousNickname=Nickname %S tidak diperbolehkan. +error.banned=Anda dicekal dari server ini. +error.bannedSoon=Anda akan segera dicekal dari server ini. +error.mode.wrongUser=Anda tidak dapat mengubah mode untuk pengguna lainnya. +# %S is the nickname or channel name that isn't available. +error.noSuchNick=%S sedang tidak daring. +error.wasNoSuchNick=Tidak ada nickname: %S +error.noSuchChannel=Tidak ada saluran: %S. +error.unavailable=%S sementara tidak tersedia. +# %S is the channel name. +error.channelBanned=Anda telah dicekal dari %S. +error.cannotSendToChannel=Anda tidak dapat mengirim pesan ke %S. +error.channelFull=Saluran %S sudah penuh. +error.inviteOnly=Anda harus diundang untuk bergabung ke %S. +error.nonUniqueTarget=%S bukan pengguna@hos atau namapendek yang unik atau Anda telah mencoba bergabung ke banyak saluran pada saat yang bersamaan. +error.notChannelOp=Anda bukan operator saluran %S. +error.notChannelOwner=Anda bukan pemilik saluran %S. +error.wrongKey=Tidak dapat bergabung ke %S, sandi saluran tidak valid. +error.sendMessageFailed=Sebuah galat terjadi saat mengirimkan pesan terakhir Anda. Mohon coba lagi ketika koneksi tersambung kembali. +# %1$S is the channel the user tried to join, %2$S is the channel +# he was forwarded to. +error.channelForward=Anda mungkin tidak bergabung ke %1$S, dan secara otomatis dialihkan ke %2$S. + +# LOCALIZATION NOTE (tooltip.*): +# These are the descriptions given in a tooltip with information received +# from a whois response. +# The human readable ("realname") description of the user. +tooltip.realname=Nama +tooltip.server=Terhubung ke +# The username and hostname that the user connects from (usually based on the +# reverse DNS of the user's IP, but often mangled by the server to +# protect users). +tooltip.connectedFrom=Terhubung dari +tooltip.registered=Terdaftar +tooltip.registeredAs=Terdaftar sebagai +tooltip.secure=Menggunakan sambungan aman +# The away message of the user +tooltip.away=Pergi +tooltip.ircOp=Operator IRC +tooltip.bot=Bot +tooltip.lastActivity=Aktivitas terakhir +# %S is the timespan elapsed since the last activity. +tooltip.timespan=%S yang lalu +tooltip.channels=Sedang on + +# %1$S is the server name, %2$S is some generic server information (usually a +# location or the date the user was last seen). +tooltip.serverValue=%1$S (%2$S) + +# LOCALIZATION NOTE (yes, no): +# These are used to turn true/false values into a yes/no response. +yes=Ya +no=Tidak

1 0

[translation/tor-messenger-ircproperties] Update translations for tor-messenger-ircproperties
by translation＠torproject.org 25 Sep '15

25 Sep '15

commit d699995e1d06eedb7132ad7795f541ab9780f4fe Author: Translation commit bot <translation(a)torproject.org> Date: Fri Sep 25 07:16:27 2015 +0000 Update translations for tor-messenger-ircproperties --- id/irc.properties | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/id/irc.properties b/id/irc.properties index 52eae2e..4fc394a 100644 --- a/id/irc.properties +++ b/id/irc.properties @@ -54,27 +54,27 @@ command.deop=%S <nick1>[,<nick2>]*: Membuang status operator kanal s command.devoice=%S <nick1>[,<nick2>]*: Membuang status kanal suara seseorang, mencegahnya berbicara jika kanal dimoderasi (+m). Anda harus menjadi operator kanal untuk melakukan hal ini. command.invite2=%S <nick>[ <nick>]* [<channel>]: mengundang satu atau lebih nama samaran untuk bergabung denganmu di kanal ini, atau bergabung dengan kanal tertentu. command.join=%S <room1>[ <key1>][,<room2>[ <key2>]]*: Memasukan satu atau lebih kanal, optional menyediakan kunci kanal masing-masing jika dibutuhkan. -command.kick=%S <nick> [<message>]: Remove someone from a channel. You must be a channel operator to do this. -command.list=%S: Display a list of chat rooms on the network. Warning, some servers may disconnect you upon doing this. -command.memoserv=%S <command>: Send a command to MemoServ. -command.modeUser=%S (+|-)<new mode> [<nick>]: Set or unset a user's mode. -command.modeChannel=%S <channel>[ (+|-)<new mode> [<parameter>][,<parameter>]*]: Get, set or unset a channel mode. -command.msg=%S <nick> <message>: Send a private message to a user (as opposed to a channel). -command.nick=%S <new nickname>: Change your nickname. -command.nickserv=%S <command>: Send a command to NickServ. -command.notice=%S <target> <message>: Send a notice to a user or channel. -command.op=%S <nick1>[,<nick2>]*: Grant channel operator status to someone. You must be a channel operator to do this. -command.operserv=%S <command>: Send a command to OperServ. -command.part=%S [message]: Leave the current channel with an optional message. -command.ping=%S [<nick>]: Asks how much lag a user (or the server if no user specified) has. -command.quit=%S <message>: Disconnect from the server, with an optional message. -command.quote=%S <command>: Send a raw command to the server. -command.time=%S: Displays the current local time at the IRC server. -command.topic=%S [<new topic>]: Set this channel's topic. -command.umode=%S (+|-)<new mode>: Set or unset a user mode. -command.version=%S <nick>: Request the version of a user's client. -command.voice=%S <nick1>[,<nick2>]*: Grant channel voice status to someone. You must be a channel operator to do this. -command.whois2=%S [<nick>]: Mendapat informasi ke seorang pengguna. +command.kick=%S <nick> [<message>]: Menghapus seseorang dari kanal. Anda harus menjadi operator kanal untuk melakukan hal ini. +command.list=%S: Menampilkan daftar ruang ngobrol di jaringan. Awas, beberapa server mungkin memutus koneksimu jika melakukan hal ini. +command.memoserv=%S <command>: mengirim perintah ke MemoServ. +command.modeUser=%S (+|-)<new mode> [<nick>]: membuat atau merubah moda pemakai. +command.modeChannel=%S <channel>[ (+|-)<new mode> [<parameter>][,<parameter>]*]: Mengambil, menyusun atau merombak moda kanal. +command.msg=%S <nick> <message>: Mengirim pesan pribadi kepada pengguna (sebagai kebalikan dari pesan ke kanal) +command.nick=%S <new nickname>: Merubah nama samaran. +command.nickserv=%S <command>: Mengirim perintah ke NickServ. +command.notice=%S <target> <message>: Mengirim pemberitahuan ke pengguna atau kanal. +command.op=%S <nick1>[,<nick2>]*: Memberi status operator kanal pada seseorang. Anda harus menjadi operator kanal agar bisa melakukan hal ini. +command.operserv=%S <command>: mengirim satu perintah ke OperServ. +command.part=%S [message]: Meninggalkan kanal ini dengan pesan pilihan. +command.ping=%S [<nick>]: Menanyakan berapa banyak pengguna (atau server jika tidak ada pengguna) yang tertinggal, +command.quit=%S <message>: Memutus koneksi server, dengan pilihan pesan. +command.quote=%S <command>: Mengirim pesan belum terolah ke server. +command.time=%S: Menampilkan waktu setempat saat ini di server IRC. +command.topic=%S [<new topic>]: Membuat judul kanal. +command.umode=%S (+|-)<new mode>: membuat atau merubah moda pengguna. +command.version=%S <nick>: Meminta versi klien pengguna. +command.voice=%S <nick1>[,<nick2>]*: Memberi status kanal suara pada seseorang. Anda harus menjadi operator kanal untuk dapat melakukan hal ini. +command.whois2=%S [<nick>]: Meminta informasi pengguna. # LOCALIZATION NOTE (message.*): # These are shown as system messages in the conversation.

1 0

[translation/tor-messenger-ircproperties] Update translations for tor-messenger-ircproperties
by translation＠torproject.org 25 Sep '15

25 Sep '15

commit ba030347219d92da5782694889f7bf8ec29fef23 Author: Translation commit bot <translation(a)torproject.org> Date: Fri Sep 25 06:46:38 2015 +0000 Update translations for tor-messenger-ircproperties --- id/irc.properties | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/id/irc.properties b/id/irc.properties index cfbd862..52eae2e 100644 --- a/id/irc.properties +++ b/id/irc.properties @@ -47,13 +47,13 @@ ctcp.time=Waktu untuk %1$S adalah %2$S. # These are the help messages for each command, the %S is the command name # Each command first gives the parameter it accepts and then a description of # the command. -command.action=%S <action to perform>: Perform an action. -command.ctcp=%S <nick> <msg>: Sends a CTCP message to the nick. -command.chanserv=%S <command>: Send a command to ChanServ. -command.deop=%S <nick1>[,<nick2>]*: Remove channel operator status from someone. You must be a channel operator to do this. -command.devoice=%S <nick1>[,<nick2>]*: Remove channel voice status from someone, preventing them from speaking if the channel is moderated (+m). You must be a channel operator to do this. -command.invite2=%S <nick>[ <nick>]* [<channel>]: Invite one or more nicks to join you in the current channel, or to join the specified channel. -command.join=%S <room1>[ <key1>][,<room2>[ <key2>]]*: Enter one or more channels, optionally providing a channel key for each if needed. +command.action=%S <action to perform>: melakukan tindakan +command.ctcp=%S <nick> <msg>: mengirim CTCP ke nama samaran. +command.chanserv=%S <command>: mengirim perintah ke ChanSrv. +command.deop=%S <nick1>[,<nick2>]*: Membuang status operator kanal seseorang. Anda harus menjadi operator kanal untuk melakukan hal ini. +command.devoice=%S <nick1>[,<nick2>]*: Membuang status kanal suara seseorang, mencegahnya berbicara jika kanal dimoderasi (+m). Anda harus menjadi operator kanal untuk melakukan hal ini. +command.invite2=%S <nick>[ <nick>]* [<channel>]: mengundang satu atau lebih nama samaran untuk bergabung denganmu di kanal ini, atau bergabung dengan kanal tertentu. +command.join=%S <room1>[ <key1>][,<room2>[ <key2>]]*: Memasukan satu atau lebih kanal, optional menyediakan kunci kanal masing-masing jika dibutuhkan. command.kick=%S <nick> [<message>]: Remove someone from a channel. You must be a channel operator to do this. command.list=%S: Display a list of chat rooms on the network. Warning, some servers may disconnect you upon doing this. command.memoserv=%S <command>: Send a command to MemoServ.

1 0

[tor/master] Add test-network.sh to EXTRA_DIST
by nickm＠torproject.org 25 Sep '15

25 Sep '15

commit 7b1d2726e4eeebb2b92f7983da455b81f55c4cc8 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Sep 24 19:38:50 2015 -0400 Add test-network.sh to EXTRA_DIST --- src/test/include.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/test/include.am b/src/test/include.am index 9f142d5..a37fe23 100644 --- a/src/test/include.am +++ b/src/test/include.am @@ -194,4 +194,5 @@ EXTRA_DIST += \ src/test/zero_length_keys.sh \ src/test/test_keygen.sh \ src/test/test_zero_length_keys.sh \ - src/test/test_ntor.sh src/test/test_bt.sh + src/test/test_ntor.sh src/test/test_bt.sh \ + src/test/test-network.sh

1 0

[tor/master] Make our digest-mismatch warnings a touch better
by nickm＠torproject.org 24 Sep '15

24 Sep '15

commit 8d6bb3a5595cd4b9dbc175a43b93e8d7ca332635 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Sep 24 17:45:29 2015 -0400 Make our digest-mismatch warnings a touch better --- src/or/routerlist.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/or/routerlist.c b/src/or/routerlist.c index 8bd8039..03729bd 100644 --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@ -4964,6 +4964,12 @@ routerinfo_incompatible_with_extrainfo(const routerinfo_t *ri, goto err; } + if (!digest256_matches && !digest_matches) { + if (msg) *msg = "Neither digest256 or digest matched " + "digest from routerdesc"; + goto err; + } + if (!digest256_matches) { if (msg) *msg = "Extrainfo digest did not match digest256 from routerdesc"; goto err; /* Digest doesn't match declared value. */

1 0

[tor/master] Merge branch 'bug17149'
by nickm＠torproject.org 24 Sep '15

24 Sep '15

commit 9febbf0451ecd60fb78c1b4e5632d09bf3403fcc Merge: 4b2ae5a e62fe2f Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Sep 24 17:19:21 2015 -0400 Merge branch 'bug17149' src/or/policies.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

1 0

[tor/master] Put braces around reject-lines for IPv6 addrs
by nickm＠torproject.org 24 Sep '15

24 Sep '15

commit e62fe2f02d38958516026ce9042c3d1542b6c0a6 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Sep 24 16:51:25 2015 -0400 Put braces around reject-lines for IPv6 addrs Fixes bug 17149; bug not in any released Tor. --- src/or/policies.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/or/policies.c b/src/or/policies.c index 86eedd2..9c858ec 100644 --- a/src/or/policies.c +++ b/src/or/policies.c @@ -1037,7 +1037,7 @@ policies_parse_exit_policy_internal(config_line_t *cfg, smartlist_t **dest, "address", fmt_addr(ipv6_local_address)); } else { char buf6[POLICY_BUF_LEN]; - tor_snprintf(buf6, sizeof(buf6), "reject %s:*", + tor_snprintf(buf6, sizeof(buf6), "reject [%s]:*", fmt_addr(ipv6_local_address)); append_exit_policy_string(dest, buf6); log_info(LD_CONFIG, "Adding a reject ExitPolicy '%s' for our " @@ -1075,7 +1075,7 @@ policies_parse_exit_policy_internal(config_line_t *cfg, smartlist_t **dest, * address */ if (ipv6_local_address == NULL || !tor_addr_eq(ipv6_local_address, a)) { - tor_snprintf(bufif, sizeof(bufif), "reject6 %s:*", + tor_snprintf(bufif, sizeof(bufif), "reject6 [%s]:*", fmt_addr(a)); append_exit_policy_string(dest, bufif); log_info(LD_CONFIG, "Adding a reject ExitPolicy '%s' for a local "

1 0