- tor-dev - lists.torproject.org

The consequences of key compromise (or the reasons for changing)
by Watson Ladd 04 Nov '11

04 Nov '11

Dear all, Recently Zooko forwarded an email asking why we have to migrate. I am outlining the reasons in this email why I believe Tor needs to use stronger cryptography very soon. Tor currently uses RSA-1024 bit keys for OR public identities and 1024-bit Diffie Hellman for the negotiation of keys protecting circuits. It also uses SHA-1 for a hash in serveral applications, including key fingerprints. When deciding if these are adequate it is necessary to think about what compromise gives an attacker and what it costs to compromise Tor cryptography. We are aiming to protect users from TLAs with ASICs. Directory keys are 3024 bit RSA. Compromising a directory key is sufficient to generate directories containing fake entries, and thus break the anonymityof all users who see the fake directory. In the event of a compromise, Tor would be unusable until a new version is put out with a longer key length and new directory keys. But these are long keys. However, the keys that actually sign the directories are 1024 bits, but rotate every 3 months. OR keys are also 1024 bit RSA. Compromise of an OR key enables impersonation of the OR to an OP. Combined with fun and games with BGP it enables impersonation of an OR to other ORs, which can direct significant traffic to the fake OR. Detection is likely as the real OR will notice various refusals to connect by other OR to whom it is not connected. And if you can break the directory key why bother with ORs. Hidden services are also identified by 1024 bit RSA keys. At the circuit level DH keys are 1024 bits. An attacker who compromises these can read data intended for further down in the circuit. In particular they can determine the rest of a circuit if they are the first node. There is also the issue of keysize. A Tor cell is 512 bytes long. Thisis sufficent for only 4 keys, if we pack them very tightly. Smaller keys could enable fast circuit initiation or other cool tricks we cannot use today. So, how strong or weak are RSA-1024 and DH-1024 currently? We are using DH over F_q* where q = a big prime. For DH the best known algorithm is the index calculus. This attack proceeds in 3 steps. The first step, which can be spread over multiple keys is the collection of relations among a factor base, usually of small primes. The second step, again spread over multiple keys, is solving the linear system of equations from the first step. The third step is fast and key specific: given an element h,and generator g we attempt to factor g^s*h over the factor base. The general number field sieve is a very similar algorithm for factoring. It is more complicated but again relies on finding smooth numbers and factoring them with respect to a factor base of small primes. Currently the complexity of these algorithms is L_n[1/3,\sqrt^3_{\frac{64}{9}}]for GNFS and L_n[1/2,c] for index calculus. (From wikipedia). Sadly the sieving stepscan be done very well on special hardware. TWIRL, a specialized hardwaredevice designed by Adi Shamir and Eran Tromer is believed by Shamir and Tromer to be capable of factoring a 1024-bit RSA key in a year at a cost of $10 million dollars. To break 10 directory keys in 3 months is 10 times as many keys, and 4 times the speed. That will be $400 million dollars. That is half the cost of Golden Shield for a year: an amount of money that is not ludicrous. And such a machine once built can crack the next 10 keys for free. The cost is design and fabrication of this device: power is comparatively cheap. Of course, such a machine would be unsuited to other bit sizes. If the attacker instead decides to find a discrete logarithm base for DH over 1024, then they will have the ability to break DH-1024 fairly quickly. I haven't seen a good estimate for the time it would take to do this, but it will be a bit more. It will not be much more. And it will be a total break: once a factor basis is found discrete logs are very fast. So an adversary can spend more time and still be happy with the results. So it isn't just directory signing that is an issue but the link protocol as well. And $400 million is a lot. But when you are the Golden Shield director and someone says "for $400 million we can break Tor for a long time" that is not entirely out of the picture. As technology for ASIC fabrication gets better, this price drops. As GNFS gets better it also drops. As index calculus gets better it drops. And as Balmol's cost disease drives up the cost and budget of Golden Shields regular activities, the price drops. Sincerely, Watson Ladd

3 2

[idle speculation] Combining bridge partioning and limiting directory trust?
by Watson Ladd 04 Nov '11

04 Nov '11

Dear all, I read arma's blog entry calling for someone to see if limiting zig-zag attacks would harm anonymity. Well, I don't have an answer, but I did notice that we could increase the number of bridge authorities by having each bridge authority take a distinct subset of bridges to hand out, and then implementing a honest forwarder that forwards an email asking for bridges to a bridge authority based on some hash function of the requesting gmail address. Compromising an authority results in those bridges being cut off, but only a subset of users are affected. This also prevents zig-zag attacks: there are no clients who see bridges in two distinct authorities mandate. Unfortunately this only works if bridges are careful not to be listed by multiple authorities. Sincerely, Watson Ladd -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin

1 0

patch to torspec that seperates out the crypto.
by Watson Ladd 03 Nov '11

03 Nov '11

Dear all, Here is a patch that removes crypto cruft from torspec.txt. It does make torspec unusable because we haven't written crypto.txt yet. In the process I noticed a few things I cleaned up, and also noticed that RELAY_EXTEND cells have to be understood by both ORs, which could be an impediment to migration. Sincerely, Watson Ladd

2 1

Leap Seconds
by Watson Ladd 03 Nov '11

03 Nov '11

Dear All, What precisely is the timestamp? Right now it says "number of seconds since the Unix epoch" which leaves open TAI, UTC, or UT1. We probably are using UTC so I should say that, but I just want to make sure. Sincerely, Watson Ladd

1 0

Rewriting tor-spec to be crypto agnostic
by Watson Ladd 03 Nov '11

03 Nov '11

Dear all, I'm busy rewriting tor-spec (well, mangling it) to be crypto agnostic (read: shoving hard choices to later). In the process I am trying to make it a bit clearer. The spec seems to hold open the possibility that nodes not on the two ends of a circuit can send recognized RELAY cells (the role of OPs in processing RELAY cells is also unclear). Is this the case, or is this not supported given that there are no points at which the spec explicitly calls for them to be sent? Sincerely, Watson Ladd

2 1

A concrete proposal for crypto (at least part of it)
by Watson Ladd 02 Nov '11

02 Nov '11

Dear All, Rather then get further sucked into a debate that is producing more heat then light about Wegman-Carter, I've decided to make a concrete proposal for how Tor can better protect its streams from manipulation. Right now Tor encrypts the streams of data from a client to a OR with AES-CTR and no integrity checks. I propose the following: On establishment of a new connection between a client and an OR (using either the Goldman et al paper or ephermental DH) the client and the OR derive a single 16-byte K. The client has an 8 byte counter which starts at 1, the client counter, the OR an 8 byte counter which starts at 0, the OR counter. Each cell from the client to the OR is protected by AES-GCM defined as in the NIST standard, with a 4 byte string "TorC" being used to make our counter 12 bytes. (If you read the standard you will see this is the method for generating nonces recommended). The counter is incremented by 2 each time a packet is sent. Under no circumstances can it go backward. Under no circumstances does an OR or Client accept a packet that reuses a nonce (nonces should be sent along if we make transport unreliable). Under no circumstances are more then 2^64 packets sent. Under no circumstances are packets longer then 2^32 bytes. Following these rules an attacker who sends 2^64 forgery attempts has probability 2^-36 of successfully forging one message. If we limit the attacker to 2 billion forgery attempts (forgery must be online) then the probability of forgery is 2^-68. I think we can live with that. These numbers come from http://cr.yp.to/antiforgery/securitywcs-20050227.pdf. Note that these numbers assume AES is secure, and are theorems if AES is secure. This proposal is independent from the establishment of streams. This proposal eliminates issues relating to an intermediate node flipping bits in an HTTP request, thereby tagging the traffic, amongst other evil things manipulation can do. If we want more performance the evaluation of a polynomial over GF(2^128) can be replaced by GF(2^130-5), or AES could be replaced by xsalsa20, and the nonce lengthened. Sincerely, Watson Ladd --- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin

4 5

SHA-3 isn't looking so hot to me (was: Draft sketch document with ideas for future crypto ops)
by Zooko O'Whielacronx 02 Nov '11

02 Nov '11

In reference to: https://lists.torproject.org/pipermail/tor-dev/2011-November/002999.html > FOR A HASH FUNCTION: SHA256, switching to SHA3 in 2012 when it comes > out. It might be worthwhile waiting for SHA3 in most places and > skipping over the SHA256 stage entirely. The AES contest resulted in a cipher that was much faster than 3-DES and probably safer as well. It is looking like the SHA-3 contest will result in a hash function that is slightly slower than SHA-256, and not obviously safer either! There are some details about the performance issue: the most efficient SHA-3 candidates are faster than SHA-256 on large, expensive, powerful x86_64 servers, and they are faster on long messages (more than a couple thousand bytes). This almost certainly doesn't matter to the tor project! (Nor, I suspect, to almost anyone else.) I'm guessing (sorry for my ignorance about these important facts) that tor uses secure hashes in two ways: first as the "nails" holding the crypto together, such as in commitments, key-derivation, HMAC, and so forth, and second to integrity-check the bulk data in chunks that are approximately "packet sized" -- a few thousand bytes. On a powerful x86_64 server for 4096 bytes [1], the most efficient SHA-3 candidate (Blake-256) takes about 33,000 cycles and SHA-256 takes about 73,000. So the difference is about 40,000 CPU cycles. Assuming that all of this is done on a single core of a 3.4 GHz chip, that means SHA-256 takes about 12 microseconds longer to hash this 4096-byte packet. I don't think that makes much of a difference to anyone. You'd have to process data at more than 190,000,000 bytes per second before this would exceed your ability to do it that with SHA-256 on a single one of the 4 cores that come in that chip. Is that a realistic amount of data for a single tor node to process per second in forseeable future? (Honest question: I have no idea if it is although I would guess not.) Anyway, if you *do* want to process more than 190 MBytes/s on a fancy server in the next few years, you can probably just use more than one of its cores. On the other hand, what if someone wants to deploy Tor in a 32-bit ARM CPU such as in a Freedom Box or in a smart phone. When it is doing 4096-byte packets, Blake-256 is actually less efficient than SHA-256 by about 36,000 cycles. Since the chip in that device is running at a slower clock rate (maybe 800 MHz), then it takes 45 microseconds more to hash that 4096-byte packet with Blake-256 than with SHA-256. If you hash those packets with the slower of the two algorithms (Blake-256), you could handle about 25 MBytes/s using 100% of the only CPU in the system. If you used SHA-256 instead you could handle 35 MBytes/s. If you are using say, 90% of that CPU for other tasks. such as playing a game or watching a movie while running Tor in the background, or even playing a movie which is streaming in over Tor live, then this is the difference between being able to process 2.5 MBytes/s (Blake-256) and 3.5 MBytes/s (SHA-256). That seems be a difference that might matter in practice, unlike the performance difference on expensive x86_64 servers. Okay, what about the "not obviously safer" part? I think there was a bit of a panic a few years ago, in the aftermath of Wang Xiaoyun's breakthrough on SHA-1, that someone might suddenly figure out a way to find collisions in SHA-256. This panic spurred the creation of the SHA-3 project. However, it seems like in the intervening years nobody has published any techniques that really threaten the safety of SHA-256, so now I'm personally no longer so confident that SHA-3 candidates like Blake will endure longer before someone finds a fatal flaw in them than SHA-256 will. SHA-256 has endured substantial analysis by experts for about a decade now. Blake and its fellow competitors have had about three years. I'm not saying that I'm confident that SHA-256 will outlast Blake! I'm saying it could go either way. Bottom line: I would probably move ahead toward SHA-256 and let SHA-3 mature for a few extra years before planning to move to that, if I were you. Regards, Zooko [1] http://bench.cr.yp.to/results-hash.html

5 8

Draft sketch document with ideas for future crypto ops
by Nick Mathewson 02 Nov '11

02 Nov '11

Here's an early draft document trying to sketch out the parameters for migrating to better crypto ops and designs in the future. Comments are invited, even comments of the form "you will need to be much more specific here before I can say anything sensible." This is proposals/ideas/xxx-new-crypto-sketch.txt in the torspec repository. Title: Design sketch for new crypto ops Date: 31 Oct 2011 Author: Nick Mathewson 0. Overview The point of this document is to discuss what crypto we ought to be using. See "Initial Thoughts on Migrating Tor to New Cryptography" from last year for general guidelines and principles. In broad strokes, the parts of our crypto are: IDENTITY KEYS AND FINGERPRINTS Addressed here in Section 2. LINK CRYPTO (TLS) -- Addressed in proposals 176, 184. We say a little here in section 5, though. CREATE/EXTEND CRYPTO -- Addressed in xxx-ntor-handshake.txt and rransom's EXTEND draft at [*] and subsequent discussion on the tor-dev mailing list. Not considered here. RELAY CRYPTO Addressed here in Section 6. DIRECTORY SYSTEM Addressed here. HIDDEN SERVICE SYSTEM Addressed in a forthcoming document by rransom. [*] https://lists.torproject.org/pipermail/tor-dev/2011-March/002547.html 1. Base algorithm choice There seem to be two main candidate algorithms for signatures: RSA with big keys (hereinafter "RSA>1024"); and Ed25519, which is DSA with the sharp edges filed off on an Edwards curve related to DJB's Curve25519. We can look at other ECC groups too. {But see ECC Notes in 1.1 below.} FOR DIFFIE-HELLMAN: Curve25519 seems like a decent choice; failing that, one of the NIST P-groups. Failing that, DH on Z_p with big groups (hereinafter "DH>1024"). {But see ECC Notes in 1.1 below.} FOR A HASH FUNCTION: SHA256, switching to SHA3 in 2012 when it comes out. It might be worthwhile waiting for SHA3 in most places and skipping over the SHA256 stage entirely. FOR A STREAM CIPHER: AES-CTR is in one sense a conservative choice inasmuch as AES is well-analyzed, but AES's well-known issues with cache-based timing attacks are pretty worrisome. We can mitigate that some by using random secret IVs for AES-CTR, so that we will be encrypting neither attacker-chosen nor attacker-known plaintext with our AES cipher, but that's a bit kludgy. There are also supposed to be time-invariant implementations that use Intel's AESNI instructions where available, and time-invariant implementations that use bit-slicing. Salsa20 is what rransom likes these days, but IMO we aren't competent to tell whether it looks good or not; the existing attacks against it don't look like very bad news to me, but who knows whether it's getting enough attention that we can read. See also ChaCha; see also the other eSTREAM winners/finalists; see also SHA3 if the SHA3 winner specifies a way to use it as a stream cipher, or specifies an underlying stream/block cipher. If we're feeling cautious, we could run two independently-keyed stream ciphers and xor their streams together. FOR A RANDOM NUMBER GENERATOR: We currently use OpenSSL seeded with RAND_poll and with platform entropy. OpenSSL uses a message-digest- based algorithm from SSLeay (See http://linux.die.net/man/3/sslrand for the ugly details.) The platform entropy management can be messy, obscure, or both. I suggest that: * We should seed our PRNG with more entropy sources if we can find some promising code with an appropriate license * Instead of just using OpenSSL's PRNG, we should use OpenSSL's MD-based PRNG xor'd with some other good PRNG. (Fortuna, maybe. Is there a combine operation better than xor? See also SHA3 if the SHA3 winner is one that specifies a PRNG mode of operation.) * We should consider splicing this combined-stream PRNG into OpenSSL as the RNG it uses for SSL and key generation. * We should re-seed the RNG before and after very sensitive operations, like private key generation. 1.1. ECC notes ECC is the brave new[*] crypto of the future! It's faster[**] than doing crypto in Z_n (as we do for RSA and DH now) for equivalent levels of security, and the resulting outputs are much shorter. As near as I can tell as a layman, Certicom is muddying the waters as much as possible wrt claiming that it's nigh-impractical to deploy ECC without licensing their patents. This is rather like the silliness that PKP used to pull back in the day, where they claimed that their patents covered not only the existing public key cryptography algorithms, but also the very idea of public key cryptography itself. DJB claims that for every patent he's aware of, either that patent doesn't cover his code, or that patent is invalid because of prior art. I'm not going to try to evaluate these claims, since I'm not supposed to be reading patents for typical "let's avoid the appearance of knowing infringement" reasons. But before we dive into the world of ECC, we should see if we can ask any friendly patent attorneys and ECC experts for a second or third opinion here. I note in passing that nearly all of the patents that DJB mentions in his list would appear to expire over the next 12 months or so. Additionally, there are ECC groups out there less fast than DJB's, but more widely available and analyzed. We should consider some of those too. One final issue to investigate is whether using these algorithms will make any major free software distribution decide not to include us. I seem to recall seeing that one or two of the big ones had at one point decided to ship OpenSSL only with ECC disabled, either because of real patent concerns, or because of an opinion that the Certicom license for ECC use in TLS was problematic for free software, or something like that. We should check that out. [*] Actually, it's older than onion routing, and older than some members of the Tor Project. [**] Actually, because of the common practice of choosing a small-ish prime value (65537) for e in RSA, RSA public key operations can be a little faster than equivalent-security ECDH or ECDSA operations. The private key operations in RSA are still much much slower. 2. New identities Identity keys and their fingerprints are used: - To sign router descriptors. - To identify nodes in consensus directories. - To make sure we're talking to the right node in the link handshake. - To make sure that the extending node is talking to the right next node when sending an extend cell. - To identify particular nodes in the hidden service subsystem. - To identify nodes in the UI in various places. - Internally, to identify a node uniquely in the codebase. - To determine which part of the circuit ID space to use on a Tor instance's links. 2.1. New identities, option 1: "RSA>1024, slow migration" In this option, we use RSA for identity keys indefinitely. Nearly all operations done with an identity key are signature checking; signing happens only a few times an hour per node even with pathological cases. Since signature checking is really cheap with RSA, there's no speed advantage for ECC here. (There is a space advantage, since the keys are much smaller.) The easiest way to migrate to longer identity keys is to tell all Tors to begin accepting longer identity keys now, and to tweak all our protocols so that longer RSA identity keys are understood. We should then have a pair of parameters in the consensus that determines the largest and smallest acceptable identity key size in the network. Clients and servers should reject any keys longer or shorter than specified. Once all versions of Tor can accept long identity keys, we raise the maximum size from 1024 to somewhere in the 2048-4096 range. 2.2. New identities option 2: "RSA>1024, faster migration" In this option, we use RSA for identity keys indefinitely as above. But we allow nodes to begin having longer identities now, even though older Tors won't understand them. This implies, of course, that every such node needs to have at least 2 identities: one RSA1024 identity for backward compatibility, one RSA>1024 identity for more secure identification. We would have these identities cross-certify as follows: All keys would be listed in the router descriptor. RSA>1024 keys would be called something other than identity-key, so as not to confuse older clients. A signature with the RSA>1024 key would appear right before the current RSA1024 signature. This way, signed material would include both keys, and would be signed by both keys. [In other words, descriptors would look something like: router foo... ... identity-key -----BEGIN RSA KEY----- 1024-bit RSA key here -----END RSA KEY----- ext-identity-key -----BEGIN RSA KEY----- 3072-bit RSA key here -----END RSA KEY----- ... ext-signature -----BEGIN SIGNATURE----- signature of everything through "ext-signature\n", using the long key -----END SIGNATURE----- router-signature -----BEGIN SIGNATURE----- signature of everything through "router-signature\n", using the short key -----END SIGNATURE----- ] See "UI notes" in the "new fingerprints" section below for some of the implications of letting nodes have multiple identity keys. We'll need to advertise these new identities in consensus directories too; see 4.2 below for more info there. 2.3. New identities option 3: "RSA>1024 and/or Ed25519, faster migration" As in option 2 above, but new keys can also be Ed25519. If we expect that not all installations will allow Ed25519 (see "ECC Notes", section 1.1), we'll need to say that every server with an Ed25519 key must also have an RSA>1024 key. 2.4. Implications for current use of identity keys Let's review our use of identity keys again and make sure that we can handle all of them with the ideas above. - To sign router descriptors. We discussed this in 2.2. - To make sure we're talking to the right node in the link handshake. The current v3 link handshake can handle presenting multiple identity certificates in the CERT cell. We should consider ourselves to be connected to a node with identity X if _any_ of the identity certificates that it presents in its authenticated CERT cell has identity X. To handle EXTEND cells correctly, we should verify every identity we can. - To make sure that the extending node is talking to the right next node when sending an extend cell. The new extend cell format needs to allow the client to tell the extending node about some identity for the destination node that the extending node will be able to understand. This is a capability of the extending node that the client needs to be able to check. (Also, the extend cell needs to hash that identity in a form the extending node can understand, but that's a fingerprint issue.) - To determine which part of the circuit ID space to use on a Tor instance's links. We can continue to use RSA1024 identity key comparison here by default. We can also use some other parameter of the v3 handshake, or introduce a new link protocol where if the initiator authenticates, the initiator always gets the low circIDs and the responder always gets the high ones. - To identify nodes in consensus directories. - To identify nodes in the UI in various places. - Internally, to identify a node uniquely in the codebase. See sections 3 and 4 below. - To identify particular nodes in the hidden service subsystem. Out of scope. 2.5. Migrating away from short ID keys entirely Eventually, no version of Tor that requires 1024-bit identity keys will remain. When that happens, we should stop using them entirely. That means that if we take any path other than the "slow migration" path of 2.1, we'll need to make everything that looks at a node's identity also accept nodes with _only_ a RSA>1024/Ed25519 identity. At the directory service level, we should have an option to allow nodes without RSA1024 identity keys (off until all clients and nodes accept new identity keys). 2.6. Selective correctness attacks For any scheme based on having multiple signature types on a router descriptor or other document, an attacker could mount a partitioning attack by making a document which older clients will accept but newer clients will reject. It's easy to prevent this at the consensus step: directory authorities MUST NOT accept any descriptor unless all clients will be able to verify it. For bridge descriptors, we need to investigate more carefully. 3. New fingerprints Right now we compute fingerprints by taking the SHA1 hash of an ASN1 encoding of the RSA1024 identity key. We encode this in hex almost everywhere, and sometimes prefix it with a $. I propose that fingerprints of the future be determined by taking a digest using SHA256 or SHA3 of: "Hash Algorithm Name", "Key Type Name", encoded key When representing these internally, we should include the hash algorithm that was used. When representing them in the UI, we should use the notation %b64, where b64 is a base-64 encoding, omitting the trailing =s. (Other plausible characters to use are @, ?, +, ~, =, etc. I like %, but can be persuaded. Bikeshed bikeshed bikeshed.) Since 43 base-64 characters is enough to represent a 256-bit digest, with 2 bits left over, I propose that the b64 value encode hh | D(hash algorithm name, key type, encoded key) where hh is a 2-bit value, with one of the following values: 00 -- sha256 01 -- sha3 10 -- to be determined 11 -- reserved. We should investigate in the interface whether it's plausible to allow a prefix of a node ID where the full ID would otherwise be required. That seems risky for short prefixes, though. 3.1. How many fingerprints is that anyway?! Suppose that we allow sha256 and sha3 as hash algorithms, and we allow each node to have 3 identity keys: one RSA1024, one RSA>1024, and one ECC. Then we would have 7 fingerprints (6 plus the legacy SHA1(RSA1024) fingerprint), for a total of 20+6*32==212 bytes per node. It's not a horrible problem to accept them all in the UI, but the UI isn't the only place that needs to know fingerprints. Instead, let's say that RSA1024 identities are only identified with SHA1 hashes. This limits our fingerprint load to a more manageable 20+32*2 == 84 bytes per node. Still not great, though. 3.2. What does this imply for the UI? In the UI we'll lose the property that no node has more than one fingerprint: I do not believe that this actually hurts us. 3.3. Implications for directory information Clients must know a hash for each node's identity key, or else they can't make an authenticated connection to the node or tell ORs how to extend to the node. This means that if client Alice wants to connect to node Bob, Alice must have a fingerprint of Bob's ID key such that she understands the ID key type and the fingerprint algorithm. If Alice wants to extend from Bob to Carol, she must have a fingerprint of Carol's ID key such that Bob understands the ID key type and the fingerprint algorithm. So for every node, Alice must not only know a fingerprint that *she* can use for that node, but also a set of fingerprints such that every node can understand at least one fingerprint in the set. This implies a proliferation of fingerprints! We should tread carefully here. To prevent proliferation, the easiest solution is not to add too many new types and to have a good plan for retiring older types. 3.4. Implications for EXTEND cells As mentioned in 3.3, when a client Alice tells node Bob to extend to node Carol, she needs to give Bob a fingerprint for Carol that Bob will understand: one where Bob understands the digest algorithm, and understands the identity key type. There are two ways we can do this: 1) Alice's EXTEND cell contains every fingerprint for Carol that Alice knows about. Bob treats the cell as valid if every one he can verify is correct. 2) Alice knows which fingerprint types Bob understands (either via his version, or something else in his directory info). She selects a fingerprint for Carol using the best one of these types. The first seems more robust to me, if we have space for enough bytes. If we proliferate too many types, though, we'll need to do the second. 4. Directory changes 4.1. Better cross-referencing In some places, directory objects cross-reference one another by SHA1 hash. They should use a better hash algorithm instead. This does make problems in a few cases. Router descriptors and extrainfo descriptors: One problematic case is in determining node families. If node A and node B want to list each other as being in the same family, they need to do so in a way that clients can interpret. That could mean listing SHA1-RSA1024 fingerprints so old clients understand, AND new fingerprints for security. (But *that* could create interesting partitioning attacks wherein your family looks different depending on who's looking.) Solution: we need to move the responsibility for combining node families into the consensus voting process, so clients don't need to understand the cross-reference types themselves. Another case is in certifying extrainfo documents from descriptors. For that, we can list multiple extrainfo digests, either on the extrainfo line, or on additional lines. Voting and consensus documents: Adding more fingerprints in votes isn't a problem; votes are a tiny fraction of authority bw usage. Adding more hashes is easy. For consensus documents, we ought to have flavors that you can download depending on what set of fingerprint types you understand. For integrity purposes, consensuses can refer to microdescriptors or descriptors by any digest type that the client understands. But for downloading purposes, the digest type must be one that directory caches also support: see 4.4. 4.2. More fingerprints Because extending from node A to node B requires that we have node B's fingerprint in a way that node A will understand, it is not enough to get a set of identity fingerprints for each node in the format that the client likes best -- see 3.3 and 3.4 above. So every flavor of consensus we serve needs to include a node identity in a format the client understands, and node identities in formats such that every node will understand at least one. 4.3. An option: compound signatures on directory objects In Tor 0.2.2.x and later, when we check a signature on a directory object (not including hidden service descriptors), we only look at the first DIGEST_LEN bytes of the RSA-signed data. Once 0.2.1.x is obsolete, or on any types of signatures not checked in 0.2.1.x, we can use the rest of the space. (We're using PKCS1 padding on our signatures, which has an overhead of 11 bytes. Signing a SHA1 hash with a 1024-bit key therefore leaves 128-11-20==97 more bytes we could use for a SHA2 or a SHA3 hash.) 4.4. Downloading by digest We should have directory caches support downloading objects by more hash types. Right now, descriptors are downloaded by their SHA1 hashes and microdescriptors by their SHA256 hashes. This is okay for now, but once SHA3 is out, we should support downloading all of these by SHA3 digest. 5. Link crypto changes Currently we use TLS. That's fine. We should however look to longer link keys, bigger DH groups, etc. Once TLS versions 1.1/1.2 are available in OpenSSL, we should move to use them, I think. We should also look into how quickly we can deprecate TLS 1.0 and SSL <= 3 usage. 6. Relay crypto changes There are a few things we might want out of improved relay crypto. They include: - Resistance to end-to-end bitwise tagging attacks. - Better resistance to malleability. - If using counter mode, no block-cipher operations on any value known to the attacker. I'll try to provide these in increasing order of difficulty. None of these is necessarily correct; I should look for a security proof or a better construction for any that we seem likely to use. Rationales: Our existing malleability resistance is a kludge. Doing no block-cipher ops on attacker-known values increases our security margins a little. Our arguments about tagging attacks hold that an attacker who controls both ends has plenty of ways to win even if tagging attacks are foiled; nonetheless, most of these ways are technically slightly more difficult than xor-based tagging, and it could be useful to boost our defense-in-depth a little bit, just in case other active end-to-end attacks turn out to be harder than we'd thought. 6.1. Option 1: Use AES-CTR in a less scary mode When doing key expansion, in addition to establishing Kf, Kb, Df, and Db, also establish IVf and IVb. Use the current relay crypto, except instead of starting the counters at 0, start them at IVf and IVb. This way, an attacker doesn't have any known plaintexts to work with, which makes AES a little more robust. 6.2. Option 2: As 1, but tagging attacks garble the circuit after one block. Keep an HMAC of all previously received encrypted cells on a circuit. When decrypting a cell, use this HMAC value to determine the first 64 bits of the counter; increment the low 64 bits of the counter as usual. This way, if an adversary flips any bits before passing the stream through an honest node, no _subsequent_ block will be recoverable. To prevent any part of the stream from being re-used, close any circuit if the low 64 bits of the counter would ever wrap (that is, around 295 million terabytes). (If we're using a stream cipher with fast re-key, then we can just have the key used for each block be an HMAC of all previously received ciphertext.) 6.3. Option 3: As 1, but tagging attacks garble the circuit in the same block. Use a large-block cipher mode, such as BEAR or LIONESS (depending on whether we need a PRP or SPRP). Base the key material for each block on an HMAC of all previous blocks' ciphertexts. This way, if an adversary makes any alteration in a block, that block and all subsequent blocks will be garbled. It's more expensive than 2, though, especially if we need to use a LIONESS construction. {I considered IGE here, with a trick where odd-numbered nodes on a circuit start from the front of the block and even-numbered nodes start from the end, but it didn't seem much better. We should investigate relative performance, though.} 6.4. Option 4: Shall we have middle nodes be able to fast-stop bad data? In all the above options, if a cell is altered, the middle node can at best turn that cell and the rest of the cells on the circuit into garbage, which the last node won't deliver (if honest) or can't deliver (if dishonest). Might we prefer to do as in mixnets, and have nodes kill circuits upon receiving altered cells? It's not such an obvious improvement. Including more MACs is more expensive in per-cell overhead. The attacks that we would foil this way but not with Option 3 are not so much better than the the passive or timing-based-active end-to-end attacks that would still remain. Consider that if option 3 is in place, an end-to-end attacker who wants to do a tagging attack at one node can garble the rest of the circuit and see if the output is garbled at the exit node. But such an attacker could just as easily close the circuit at one of those nodes and watch for a corresponding close event, or even better -- simply pause traffic on that circuit for a while and watch for a corresponding gap at the exit. The only advantage of the garbling attack would be that garbled cells are presumably rarer than circuit closes or traffic pauses, and thus easier to use to distinguish target circuits. But that's still questionable: the other attacks win fine, and the pause attack doesn't risk detection as much. So why might we want to do this? First, the overhead doesn't need to be as bad as you might first expect (see below). Second, it would be nice to increase the security margin as much as possible: "attacks only get better". So let's figure out how it would look. To do this one, we'd want to have outgoing and incoming circuits treated differently. Incoming cells would get decrypted as in 1 above, except that we'd have a MAC on them. For outgoing cells, each node would check that the first N bytes of the cell match a MAC of all data seen so far, *including the rest of the cell*. They'd then remove the first N bytes, re-pad the cell with bytes from a PRNG, and decrypt the resulting re-padded cell. (This is basically how mixmaster works, and how mixminion works in the common case.) The space overhead here is kind of large: N bits per cell per node. In the most paranoid case, if we used 256-bit HMACs on 3-node paths, that's 96 bytes per cell, which is more than 20% of the total length. But we can probably do better if we let the CREATE operation also tell the node some N to check. For example, the first node doesn't need to check any bits. The second and third nodes could check 64 bits apiece; that only has 16 bytes overhead total, and high probability of catching any changes. (Birthday attacks don't matter here, and an attacker who mounts this attack for long enough to accidentally find a 64-bit MAC will break so many circuits in the process as to become totally unreliable.) All of this leaks the path lengths and position on the path to various nodes. We might open ourselves up to partitioning attacks if different clients choose different numbers of bits. What's more, we might leak the length of the path to the last node by how much junk there is at the end of the cell. So we'd need to be careful! Here's a simple construction for this format, to be concrete: The CREATE operation's KDF produces the following outputs: Kf, IVf (stream cipher key and IV for forward direction) Kb, IVb (stream cipher key and IV for reverse direction) Mf (MAC key for forward direction) Mb (MAC key for reverse direction) SEEDf (PRNG key for forward direction) And it also sets the following user-selected parameter: MACBYTESf (an integer between 0 and 32 inclusive) MACBYTESb (an integer between 0 and 32 inclusive) CANEXIT (boolean: can we exit from this hop?) Let Kf[i], Mf[i], etc denote the parameter Kf, Mf, etc as shared between the client and the i'th node in its circuit. Relay cells sent towards the client have the following plaintext format: Body: Content: Relay Command [1 byte] StreamID [2 bytes] Length [2 bytes] Data [Up to CELL_DATA_LEN-5-MACBYTESb bytes] Padding [randomly generated as needed to fill the cell] MAC(All previous encrypted content + encrypted content, Mb)[:MACBYTESb] [MACBYTESb bytes] The originator of the client-bound cell encrypts the content with the next part of its Kb,IVb stream, then appends the MAC. Non-clients receiving a client-bound relay cell encrypt the entire cell body, MAC included, with the next part of the stream cipher that was keyed with Kb,IVb. When the client receives a relay cell body, it iteratively does: For node i in circuit from 1..N: Let cells_i = all previous cells which we previously decided were from node i, or relayed by node i, and let cellbody = the body of the cell, except for the last MACBYTESb[i] bytes, and let cellmac = the last MACBYTESb[i] bytes of this cell. If cellmac is nonempty, check wither cellmac = mac_received, where mac_received is the first MACBYTESb[i] bytes of MAC(cells_i | cellbody, Mb[i]). If so, this cell is from node i. If this cell is from node i, add cellbody to cells_i, then decrypt cellbody using the stream keyed with Kb[i],IVb[i]. Act on it as a relay cell. Otherwise add the entire cell to cells_i, and decrypt it, MAC included, with the stream keyed with Kb[i], IVb[i]. If no node sent this cell: it's junk and somebody is probably messing with us! Destroy the circuit. When the client *sends* a cell outbound to node N: Let cells[i] start at "" for all i in 1...N initially, and get updated as below. Let MACLEN = SUM(MACBYTESf[1...N]) Let Body = Relay Command [1 byte] StreamID [2 bytes] Length [2 bytes] Data [Up to CELL_DATA_LEN-5-MACLEN bytes] Padding [randomly generated, CELL_DATA_LEN-5-MACLEN-len(Data) bytes] Let PAD[i] = the next MACBYTESf[i] bytes from the PRNG keyed with SEEDf[i], for i in 1...N Let STREAM[i] = the next CELL_DATA_LEN bytes of the stream keyed by Kf[i],IV[i], for i in 1...N Let PADSEEN[1] == "" For i in 2...N: Let L = len(PADSEEN[i-1]) + len(PAD[i-1]) Let PADSEEN[i] = (PADSEEN[i-1] | PAD[i-1]) xor STREAM[i-1][CELL_DATA_LEN-L:] For i in N down to 1: Let Encbody = Body xor STREAM[i][:len(Body)] Let extra = "RECOGNIZED" if i == N, "OK" otherwise Let cells[i] = cells[i] | Body | PADSEEN[i] Let M = MAC(cells[i] | extra , Mf[i]) Let Body = M[:MACBYTESf[i]] | EncBody To receive an outbound cell: Let M be the first MACBYTESf bytes of the cell, let REST be the rest of the cell, and let "cells" be all previous cells on this circuit. If CANEXIT, and M = MAC(cells|rest|"RECOGNIZED", Mb)[:MACBYTESf], and MACBYTESf > 0, this cell is for us. If M = MAC(cells|rest|"OK", Mb)[:MACBYTESf], this cell is not for us, but is valid. Otherwise, destroy the circuit. Let PAD = the next MACBYTESf[i] bytes of the PRNG keyed with SEEDf, and decrypt REST | PAD using the stream cipher keyed with Kf,IVf. If this cell is for us, act on it as a relay cell. Otherwise, relay it. ANOTHER VARIANT: If we restrict MACBYTESf values to range 0..HL/2, where HL is the length of the MAC output, we can replace MAC(x | "RECOGNIZED")[:MACBYTESf] and MAC(x | "OK")[:MACBYTESf] with MAC(x)[:MACBYTESf] and MAC(x)[HL-MACBYTESf:] PICKING MACBYTESf,MACBYTESb. We don't need to worry about birthday attacks: Because we're using a MAC, only the parties who are making the MACs could try to do a brute-force search for a collision, but they have no reason to do so. If a collision occurs accidentally, an adversary can't substitute an earlier-seen cell for a later one with the same MAC, since the MAC covers not only the cell, but all previous cells on the circuit. So 16 bytes is about the most we should ever do, given our usual security parameters. Let me moot the number 8 for MACBYTESb. For outbound cells, for any hop we can exit from, choosing MACBYTESf=6 gets us the current security level. For the first hop, assuming we don't exit from it, choosing MACBYTESf=0 is totally safe, since the link crypto guarantees that nothing was corrupted on the way. In general, to prevent an end-to-end tagging attack, it seems sufficient to do something like setting MACBYTES=8 for the last hop, and MACBYTES=8 for one hop in the middle. OTHER VARIANTS: Can we combine this approach with one of the approaches in 2 or 3 above to ensure that if corrupt data passes (because of our use of truncated HMACs) it still corrupts the stream? Can/should we use GCM or something here instead of separate encrypt/hmac operations? It doesn't seem that GCM per se would apply without some tweaking, which we probably do not have the expertise to do. OVERHEAD NOTES: When computing additional overhead with this method, note that it lets us replace the old 4 byte "digest" field and the 2 byte "recognized" field. I note in passing that we need at most 9 bits for the length field, and at most 6 bits for the command field, yet we're using a total of 3 bytes for those 15 bits. That's an opportunity to save another byte. ACKS Lots of the good ideas and concerns here are due to Robert Ransom. Michael Stone helped some with "relay option 4" above.

5 4

is ECC patented? (was: Draft sketch document with ideas for future crypto ops)
by Zooko O'Whielacronx 02 Nov '11

02 Nov '11

A few pointers. On the happy "yay we can use it freely" side, we have: * RFC 6090 Pure gold! A catalog of ECC techniques which were published so long ago that they cannot still be under patent. It includes digital signatures and Diffie-Hellman. * DJB's page stating that certain patents don't apply to Curve25519 (which you mentioned): http://cr.yp.to/ecdh/patents.html * Jack Lloyd's statement that he avoided techniques newer than about 1990 in Botan: https://bugzilla.redhat.com/show_bug.cgi?id=615372#c19 On the sad "no we can't use it" side, we have: * Fedora's insistence on removing all elliptic curve cryptography from their Linux distribution and refusing to answer questions about why: https://bugzilla.redhat.com/show_bug.cgi?id=615372 Regards, Zooko

2 1

Re: [tor-dev] SHA-3 isn't looking so hot to me
by Watson Ladd 02 Nov '11

02 Nov '11

On Tue, Nov 1, 2011 at 4:40 PM, Marsh Ray <marsh(a)extendedsubset.com> wrote: > > On 11/01/2011 03:06 PM, Watson Ladd wrote: >> >> GCM is a Wegman-Carter authenticator with polynomial evaluation in >> GF2^128 as the universal hash and AES as the encryption. As NIST >> pointed out, neither of those papers had anything to say about the >> actual security of GCM: the security claims in the GCM paper are still >> valid. The Microsoft paper is simply irrelevant. 2^{n-k} looks scary, >> but messages are 2^k blocks long, where a block is 128 bits. And the >> GCM paper limited the length of messages to 2^36 bytes. The Joux paper >> was a threat to a misfeature: Theorem 1 still holds from the GCM paper >> (http://eprint.iacr.org/2004/193.pdf) Its just a matter of >> remembering that unique means unique, and that supporting variable >> length IVs by padding changes the meaning of the word unique. > > But those are exactly the kinds of details that get overlooked time and time > again. Whether or not you consider it a "real attack", a little bit of > controversy can help raise the important design constraints out of footnote > status. Definition of attack: something that breaks a security claim. Microsoft breaks a claim the GCM designers never made, Joux very cleverly breaks a part of the standard that their proof doesn't cover. The designers also didn't claim anything near the real security. (http://cr.yp.to/antiforgery/securitywcs-20050227.pdf is a tighter proof). True, NIST should put the claims front and center in the document, especially when they have such a nice form. But it is the responsibility of implementators of cryptography to exhaustively document what their security claims are. Hiding behind NIST won't save your data if you do something stupid. > >> I don't >> think stupidity by standards designers is a strike against what they >> are standardizing. > > :-) > > Everyone except fools and specialized cryptographers look to the recognized > experts to guide them. NIST's function is to provide expert, conservative > guidance on these topics, and they're pretty well regarded by engineers and > others who choose which standard to use. By following NIST, at the very > least it's not your fault if it turns out to be broken. NIST is standardizing cryptographic algorithms for government use. They make tradeoffs in their algorithms the same as any other user: speed vs. security. Blindly implementing standards is a way to fall into a trap. DES is a standard, Blowfish isn't as much. Which would you rather use? Furthermore, NIST didn't write the draft that the comments from Ferguson were about. As the response indicates GCM could be secure if you made the right parameter choices. Its not substantially different from RSA in that regard. Now, why the options, why q=2^128 instead of some prime? Because NIST wanted to support high speed encryption of fiber optic links in hardware, and Galois fields are easy in hardware. This is the story I get from the comments on the standard. If you are working in software, I would suggest something else. > > If, as you suggest, NIST can't get this unambiguously correct the first time > then in peoples' minds it naturally raises the question of the whole scheme > maybe being too complicated in practice. The standard is complicated But the problem is the picking the IV. I have no idea why NIST decided to use 96 bit IVs but fix the first 32 bits, so you are left with a 64 bit counter, then support longer ones through hashing, and then ultimately have to backtrack and support only 64 bit counters as nonces. But GCM is simple: it is polynomial evaluation, and encryption of the resulting value. The NSA has had these incidents before: ECMQV used to be in Suit B, before unknown key share attacks were published against it. The NIST P-256 was fast on 32 bit machines, but put a reflection right in the middle of a word on 64 bit machines. Etc, etc,. I'm sure there are many we never hear about. More fundamentally implementing a system such as Tor requires making choices about how standards are used and fit together. It is the rare (and wonderful!) standard that has no options. Making those choices requires knowledge of the security offered by the standard. It is never going to be possible to rely on guidance alone. Implementors who implement AES with giant tables are in for a surprise when they run on cloud machines. Hashing a password is pointless when that hash is a hash function: checking all 10 character passwords takes about a week on a nice graphics card. Understanding of cryptography is required even if standards exist. Nonces are required for protection against replay attacks. If nonces are unique, GCM is secure and pretty fast. Poly1305 is faster. HMAC does not have as high a margin of security proven, and when a hash function breaks so does HMAC. This is a good case for GCM or Poly1305 in Tor. Right now we have nothing: cells are encrypted with AES in counter mode only. In order to do something constructive I might go through Torspec and look at how things are used and what we rely on them for. This might give us a better idea of what the requirements are. > >> KDF!=turn a password into a bunch of bits. The KDF Tor uses is used to >> turn the result of a DH negotiation into keying material for several >> different algorithms. The KDF we need just needs to take some >> distribution to something random looking. We have enough randomness in >> the initial DH negotiation to not have to worry about slowing down >> brute force attacks. > > So you could almost use MD5(counter + DH material) for that :-) You can indeed. Or any stream cipher really. (Provided it doesn't do very bad things) > >> Where we use hashing to protect a password we >> should use scrypt or similar functions. > > I didn't know if passwords was a use case under discussion. PBKDFs has been > a hot topic lately and was just ranting in general. > > Thanks, > > - Marsh > Sincerely, Watson Ladd -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin

1 0

future-proofing by combining ciphers (was: Draft sketch document with ideas for future crypto ops)
by Zooko O'Whielacronx 01 Nov '11

01 Nov '11

in reference to https://lists.torproject.org/pipermail/tor-dev/2011-November/002999.html We're doing a development effort and/or thought experiment in the Tahoe-LAFS project. This development effort and/or thought experiment is called "One Hundred Year Cryptography" [1]. The main result of the experiment so far is that you don't need to worry very much future-proofing your digital signatures, collision-resistant hashes, or MACs, but you *should* worry about future-proofing your Diffie-Hellmans and ciphers! Once you deploy a future version of Tor which no longer accepts old-style signatures, then it will no longer matter to your users if someone subsequently figures out how to forge old-style signatures (for example by using quantum computers). On the other hand, once you deploy a future version of Tor that uses a newer cipher, your users remain vulnerable to an attacker who later breaks the older cipher and reads their older plaintexts. Combining two ciphers as you suggested by XORing their output (and keying them independently—perhaps by deriving two subkeys from a master key using a strong KDF) seems to be a safe and efficient way to protect against this sort of threat and doesn't seem to impose too high of a burden of complexity. That's what we intend to do in Tahoe-LAFS. A Google Summer of Code student, Yu Xue, contributed some code to generate subkeys and XOR the streams, but we haven't yet integrated it into Tahoe-LAFS itself. (I intend to do that in the release cycle that just opened up, so within the next 4 or so months.) I haven't thought very much about future-proofing Diffie-Hellman operations. That sounds like it might be more complex. I *have* thought about how to combine two different digital signatures or public key encryption algorithms. Those don't seem too dauntingly complex, but like I said not so urgent. I'm leaning toward combining AES-256 with XSalsa20. Other interesting options include ChaCha (used in SHA-3 finalist Blake, and very similar to Salsa20) and Threefish (used in SHA-3 finalist Skein). Regards, Zooko [1] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/OneHundredYearCryptography

1 0

Reminder: one month left for big features in 0.2.3.x
by Nick Mathewson 31 Oct '11

31 Oct '11

Hi, all! This is the final reminder about the December 1 deadline for getting large stuff merged into 0.2.3.x. See http://archives.seul.org/or/dev/Jul-2011/msg00030.html for the original announcment. It should answer many questions. December 1 is the deadline for getting large features and complicated bugfixes merged into 0.2.3.x. January 6 is the deadline for new features and marginal bugfixes. I am looking forward to being able to release 0.2.3.x on a faster-than-previous-Tor-releases schedule. Please plan accordingly! cheers, -- Nick

1 0

git-rw moved hosts - new ssh host key
by Sebastian Hahn 30 Oct '11

30 Oct '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey there people who have repositories hosted on tpo hardware, weasel migrated cupani to our shiny new VM server. Along with this came a change of ssh host key, so please be ready to modify your known_hosts file accordingly when you next push. The new ssh key fingerprint is: ssh-rsa e7:a0:63:15:a6:d3:41:e3:cf:92:6e:78:ea:cb:d7:ee After doing the migration, we took the opportunity to run a full git gc --aggressive on each repository, which should result in smaller clone sizes and generally faster clones. Take this as a reminder to occasionally optimize your local repositories too, your pushes will benefit and you can reclaim some lost space :) Sorry this went through without prior notice, I hope nobody's work was interrupted. Let me know if there is anything amiss, we don't expect any kind of issues tho. All the best Sebastian -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJOrbUZAAoJEKlsb90UDJYb77AIAIXIW5bkuXVfOB8DEYwh93vN ddIlxAea8QvrY8hebqHNYGC9a/GgHkgT3+fDGRLW1EsHgTb6YzpYT4Jhnrj1BKHu 37Kn1UzIyuS1X6X1CzFKJzoa6Z2Wej8lmpcOMk5m8GXE+MTMnYV/3kAZ+qsRgJOi GLO75HIFZc4FbD/wy2xAU6it3aBMPP1wszKK30wtU0oCldo20FDeltqaXt9GlWav jimBI+AcWBhgFr6hx7FKVLsLNlNkVEeH911E7qtDTF2lNzQAh7mHnzDU4sIZ6FhK wTNJOV3n/eCiyOp6amNmWC9mk+5RO0qjtNsdG+0aiPcmeKPzNNeIPiH1oQFVBWc= =rYix -----END PGP SIGNATURE-----

1 0

Proposal 187: Reserve a cell type to allow client authorization
by Nick Mathewson 29 Oct '11

29 Oct '11

Filename: 187-allow-client-auth.txt Title: Reserve a cell type to allow client authorization Author: Nick Mathewson Created: 16-Oct-2011 Status: Open Target: 0.2.3.x Overview: Proposals 176 and 184 introduce a new "v3" handshake, coupled with a new version 3 link protocol. This is a good time to introduce other stuff we might need. One thing we might want is a scanning resistance feature for bridges. This proposal suggests a change we should make right away to enable us to deploy such a feature in future versions of Tor. Motivation: If an adversary has a suspected bridge address/port combination, the easiest way for them to confirm or disconfirm their suspicion is to connect to the address and see whether they can do a Tor handshake. The easiest way to fix this problem seems to be to give out bridge addresses along with some secret that clients should know, but which an adversary shouldn't be able to learn easily. The client should prove to the bridge that it's authorized to know about the bridge, before the bridge acts like a bridge. If the client doesn't show knowledge of the proper secret, the bridge should at like an HTTPS server or a bittorrent tracker or something. This proposal *does not* specify a way for clients to authorize themselves at bridges; rather, it specifies changes that we should make now in order to allow this kind of authorization in the future. Design: Currently, now that proposal 176 is implemented, if a server provides a certificate that indicates a v3 handshake, and the client understands how to do a V3 handshake, we specify that the client's first cell must be a VERSIONS cell. Instead, we make the following specification changes: We reserve a new variable-length cell type, "AUTHORIZE." We specify that any number of PADDING or VPADDING or AUTHORIZE cells may be sent by the client before it sends a VERSIONS cell. Servers that do not require client authorization MUST ignore such cells, except to include them when calculating the HMAC that will appear in the CLOG part of a client's AUTHENTICATE cell. We still specify that clients SHOULD send VERSIONS as their first cell; only in some future version of Tor will an AUTHORIZE cell be sent first. Discussion: This change allows future versions of the Tor client to know that some bridges need authorization, and to send them authentication before sending them anything recognizably Tor-like. The authorization cell needs to be received before the server can send any Tor cells, so we can't just patch it in after the VERSIONS cell exchange: the server's VERSIONS cell is unsendable until after the AUTHORIZE has been accepted. Note that to avoid scanning attacks, it's not sufficient to wait for a single cell, and then either handle it as authorization or reject the connection. Instead, we need to decide what kind of server we're impersonating, and respond once the client has provided *either* an authorization cell, *or* a recognizably valid or invalid command in the impersonated protocol. Alternative design: Just use pluggable transports Pluggable transports can do this too, but in general, we want to avoid designing the Tor protocol so that any particular desirable feature can only be done with a pluggable transport. That is, any feature that *every* bridge should want, should be doable in Tor proper. Also, as of 16 Oct 2011, pluggable transports aren't in general use. Past experience IMO suggests that we shouldn't offload architectural responsibilities to our chickens until they've hatched. Alternative design: Out-of-TLS authorization There are features (like port-knocking) designed to allow a client to show that it's authorized to use a bridge before the TLS handshake even happens. These are appropriate for bunches of applications, but they're trickier with an adversary who is MITMing the client. Alternative design: Just use padding. Arguably, we could only add the "VPADDING" cell type to the list of those allowed before VERSIONS cells, and say that any client authorization we specify later on will be sent as a VPADDING cell. But that design is kludgy: padding should be padding, not semantically significant. Besides, cell types are still fairly plentiful. Counterargument: specify it later We could, later on, say that if a client learns that a bridge needs authorization, it should send an AUTHORIZE cell. So long as a client never sends an AUTHORIZE to anything other than a bridge that needs authorization, it'll never violate the spec. But all things considered, it seems easier (just a few lines of spec and code) to let bridges eat unexpected authorization now than it does to have stuff fail later when clients think that a bridge needs authorization but it doesn't. Counterargument: it's too late! We've already got the prop176 branch merged and running on a few servers. But as of this writing, it isn't in any Tor version. Even if it *is* out in an alpha before we can get this proposal accepted and implemented, that's not a big disaster. In the worst case, where future clients don't know whom to send authorization to so they need to send it to _all_ v3 servers, they will at worst break their connections only to a couple of alpha versions which one hopes by then will be long-deprecated already.

3 2

Fwd: [guardian-dev] Orbot-1.0.6-Tor-0.2.3.6-alpha-RC2
by Nathan Freitas 29 Oct '11

29 Oct '11

-- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Nathan of Guardian <nathan(a)guardianproject.info> wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Major update to Orbot is now available for testing on Android devices: https://github.com/guardianproject/Orbot/Orbot-1.0.6-Tor-0.2.3.6-alpha-RC2.… (sig: https://github.com/downloads/guardianproject/Orbot/Orbot-1.0.6-Tor-0.2.3.6-…) This includes work from GSathya of GSoC, as well as the new "make your phone a Tor Wifi hotspot" feature. code, commits, whatnot is here now: https://gitweb.torproject.org/orbot.git +n -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk6rpcgACgkQ0qzSA7N0y9IJaQD/avI5IVCV4+Zy9yaz/XbVGDrO ZFIcUVe27zWSa8c8X3cA/j05eJhwnoGAIPLsIQ0jaywd+HcqKQmSI8FHfRgLqgus =ToXu -----END PGP SIGNATURE----- _____________________________________________ Guardian-dev mailing list Post: Guardian-dev(a)lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianpr… You are subscribed as: nathan(a)guardianproject.info

1 0

Survey on Tor Trac usage and how you manage your tasks
by Karsten Loesing 25 Oct '11

25 Oct '11

Hi everyone! At the last annual dev meeting in Waterloo we had a very productive discussion about managing the various channels of Tor communication: https://trac.torproject.org/projects/tor/wiki/org/meetings/2011TorAnnualDev… Related to that discussion, we should talk about how we use Tor's Trac system, or more generally how we manage our Tor tasks. We use Trac as issue tracker, wiki, and for project management. But it seems that everyone uses Trac slightly different and has their own expectations how other people use it. This can slow us down. In addition to that, some people may not know how Trac can solve their problems. Knowing how others use Trac might help them manage their tasks more quickly. Let's conduct a survey! The survey below consists of two parts: The first part focuses on Trac's features and whether you're using them or not. The second part is about managing your tasks in general, either with or without Trac. If you are a Tor developer or volunteer or think you have some input on the topic, please fill out this survey until Sunday, August 28, 2011 and send it either to this list or to me. I'll try to summarize what was said and send the survey results to this list, hopefully before the end of the month. Thanks! Karsten 1 Using Trac features 1.1 Which of the reports (stored ticket queries) do you use most often? 1.2 What are typical custom queries that you run? 1.3 How do you use milestones and roadmaps? 1.4 Are you subscribed to tor-bugs and/or tor-wiki-changes, and how do you use the mails sent to these lists? 1.5 Which wiki pages do you read/edit most often? 1.6 How do you search for wiki pages? 1.7 What are typical search terms that you use when using the search features? 1.8 Do you use keywords and the tags page, and if so, what are keywords that you typically use? 1.9 How relevant are the following ticket fields for you? 1.9.1 Reported by 1.9.2 Owned by 1.9.3 Priority 1.9.4 Milestone 1.9.5 Component 1.9.6 Version 1.9.7 Keywords 1.9.8 Cc 1.9.9 Parent ID 1.9.10 Points 1.9.11 Actual Points 1.10 How relevant are the following ticket statuses for you? 1.10.1 accepted 1.10.2 assigned 1.10.3 closed 1.10.4 needs_information 1.10.5 needs_review 1.10.6 new 1.10.7 reopened 1.11 What other features do you use in Trac? 1.12 What features are you missing in Trac? 1.13 What features would you want our Trac not to offer anymore, because they're making things only more confusing for you (and for people who are new to Tor)? 2 Solving typical software development tasks Note that the questions below don't just focus on Trac, but on any tools or communication media you use for solving a task. 2.1 How do you decide what to work on, both when fixing bugs or when implementing new features? 2.2 How do you keep track of what things you're supposed to do for sponsors and for when? 2.3 How do you memorize new ideas to work on when they come up? 2.4 How do you coordinate working together with someone on something? 2.5 How do you learn who you could work together with on something? 2.6 What other software development tasks do you have that may be supported by Trac or a Trac-like system?

15 35

Re: [tor-dev] tor-dev Digest, Vol 9, Issue 8
by Rob Jansen 15 Oct '11

15 Oct '11

On 10/14/2011 08:00 AM, tor-dev-request(a)lists.torproject.org wrote: > On Tue, Sep 27, 2011 at 4:20 PM, Rob Jansen<rob.g.jansen(a)nrl.navy.mil> wrote: >> > If you have the need to run Tor experiments, or are just interested in the >> > Software, please try it out. We would love any feedback or comments or >> > suggestions if you have them! > i've got more, but first off: > > - why secondary dependencies not in git and not opt-in? > e.g. downloading > http://shadow.cs.umn.edu/downloads/shadow-resources.tar.gz - if you > run fully offline build systems this default behavior breaks builds. > True, this is a good point. My original reason is that I thought the latency data we collected from PlanetLab was too large to put in git. Since then, my experience with git and its way of handling changes leads me to believe this isn't an issue after all. Also, it is unclear to me that resources should be versioned the same way that source code is. > - what about hw acceleration in performance estimates? > e.g. openssl dynamic engines in virtual CPU processing. > We incorporate CPU delays into Shadow by giving it a CDF distribution of real measurements of application and CPU throughput, and "delaying" the processing of events based on this distribution. You can model HW accel by skewing the distribution, or better yet creating a new one based on real measurements of an accelerated OpenSSL/Tor. > - is there a shadow-dev in addition to shadow-support?:) > Not yet. Since you asked, it will be up in a few days:) > >> > We are continuously working on improving the simulator, including more >> > efficient use of multiple CPU cores and a command-line interface to help >> > with installing Shadow and some of its dependencies. > https://github.com/shadow/shadow-cli also handy. > > thanks! Thanks for the comments, feel free to share your others. Rob

1 1

Running Real Tor Code Over Simulated Networks
by Rob Jansen 14 Oct '11

14 Oct '11

Hello, For the unaware, we have been working on the design and development of Shadow, a simulator capable of running real binaries over a simulated network, and a plug-in that runs real Tor. Shadow can simulate roughly 1000 Tor nodes in 10 GB of RAM and is easy to setup and use (no root required). You can generate realistic Tor topologies using a consensus, and test changes implemented in Tor extremely quickly. Earlier this year, I had an idea for a new algorithm on Sunday, thought about how it might work and discussed it with Nick [Hopper - my adviser] on Monday, implemented it in Tor and tested it on Tuesday and Wednesday, started running experiments and had results by Friday. Honestly. That fast. If you have the need to run Tor experiments, or are just interested in the Software, please try it out. We would love any feedback or comments or suggestions if you have them! We are continuously working on improving the simulator, including more efficient use of multiple CPU cores and a command-line interface to help with installing Shadow and some of its dependencies. (Because really, who wants to install dependencies?) More details on Shadow's design can be found in our technical report: http://www-users.cs.umn.edu/~jansen/papers/shadow-umntr11-020.pdf A release version that is somewhat stable is available on the Shadow webpage: http://shadow.cs.umn.edu/ Our code is public at https://github.com/shadow Best regards, Rob -- Rob G. Jansen U.S. Naval Research Laboratory rob.g.jansen(a)nrl.navy.mil 202.767.2389

2 1

pid_t and MSVC
by Gisle Vanem 11 Oct '11

11 Oct '11

The use of 'pid_t' confuses me a bit: In common/procmon.c (inside MS_WINDOWS), it's typedef'ed to 'int' unconditionally. And then in common/util.* (tor_terminate_process()) it is assumed to be defined in orconfig.h or somewhere else. It's not AFAICS. It is true that _getpid() returns an 'int', but the way Tor uses it seems wrong; the last argument to OpenProcess() takes a 'DWORD'. So 'pid_t' should be 'DWORD' IMHO. So maybe we should introduce a 'typedef DWORD tor_pid_t;' in orconfig.h? Btw. MingW does have 'pid_t' in it's <sys/types.h>. --gv

2 1

Tor download link
by Marco Bonetti 10 Oct '11

10 Oct '11

Hello all, I have noticed that the distribution directory: https://www.torproject.org/dist/ only contains source code for the latest stable and unstable version. This somehow breaks package distribution mechanism like SlackBuilds.org which do not host source code by themselves. I have already submitted an up to date SlackBuild: as soon it will be accepted, new Slackware users will be able again to build Tor again so it's not a ground breaking issue but nevertheless a bit annoying. So, is there a directory which hosts older but still accepted as valid version of Tor which I did not see or is a torproject.org policy to just keep latest versions online? Again, not a very important issue but it will make package maintenance easier if I could link to a source package which will not be removed when still valid. Thanks in advance, Marco -- Marco Bonetti Tor research and other stuff: http://sid77.slackware.it/ Slackintosh Linux Project Developer: http://workaround.ch/ Linux-live for powerpc: http://workaround.ch/pub/rsync/mb/linux-live/ My GnuPG key id: 0x0B60BC5F

3 4

Re: [tor-dev] Proposal 176: Proposed version-3 link handshake for Tor
by Roger Dingledine 05 Oct '11

05 Oct '11

On Mon, Jan 31, 2011 at 09:50:06PM -0500, Nick Mathewson wrote: > 1) We should make it easier to use self-signed certs, or maybe > even existing HTTPS certificates, for the server side > handshake, since most non-Tor SSL handshakes use either > self-signed certificates or or... CA-signed certificates? > 2) We should make it harder to probe for a Tor server. Right > now, you can just do a handshake with a server, > renegotiate, then see if it gives you a VERSIONS cell. > That's no good. Does this proposal address this goal in any way? I don't see why it's on the list. > 3) We should allow other changes in our use of TLS and in our > certificates so as to resist fingerprinting based on how > our certificates look. Or this goal. Or do we simply mean here that proposal 176's results should not prevent results from other proposals like 179? > And the cell-based part of the V3 handshake, in summary, is: > > C<->S: TLS handshake where S sends a "v3 certificate" > > In TLS: > > C->S: VERSIONS cell > S->C: VERSIONS cell, CERT cell, AUTH_CHALLENGE cell, NETINFO cell > > C->S: Optionally: CERT cell, AUTHENTICATE cell Would probably be clearer to append an explicit line here: C->S: NETINFO cell > The v3 requirements are easy to meet: any certificate designed to > resist fingerprinting will likely be self-signed, or if it's > signed by a CA, then the issuer will surely have more DN fields > set. Certificates that aren't trying to resist fingerprinting > can trivially become v3 by using a CN that doesn't end with .net, > or using a 1024-bit key. I assume you mean "or using a key longer than 1024 bits." > If the client implements this proposal, however, and the server > has shown it can understand the V3+ handshake protocol, the This is the first point where you use "V3+" where you had otherwise used "V3". Should the + just be implicit, or do you mean to imply something different when you say V3+ vs V3? I don't see how we can predict that a given behavior could imply V4 without knowing what V4 will be. > An AUTH_CHALLENGE cell is a variable-length cell with the following > fields: > Challenge [32 octets] On IRC you suggested that the AUTH_CHALLENGE cell might want to list the authtypes it knows how to parse. Thus if we bump the AuthType version, we may not need to bump the whole link version. > 3.4. Authenticating via Tor cells: Client authentication > > A client does not need to authenticate to the server. If it > does not wish to, it responds to the server's valid CERT cell by > sending NETINFO cell: once it has gotten a valid NETINFO cell > back, the client should consider the connection open, and the > server should consider the connection as opened by an > unauthenticated client. The word 'back' is misleading here, since it implies that the server waits to send its netinfo cell until it sees one from the client. > CID: A SHA256 hash of the client's RSA1024 identity key [32 octets] > SID: A SHA256 hash of the server's RSA1024 identity key [32 octets] > SLOG: A SHA256 hash of all bytes sent from the server to the client > as part of the negotiation up to and including the > AUTH_CHALLENGE cell; that is, the VERSIONS cell, > the CERT cell, and the AUTH_CHALLENGE cell. [32 octets] > CLOG: A SHA256 hash of all byte sent from the client to the > server as part of the negotiation so far; that is, the > VERSIONS cell and the CERT cell. [32 octets] > SCERT: A SHA256 hash of the server's TLS link > certificate. [32 octets] > TLSSECRETS: Either 32 zero octets, or a SHA256 HMAC, using > the TLS master secret as the secret key, of the following: > - client_random, as sent in the TLS Client Hello > - server_random, as sent in the TLS Server Hello > - the NUL terminated ASCII string: > "Tor V3 handshake TLS cross-certification" > [32 octets] > TIME: The time of day in seconds since the POSIX epoch. [8 octets] > NONCE: A 16 byte value, randomly chosen by the client [16 octets] In the server section you specify that the randomness needs to be strong. Does the omission of that specification for the client mean it doesn't need to be? :) (I'd hate for somebody to misinterpret 'nonce' as 'value that was not previously used', and implement it as a counter, which would do perfectly fine for the protocol but also reveal how many authenticate cells we've sent since the last time you saw one.) > SIG: A signature of a SHA256 hash of all the previous fields > using the client's "Authenticate" key as presented. (As > always in Tor, we use OAEP-MGF1 padding; see tor-spec.txt > section 0.3.) > [variable length] > > To check the AUTHENTICATE cell, a server checks that all fields > containing a hash contain the correct value, then verifies the > signature. The server MUST ignore any extra bytes after > the SHA256 hash. You mean extra bytes after the signature? > 4. Numbers to assign > > We need a version number for this link protocol. I've been > calling it "3". > > We need to reserve command numbers for CERT, AUTH_CHALLENGE, and > AUTHENTICATE. I suggest that in link protocol 3 and higher, we > reserve a separate range of commands for variable-length cells. Sounds good to me. > 6. Security argument > > These aren't crypto proofs, since I don't write those. They are > meant be reasonably convincing. They look plausible to me. > 8. Open questions: > > - May we cache which certificates we've already verified? It > might leak in timing whether we've connected with a given server > before, and how recently. Would this be much of a win anyway? Seems like more code for not much of a win. > - With which TLS libraries is it feasible to yoink client_random, > server_random, and the master secret? If the answer is "All > free C TLS libraries", great. If the answer is "OpenSSL only", > not so great. Good question. > - Should we do anything to check the timestamp in the AUTHENTICATE > cell? Does having the timestamp give us anything that having the nonce doesn't already provide? I pondered for a while that it might actually be bad to have the timestamp there, since its offset from 'real' time is a cookie that lets us track the user. But there are plenty of other ways that we can learn the client's time, like the NETINFO cell. > - Can we give some way for clients to signal "I want to use the > V3 protocol if possible, but I can't renegotiate, so don't give > me the V2"? Clients currently have a fair idea of server > versions, so they could potentially do the V3+ handshake with > servers that support it, and fall back to V1 otherwise. Given that corporations like Bluecoat sell censorship devices that censor our V2 handshake -- and we've seen them deployed in Syria -- but we know of no places that censor our V1 handshake, it would not be crazy to declare that V3-supporting clients all prefer V1 to V2. That said, bridges are a good example of a case where we don't know the server version, and also a prime use case here. One hack would be to change Tor versions that don't support V3 (like 0.2.2.x) so they don't support V2. *That* said, I think we shouldn't waste too much time on this topic. There aren't any Tors that can't renegotiate now (if we ignore Tor clients in Syria), so if we are forced to make some in the future before V3 is deployed, we could just make those Tors only support V1. > - What should servers that don't have TLS renegotiation do? For > now, I think they should just stick with V1. Eventually we can > deprecate the V2 handshake as we did with the V1 handshake. > When that happens, servers can be V3-only. Who are these servers you're thinking of? --Roger

3 4

Reminder: less than two months left for getting big features merged into 0.2.3.x
by Nick Mathewson 04 Oct '11

04 Oct '11

Hi, all! This is a reminder about the planned schedule for 0.2.3.x. See http://archives.seul.org/or/dev/Jul-2011/msg00030.html for the original announcment. December 1 is the deadline for getting large features and complicated bugfixes merged into 0.2.3.x. January 6 is the deadline for new features and marginal bugfixes. Please plan accordingly! cheers, -- Nick

3 2

سلام برنامه تور فارسی برای ایران
by Mohammad Mo 01 Oct '11

01 Oct '11

سلام برنامه تور فارسی برای ایران وسازگار با سرعت کم اینترنت داخلی می خاهم متشکرم mohammad_20101389(a)yahoo.com

2 2

(no subject)
by Mohammad Mo 30 Sep '11

30 Sep '11

1 0

Future direction for torperf
by Thomas S. Benjamin 30 Sep '11

30 Sep '11

Dear all, I am working on a re-design of torperf that will use a central python script to automate initiation and control of torperf experiments. I have a very rough draft that provides the most basic level of functionality in tomb/torperf.git branch 3280, and have ticket #3280 as wanting review. The code needs substantial improvement, but I would love feedback on my general approach before I spend a lot of time on grooming this specific version. If you use torperf please consider giving me feedback on the direction in which I am heading with this. I want to make sure that I am designing something that will work for other people, rather than just for my own experiments. I have chosen not to merge into a branch of torperf.git because my working style involves lots of frequent verbose commits, which would be distracting for most people. I will roll together the many commits before merging into torperf.git -- Sincerely Yours, ---Thomas S. Benjamin

2 1