- tor-dev - lists.torproject.org

[rt.torproject.org #14664] Tor on iOS (fwd)
by Veronique Dubois 06 Oct '13

06 Oct '13

---------- Forwarded message ---------- Date: Sat, 5 Oct 2013 23:59:16 +0000 From: Colin Childs via RT <help(a)rt.torproject.org> To: vero(a)was.fm Subject: [rt.torproject.org #14664] Tor on iOS On Sat Oct 05 21:57:29 2013, vero(a)was.fm wrote: > Dear Tor, > > I work with a small group of developers called Wizardry and > Steamworks and we have recently managed to port Tor to Apple iOS devices. > The port requires for iOS to be jailbroken (please note that that action > is not illegal but just //may// void warranty). > > The port has been uploaded to Cydia on BigBoss's repo and can be > found at: > > http://moreinfo.thebigboss.org/moreinfo/depiction.php?file=torDp > > We have seen that your website lists download locations for Tor > at: > > https://www.torproject.org/download/download-easy.html.en > > and that on the page: > > https://www.torproject.org/download/download.html.en > > an Android Bundle is listed under the "Tor for Smartphones" > header. > > We were wondering if you could list our port to iOS or, at > least, mention somewhere on the download page that Tor is now also > available for Apple iOS devices via Cydia. > > Thank you, > Veronique Dubois > on behalf of Wizardry and Steamworks @ was.fm Hello, Please send a copy of this message to our Tor-Dev mailing list at https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev. -- Colin C.

1 0

Re: [tor-dev] Tools of Mass Obfuscation or where are my internet curtains?
by Malard Joel 04 Oct '13

04 Oct '13

Ian, Thanks. Tell me what a better forum would be and I' ll gladly move this discussion there. Your suggestion does use encryption if only as a catalyst. There was a time when encrypted content could not be sent to Canada from the US and I can imagine some governments forbidding the use of encryption. Harvesting keywords from k messages of length n takes O(n.k) time and space, possibly with some large constants. If the messages are scrambled hopefully it would take O(k.n.log(n)) time to harvest them. What would really help imho with mass snooping would be a transfer method that requires O(k.log(k).n) time for any form of keyword harvesting. I don' t have an answer, hence the contest. Another approach might be to string every m-th bit of a message of n bits, where m an n are relatively prime, cyclically. Best of luck with Tor. Cheers, Joel ------------------------------ On Thu, Oct 3, 2013 2:58 PM PDT Ian Goldberg wrote: >On Thu, Oct 03, 2013 at 02:34:50PM -0700, Malard Joel wrote: > > > Do you think that the code at https://github.com/malardj/ slice, that uses neither encryption nor a password, could help a community proof their communications from massive systemic eavesdropping by making the latter computationally impractical or financially unsustainable? Do you think that a tool like that would be valuable if it existed? Would you think of some yourself that everyone could use? > > I am unaffiliated with any institution but I would like to setup a contest for the best such algorithm or procedure that does not involve cryptography and that can be implemented by any group of ordinary citizens for the purpose of proofing their Internet communications of ASCII characters from systemic eavesdropping. > > I need help setting up the rules of competition ( i never did this), finding judges (I am totally unqualified), finding (virtual) places where to announce and hold the competition. I would welcome your suggestion on how to make this contest more relevant to all. Can you help, or suggest where to look for help? > > The code above is a quick example of the type of entries that I have in mind. It consists in a C++ program that inputs a character string, slices it and shuffles those slices into a javascript program that displays the input when it is run. The method purports to hamper the work of automated keyword harvesters. The available code does not support html text but that capacity is not be hard to add. > > With best regards, > > Joel Malard, PhD > Fremont, CA > >I don't think this is the right list for this discussion, but how about: > >- Pick a 128-bit random key K >- Encrypt the message using key K with, say, AES-GCM or your favourite > authenticated encryption mode to yield the ciphertext C (including > tag) >- randomize the last b bits of K to yield K', for some b, probably > around 30, but could be anything from 0 to 40ish. >- output K' concatenated with C > >Notably, you don't output b. The receiver just runs a counter X up from >0 until C authenticates using the key (K' XOR X). b controls how long >this will take, but the receiver doesn't know it. (There was a >password-stretching algorithm like that in USENIX Security (I think it >was) a little while ago; the adversary doesn't know how many iterations >to wait before giving up / trying another password.) The high part of K >acts like a salt. > >It's kind of like the old Lotus Notes encryption, in that the NSA got to >know the high part of the key, and just had to brute the low 40 bits, >only now the receiver has to brute it as well. It's not technically >encryption, as there's no shared or public key. But there's also no key >management, of course. > > - Ian >_______________________________________________ >tor-dev mailing list >tor-dev(a)lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

1 0

Tools of Mass Obfuscation or where are my internet curtains?
by Malard Joel 03 Oct '13

03 Oct '13

Do you think that the code at https://github.com/malardj/ slice, that uses neither encryption nor a password, could help a community proof their communications from massive systemic eavesdropping by making the latter computationally impractical or financially unsustainable? Do you think that a tool like that would be valuable if it existed? Would you think of some yourself that everyone could use? I am unaffiliated with any institution but I would like to setup a contest for the best such algorithm or procedure that does not involve cryptography and that can be implemented by any group of ordinary citizens for the purpose of proofing their Internet communications of ASCII characters from systemic eavesdropping. I need help setting up the rules of competition ( i never did this), finding judges (I am totally unqualified), finding (virtual) places where to announce and hold the competition. I would welcome your suggestion on how to make this contest more relevant to all. Can you help, or suggest where to look for help? The code above is a quick example of the type of entries that I have in mind. It consists in a C++ program that inputs a character string, slices it and shuffles those slices into a javascript program that displays the input when it is run. The method purports to hamper the work of automated keyword harvesters. The available code does not support html text but that capacity is not be hard to add. With best regards, Joel Malard, PhD Fremont, CA

2 1

RFC of proposal draft for "Migration to ed25519 HS identity keys and privacy-preserving directory documents"
by George Kadianakis 03 Oct '13

03 Oct '13

Here is another HS proposal draft. This one specifies how to migrate from the current HS protocol to the one specified in proposals "Migrate HS identity keys to Ed25519" and "Stop HS address enumeration by HSDirs": https://lists.torproject.org/pipermail/tor-dev/2013-August/005279.html https://lists.torproject.org/pipermail/tor-dev/2013-August/005280.html (I will soon write a proposal that merges these two proposals into one) This proposal is in serious need for comments. Specifically, see section "1.1. From the PoV of Hidden Services" which I left entirely unspecified. There are also probably multiple migration concerns which I have forgotten or completely ignored. Inlining: Filename: xxx-hs-id-keys-migration.txt Title: Migration to ed25519 HS identity keys and privacy-preserving directory documents Author: George Kadianakis Created: 13 September 2013 Target: 0.2.5.x Status: Draft [More draft than Guinness.] 0. Overview and motivation Proposal XXX introduces two new HS features: a) Stronger HS identity keys. b) New-style HS directory documents so that HS addresses are not leaked to HSDirs. This document specifies how different Tor actors must act after proposal XXX is implemented, so that the migration can proceed smoothly. We aim for the migration to be smooth both from the perspective of Hidden Services (introduce grace period so that HS operators don't wake up one day to find that their HS can't be accessed with that address anymore) and from an implementation perspective (avoid bloating the Tor protocol or introducing sensitive flag days). 1. Migration strategy After proposal XXX is implemented: a) The HS address format will change (called "new-style HS address" in this document) b) New HSDirs will be introduced (called "HSDirV3" in this document) c) New-style HS descriptors will be introduced (called "HS V3 descriptors" in this document). The following sections investigate how these changes influence the various Tor actors: 1.1. From the PoV of Hidden Services: === XXX DISCUSSION XXX === I see (at least) three migration strategies here. I'm not sure which one is better so I'll write all of them and we can then discuss them and pick one. a) After proposal XXX is implemented, Tor (configured as an HS) will only publish HS V3 descriptors by default. There will be a torrc parameter that the HS operator can use, that turns on publishing of HS V2 descriptors for backwards compatibility with the old HS address (the old identity key must be kept around). b) After proposal XXX is implemented, Tor (configured as an HS) will publish both V3 and V2 HS descriptors for each Hidden Service. There will be a torrc parameter that turns off publishing of V2 HS descriptors. This parameter will eventually be switched off by default. c) After proposal XXX is implemented, Tor (configured as an HS) will only publish V3 HS descriptors. The code that publishes V2 descriptors can be disabled or removed. HSes who want to publish V2 descriptors (and keep the same address) will have to maintain two copies of Tor -- one running the latest Tor version, and another one running an older version that supports V2 descriptors. The engineer inside me tells me to go with c), but I feel that it leaves all the burden to the HS operators. I haven't checked how much implementation effort doing a) or b) would take us. 1.2. From the PoV of the HS client: Tor clients can distinguish new-style HS addresses from old ones by their length. Legacy addresses are 16 base32 characters, while new ones are 56 (XXX) base32 characters. If Tor is asked to connect to a legacy address it SHOULD throw a warning and advocate the use of new-style addresses (it should still connect to the HS however). In the future, when old-style HS addresses are close to depletion, we can introduce a torrc parameter that blocks client connections to old-style HS addresses. 1.3. From the PoV of HS directories: Tor relays will advertise themselves as HSDirV3 servers using the "hidden-service-dir" router descriptor line. For a while, relays will also continue being HSDirV2 servers. We will specify a timeout period of X months (4?), after which relays will stop being HSDirV2 servers by default (using the HidServDirectoryV2 torrc parameter). 1.4. From the PoV of directory authorities: Authorities will continue voting for HSDirV2 servers. Eventually, when all relays have upgraded and no one is claiming to be HSDirV2, we can disable and remove the relevant code. XXX Need to specify grace periods. XXX What did I forget?

4 7

[draft] Proposal XXX: On upgrading HS identity keys and on a new HS directory scheme that does not leak
by George Kadianakis 01 Oct '13

01 Oct '13

release early; release often again This is a draft of a proposal that merges the two proposals I posted last month, namely the "Migrate HS identity keys to Ed25519" and "Stop HS address enumeration by HSDirs" proposals. This goes together with the "Migration to ed25519 HS identity keys and privacy-preserving directory documents" I posted two weeks ago. It tried to address most of the comments from Nick and Matthew. There are still lots of stuff to fix (especially the key derivation part). Inlining: Filename: xxx-hs-id-keys-and-onion-leaking.txt Title: On upgrading HS identity keys and on a new HS directory scheme that does not leak Author: George Kadianakis Created: 10 August 2013 Target: 0.2.5.x Status: Draft [More draft than Guiness.] ToC: 0. Overview 1. Motivation 2. Related proposals 3. Overview of changes 4. Specification of changes 5. Discussion 6. Acknowledgments Appendix: A0. Security proof of directory scheme --- 0. Overview: This proposal has two aims: a) Improve the strength of HS identity keys. Specifically, this proposal suggests the adoption of Ed25519 ECDSA keys as a replacement for the RSA-1024 keys that are currently in use by hidden services. b) Stop HS address enumeration by HSDirs When a client asks for the descriptor of a hidden service the hidden service address is leaked to the HSDir that was inquired. This proposal suggests a new directory scheme that prevents HSDirs from learning the hidden service address or the contents of the hidden service descriptors they serve. 1. Motivation The long-term identity keys of Hidden Services are RSA-1024 keys; we consider these weak and in need for replacement. Furthermore, 80-bit hidden service addresses are short enough to be prone to brute-force impersonation attacks. Ed25519 (specifically, Ed25519-SHA-512 as described and specified at http://ed25519.cr.yp.to/) is a good alternative: it's secure, fast, has small keys and small signatures, is bulletproof in several important ways, and supports fast batch verification. (It isn't quite as fast as RSA1024 when it comes to public key operations, since RSA gets to take advantage of small exponents when generating public keys.) 2. Related proposals This proposal goes hand in hand with proposal XXX "On the migration to Ed25519 HS identity keys and privacy-preserving directory documents". Proposal XXX specifies how the schemes described in this proposal should be deployed in the real Tor network to minimize frustration and bad vibes. XXX Another related proposal is proposal XXX "On the upgrade of Hidden Service service keys" which defines the upgrade from the current RSA-1024 HS service keys to a more powerful cryptosystem. 3. Overview of changes This section provides a high-level overview of the changes suggested in this document. 3.0. Overview of identity-key changes Longterm RSA-1024 "identity keys" are used by hidden services to authenticate themselves to clients. This proposal specifies: * The generation of new Ed25519 long-term identity keypairs (#KEYGEN) * A new HS descriptor format (v3) that contains Ed25519 HS identity keys (#NEWDESC) * A way for clients to upload and fetch v3 descriptors from HSDirs (#DESCFETCH and #DESCUPLOAD) 3.1. Overview of anti-enumeration scheme Currently, Hidden Services upload their unencrypted descriptor to hidden service directories (HSDirs). HSDirs store the unencrypted descriptor in an internal map of: <hs address> -> <hs descriptor> When a client wants the descriptor of an HS, it asks an HSDir for the descriptor that corresponds to <hs address>. If the HSDir has such an index in its map, it returns the <hs descriptor> to the client. This proposal asks Hidden Services to periodically derive a new ephemeral keypair from their long-term identity key; the new keypair being a function of the identity key and a time-dependent nonce. The derivation should be one-way; if you know the identity key you should be able to derive the ephemeral key but not the other way around. Finally, a client should be able to derive the ephemeral HS public key from the long-term HS public key without knowing the long-term HS private key (#KEYPAIRDERIVATION) Hidden Services then encrypt their descriptor with a symmetric key (derived from the long-term identity public key) and sign the ciphertext and the ephemeral public key with their ephemeral private key (#NEWDESC). Then they place the ephemeral public key, the encrypted descriptor and the signature in a v3 hidden servide descriptor and send that to the HSDir (#DESCUPLOAD). When the HSDir receives a v3 hidden service descriptor, it validates the signature using the embedded ephemeral public key and if it verifies it stores the descriptor in an internal map of: <ephemeral public key> -> <v3 descriptor> (#DESCHANDLING). Now, out of band, the HS gives to its clients a <z>.onion address. <z> in this case is the long-term public key of the HS (this is different from the current situation where <z> is the hash of the long-term public key). A client that knows the <z>.onion address and wants to acquire the HS descriptor, derives the <ephemeral public key> of the HS using <z> and the same key derivation procedure that the HS uses. She also derives the symmetric key that decrypts the encrypted HS descriptor (#KEYPAIRDERIVATION). The client then contacts the appropriate HSDir and queries it for the descriptor with index <ephemeral public key>. If the HSDir has such an index in its internal map it passes the <v3 descriptor> to the client (#DESCFETCH). The client then verifies the signature of the v3 descriptor, and if it's legit she decrypts the encrypted descriptor using the ephemeral symmetric key. The client now has the Hidden Servide descriptor she was looking for (#DESCHANDLING). 4. Specificaton of changes 4.0 Generation of long-term identity-key Ed25519 keypairs (#KEYGEN) When a hidden service starts up with no Ed25519 identity keys, it generates a new identity keypair. 4.1. Ephemeral keypair derivation (anti-enumreation) (#KEYPAIRDERIVATION) XXX Leaving this unpsecified for now till the security proof comes along. 4.1.0. By Hidden Services: For now, let's assume that after this paragraph each HS has a per-TIME_PERIOD ephemeral keypair. It also has a symmetric key derived from the identity public key to encrypt its descriptor. 4.1.1. By clients: When a Tor client is asked to connect to a hidden service address <z>.onion, it assumes that <z> is the long-term public key of the hidden service. Internally, and without notifying the user, the Tor client generates the ephemeral public key and ephemeral symmetric key of the HS for that time period (using the long-term public key of the hidden service and the procedure specified in the previous section). 4.2. New v3 Hidden Service Descriptor Format (#NEWDESC) To serve the purposes of this proposal we need to perform multiple modifications to hidden service descriptors. Specifically, to migrate to new identity keys we need to change the format of the v2 Hidden Service descriptor to use Ed25519 keys. Furthermore, to provide enumeration protection we need to encrypt the whole descriptor with the ephemeral symmetric key. To do so we define a new construct just for this section, called "intermediate descriptor". It has the same format as a v2 hidden service descriptor but uses Ed25519 instead of RSA-1024. The following changes are performed to the v2 HS descriptor: [*] The "permanent-key" field is replaced by "permanent-key-ed25519": "permanent-key-ed25519" SP an Ed25519 public key [Exactly once] The public key of the hidden service which is required to verify the "descriptor-id" and "signature-ed25519". In base64 format with terminating =s removed. [*] The "service-key" field is replaced by "service-key-ed25519': "service-key-ed25519" SP an Ed25519 public key [Exactly once] The public key used to encrypt messages to the hidden service. In base64 format with terminating =s removed. [*] The "signature" field is replaced by "signature-ed25519': "signature-ed25519" SP signature-string [At end, exactly once] A signature of all fields above using the private Ed25519 key of the hidden service. In base64 format with terminating =s removed. Now we define the format of the new v3 Hidden Service descriptor that is uploaded to the HSDirs: "ephemeral-public-key" SP public-key [At start, exactly once] The ephemeral HS public key for this time period. In base64 format with terminating =s removed. "encrypted-descriptor" SP encrypted-descriptor [Exactly once] An encrypted intermediate descriptor (as specified above). It's encrypted with AES in CTR mode with a random initialization vector of 128 bits that is written in the beginning of the encrypted string. The ephemeral symmetric key derived in section XXX is used as the secret key of AES. The encrypted string is encoded in base64 and surrounded with "-----BEGIN MESSAGE-----" and "-----END MESSAGE-----". "publication-time" SP YYYY-MM-DD HH:MM:SS NL [Exactly once] A timestamp when this descriptor has been created. It should be rounded down to the nearest day. The timestamp SHOULD be used by the clients and HSDirs to discard old descriptors. XXX Should we specify how long the HSDir is supposed to keep the descriptor? rend-spec.txt doesn't do so. XXX Is "rounded down to the nearest day" too extreme of a rounding? Other Tor documents round it down to the nearest hour. Does it matter if our expiration time is longer than a day? XXX Should we kill the "publication-time" in the HS descriptors? Or just leave it there? "signature" SP signature [At end, exactly once] A signature of all fields above using the ephemeral private key of the hidden service. In base64 format with terminating =s removed. 4.3. Uploading v3 HS descriptors to HSDirs (#DESCUPLOAD) A new type of Hidden Service Directory Server must be established which knows how to handle v3 Hidden Service descriptors. The Hidden Service follows the same publishing procedure as for v2 descriptors but instead of sending an HTTP 'POST' to "/tor/rendezvous2/publish", the HS sends the 'POST' request to "/tor/rendezvous3/publish" with the descriptor included in the body of the 'POST'. 4.4. Fetching v3 HS descriptors from HSDirs (#DESCFETCH) When a client needs to fetch a v3 Hidden Service Descriptor from an HSDir, it follows the exact same procedure as for v2 descriptors but instead of sending an HTTP 'GET' to "/tor/rendezvous2/<z>", it sends an HTTP 'GET' to "/tor/rendezvous3/<z>" where <z> is the base32 encoding of the *ephemeral* public key of the Hidden Service. XXX base32 is used because it's URL-safe and because we don't really care about the extra length. XXX example? 4.5. v3 hidden servide descriptor handling (#DESCHANDLING) 4.5.1. By HSDirs: When an HSDir receives a v3 hidden service descriptor, it verifies its signature using the ephemeral public key that was included in the descriptor. If the signature verifies and the descriptor timestamp is reasonable, the descriptor is accepted and cached. Otherwise, the descriptor is discarded. 4.5.2. By clients: When a client receives a v3 hidden service descriptor, it checks the timestamp and verifies the signature using the previously derived keys and discards it if the signature was not proper. If the signature is proper, the client uses the derived ephemeral symmetric key to decrypt the 'encrypted-descriptor' part of the metadescriptor. 5. Discussion [Points here might deserve their own sections] Do we need the HSDir hash ring, even though the HS address and the descriptor are now hidden from HSDirs? An Ed25519 public key is 32 bytes. 32 bytes in base32 encoding is 56 characters (or 52 with the '=' padding removed). Do we want a different URL encoding or are we happy with addresses like: mfrggzdfmztwq2lknnwg23tpobyxe43uov3ho6dzpjaueq2eivda.onion ? 6. Acknowledgments The cryptography behind this proposal was originally proposed by Robert Ransom in a private email thread and subsequently posted in tor-dev [0]. Discussion was continued in trac ticket #8106 [1]. During the past 6 months many bright people have looked at the cryptography behind this scheme. The list of people includes Nadia Heninger, Leonid Reyzin, Nick Hopper, Aggelos Kiayias, Tanja Lange, Dan J. Bernstein and probably others that I can't recall at this point. Thanks! Parts of this proposal has been based on discussions with Nick Mathewson and his proposal 220. XXX "One more: Christian Grothoff told me in Garching that GNUnet does something quite similar for its keys. So we should probably check out their approach too, and include them in the "related work" section of any hypothetical publication here. :)" Appendix: A0. Security proof of directory scheme XXX A security proof of the above scheme is under development. We are not going to implement or deploy anything before we have a solid proof of this.

1 0

Re: [tor-dev] Sponsor F: update; next meeting [in *two weeks*]
by Matt Pagan 01 Oct '13

01 Oct '13

On Mon, 30 Sep 2013 19:13:37 -0700 Tom Lowenthal <me(a)tomlowenthal.com> wrote: > Today, at 1100 Pacific, we spent more than 90 minutes discussing > [Sponsor F][]. Here's the summary. > > **READ THIS**: The next Sponsor F meeting will be held in a mere two > weeks on **2013-10-14, at 1100h Pacific in #tor-dev**. > > This is a schedule change: from now on, the meetings will be every two > weeks. It's possible that we may have to increase this to every week, > depending on how fast we work, and how long meetings are taking. If > you should be at these meetings but cannot make Mondays at 1100h > Pacific, please contact me, and I'll start the process of finding a > better time or times. > > If you are individually in the `cc` field of this message, it's > because I think that there's something which I think you need to do > for Sponsor F before Halloween. You should also come to the next > Sponsor F meeting. If you can't make the meeting, or don't think this > work applies to you, you should get back to me ASAP so we can fix it. > > Is something else missing, wrong, or messed up? I'd like to know. > > [Sponsor F]: > https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorF/Year3 > > > * * * * * > > > Core Phase 2 Deliverables > ========================= > > > UDP Transport [#10] > ------------- > > **[On Track: Minimal]** Karsten will work with Rob to complete the > Shadow simulation of this work, then write up a full report on this, > probably with Stephen's help. We expect both tasks to be complete by > Halloween. This likely represents a minimal outcome for this > deliverable. > > > Combine obfuscation (obfsproxy) with address-diversity (flashproxy) > [#11] > ------------------------------------------------------------------- > > **[On Track: Minimal]** The work of integrating obfsproxy with > flashproxy is done. George will include this in the next released > version of the pluggable transports browser bundle. George will also > write a report on this work. Ximin and David will help. By Halloween, > the report will be complete and the bundles will either be released or > well on their way through testing. This likely represents some > combination of minimal or intended outcomes for this deliverable. > > > Bridge Metrics [#12] > -------------- > > **[Done: Intended]** Our reporting code has been merged into master. > It will ride the trains or flow downstream or whatever your favorite > code development cycle imagery is, and show up in future releases. As > it goes through alpha, beta, and release, gets picked up and adopted > by more operators, we'll get more comprehensive sample coverage, and > better data. This likely represents an ideal outcome for this > deliverable. > > > N23 Performance Work [#13] > -------------------- > > **[On Track: Alternate]** Roger doesn't think that N23 is as good as > we thought it was, so he's going to write a report on the various > performance improvements we've implemented lately; the performance > work which we though about, but decided not to implement, and why; and > a wishlist of future performance work and research. He'll have this > done by Halloween. This likely represents an alternate outcome for > this deliverable. > > > Improved Scheduling [#14] > ------------------- > > **[On Track: Intended]** Nick will work with Roger and Andrea to > implement an improved scheduler (possibly based on picking randomly, > weighted by bandwidth), and -- if possible -- also to refactor `cmux`. > If time permits, Nick will also attempt to simulate this using Shadow > , probably with Karsten's help. Finally, Nick will produce a full > report before Halloween. This likely represents an intended outcome > for this deliverable. > > > Alternate `Fast` Flag Allocation [#15] > -------------------------------- > > **[At Risk]** The person who we initially expected to do this work > does not seem to be available to do it. We need to find an alternate > plan to execute this deliverable. If you think you can do it, please > read [ticket #1854][#1854] and get in touch. > > [#1854]: https://trac.torproject.org/projects/tor/ticket/1854 > > > VoIP Support [#16] > ------------ > > **[On Track: alternate]** Our implementation strategy for this was > high-latency send-an-mp3-over-XMPP using Gibberbot/Chatsecure, or a > similar system. The internal milestone was to have a release candidate > available today. Sadly, Nathan (who is on point for this) wasn't on > the call. Fortunately, Nathan [blogged][guardian-1] about Chatsecure's > `12.4.0-beta4` ten days ago, and a tantalizingly-named > [`ChatSecure-v12.4.2-release.apk`][chatsecure-release] > ([sig][chatsecure-release-sig]) is available in the Guardian Project > [release directory][guardian-releases]. The outlook seems good, but > Tom will follow up with Nathan as soon as possible to verify these > outrageous claims. Nathan, if you're reading this, could you get in > touch (email, IRC, XMPP, whatever). Thanks! > > [guardian-1]: > https://guardianproject.info/2013/09/20/gibberbots-chatsecure-makeover-almo… > [chatsecure-release]: > https://guardianproject.info/releases/ChatSecure-v12.4.0-beta4-release.apk > [chatsecure-release-sig]: > https://guardianproject.info/releases/ChatSecure-v12.4.0-beta4-release.apk.… > [guardian-releases]: https://guardianproject.info/releases/ > > > > Extended Phase 2 Deliverables > ============================= > > > VoIP Support [#17] > ------------ > > **[Limbo: Intended]** Here we're talking about getting a general VoIP > client (Mumble) to work over Tor. This discussed in [ticket > #5699][#5699], and [instructions][torify-mumble] for using Mumble over > Tor are on the wiki. We didn't get an update during the meeting, so if > you're working on this, get in touch, eh? > > [#5699]: https://trac.torproject.org/projects/tor/ticket/5699 > [torify-mumble]: > https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/Mumble > > There still exists a bug in Mumble such that when network connections are routed through a proxy they leak DNS requests. This past month I've been reading QT documentation so that I can understand the Mumble code better and find the bug. After the meeting on IRC, velope suggested that fixing it might be as simple as implementing SOCKS5 with hostname. DNS leaks also occur with HTTP proxies, which shouldn't happen. See also: http://sourceforge.net/p/mumble/bugs/1033/

2 1

Criteria for prioritizing pluggable transport work
by Roger Dingledine 30 Sep '13

30 Sep '13

Below is my first go at a list of criteria to consider when evaluating pluggable transports for readiness of deployment to users. The goal isn't to say that every transport has to "pass" each question -- rather, I'm hoping to fund a researcher-developer at some point soon to polish some of the research prototypes so we can include them in the PT TBB, and I wanted to think about guidelines for how they should prioritize which PTs to work on. What points is it missing? What points does it mis-explain? See also George's "How the pluggable transports factory works" mail: https://lists.torproject.org/pipermail/tor-dev/2013-August/005231.html Thanks! --Roger ---- Section one, how reviewed / reviewable is it: 1) Is the software published, and is it entirely free and open source? Some designs call for non-free (and non-distributable) components like Skype, a copy of Windows in a VM image, etc. 2) Is there a published design document, including a threat model? Is there a specification? How testable are its security / unblockability claims? We should also consider how much peer review the design has received, and whether the project is getting continued attention by its inventors. 3) What is its deployment history? What kind of users did it have and how many? How much publicity? Did it get blocked? Section two, evaluation of design: 4) How difficult or expensive will it be to block the design (by protocol, by endpoints, etc)? For example, what services or protocols does it rely on being usable or reachable? Expense could include actual cost or could include collateral damage. Another way to measure might be the fraction of censoring countries where the technique is expected to work. 5) What anonymity improvements does the design provide, if any? While many pluggable transports focus only on reachability and leave anonymity properties to Tor, some research designs use the pluggable transport interface to experiment with improved traffic analysis resistance, such as by adding padding to defend better against website fingerprinting attacks. 6) What's the bandwidth overhead? Some transports like Obfsproxy don't inflate communication size, while others like Stegotorus wrap their communications in a more innocuous protocol at a cost of sending and receiving more bytes. Designs with higher bandwidth overhead can provide better blocking-resistance, but are also less suited for low-bandwidth environments. 7) Scanning-resistance: how does the design fare against active probing attacks, like China's follow-up connections that test for vanilla Tor traffic? ("How the Great Firewall of China is Blocking Tor", Philipp Winter, FOCI 2012). Section three, evaluation of implementation: 8) Does the implementation use Tor's Pluggable Transport (PT) Application Programming Interface (API) already? Tor has a standard recommended approach so transport modules can be invoked and managed by the Tor process. The PT API also allows Tor to automatically publish capabilities of the transport, collect user and usage statistics from the transport, and so on. 9) Is the implementation cross-platform (Windows, OS X, Linux at least)? How about support for mobile platforms? 10) How easy is the build process, and how easy is deployment and scaling? For example, what software libraries does it require, how likely are we to get enough bridge-side addresses, etc? 11) How is the code from a security and maintainability perspective? Are there unit tests, integration tests, etc? While the underlying Tor channel provides security properties like encryption and authentication, pluggable transports can still introduce new security risks if designed or built improperly.

1 0

Announcing liballium (A C Tor Pluggable Transports Utility Library)
by Yawning Angel 30 Sep '13

30 Sep '13

Hello, For those aspiring Pluggable Transports authors out there, I've recently written a simple library that handles the Tor Pluggable Transport Configuration protocol. The idea is for this library to be the C/C++ equivalent to pyptlib (and maybe more, depending on how much time I have to work on it). The code is available at: https://github.com/Yawning/liballium It still needs more documentation, but all of the use cases are covered by a reasonably well commented example (examples/ptcfg_example.c). Questions, comments, feedback all appreciated. -- Yawning Angel

1 0

HTTPS Server Impersonation
by Rohit 30 Sep '13

30 Sep '13

Hi, I was thinking about proposal #203 (Avoiding censorship by impersonating an HTTPS server) and have a few thoughts. I'm not sure if I've understood how everything fits correctly but here goes: For each bridge, we give their identity fingerprint and a shared secret along with their IP address and port. ie: bridge <ipaddress:port> <fingerprint> <shared_secret> The fingerprint allows the client to verify the identity of the bridge (via signed certificate) while a TLS connection is being set up. The shared secret allows the bridge to authorize clients after the TLS connection is set up. The shared secret could be sent using AUTHORIZE cells as proposed in #189 and #190. The AUTHORIZE cell could be wrapped in a HTTP GET request header. This should satisfy most goals. - A passive attacker wouldn't be able to distinguish between HTTPS->HTTPS traffic and Tor->Bridge. (Both use TLS) - An active attacker wouldn't be able to fool a client into thinking it was talking to a bridge. (Client would verify identity using fingerprint) - An active attacker wouldn't be able to fool a bridge into thinking it was a client. (No shared secret) To do the actual HTTPS impersonation, we could use Design #3 or #2 from #203. Nginx could be the reverse proxy, forwarding connections to the webserver or bridge as required. Depending on what the bridge is pretending to be, we could simply have nginx sitting in front of the bridge. I'm not sure what type of site the server should pretend to be. Some sort of blog? Maybe a login page? Or it could pretend to be a proxy service or perhaps web based ssh site? Could even be a combination of them I guess. Code changes would include - writing an nginx module to handle authentication - tor would need to handle AUTHORIZE/AUTHORIZED cell Thoughts? Did I miss anything? Thank you for your time, Rohit

4 3

Damian's Status Report - September 2013
by Damian Johnson 30 Sep '13

30 Sep '13

Hi all. Present status: gobbling birthday carrot cake. Before that, though, did a few things worth noting in September... ====================================================================== Stem: Connection Resolution Support ====================================================================== Stem can now provide you with the active connections belonging to a process. This is similar to arm, capable of doing lookups via seven *nix and FreeBSD resolution methods... https://stem.torproject.org/api/util/connection.html#stem.util.connection.R… Unlike arm, however, this is a far cleaner implementation including both unit and integ tests. Unfortunately this doesn't yet work with Tor's DisableDebuggerAttachment feature, but I plan to look into workarounds for that soon. 'How do I use this', you ask? It's easy! https://stem.torproject.org/tutorials/east_of_the_sun.html#connection-resol… ====================================================================== Arm: Rewrote Starter Module ====================================================================== Arm is presently undergoing an overhaul, and this month I focused on its starter module. It's now shorter, has unit tests, and is just generally damn better... before: https://gitweb.torproject.org/arm.git/blob/refs/heads/release:/src/starter.… after: https://gitweb.torproject.org/arm.git/blob/HEAD:/arm/starter.py ====================================================================== Other news this month includes... * Google Summer of Code finals were last week. All the remaining students passed, having done great work - fingers crossed they stick around! * DocTor's python replacement is now happily chugging along on yatei and provides #tor-bots notifications. * Attended a local TA3M meetup hosted by Lee Fisher. I'll be presenting a 'tor ecosystem' talk at it in October. (https://www.seattleprivacy.org/?p=356) * Notified outdates relays that will soon be dropped from the network if they don't upgrade. (#9476) * Investigated tor regression reported by stem's jenkins tests. (#9746) * Code reviewed Aaron's TorPS. (https://github.com/torps/torps.git) * Fixed a stem caching bug regarding hidden service config options caught by wayzard. (#9792) * My site (https://www.atagar.com, which hosts arm) finally has SSL support. https://lists.torproject.org/pipermail/tor-commits/2013-September/062328.ht… Cheers! -Damian

1 0

File verification GUI tool
by Sherief Alaa 29 Sep '13

29 Sep '13

Hi Everyone, (moving this email from the support-team ML to tor-dev as Runa suggested.) I am starting to work on a small GUI tool for file verification because I find guiding users through the verification process on Windows/Mac through the command line painful. Tools in use: - Python 3.3 or 2.7 (still didn't decide yet). - PyQT - python-gnupg-0.3.5 I might also add a log window and a save log button to see what went wrong during the verification process. Attached is a draft design of how the tool would look like. On Mon, Sep 23, 2013 at 7:12 PM, Lunar <lunar(a)torproject.org> wrote: >How do you think users will be able to install such a tool on their >system? There won't be any installation required It's a single executable. >More importantly, how will they be able to ensure that it's >not a tampered version? I've thought about that and few things came to mind: - Include the executable inside TBB. - Host it somewhere and also provide a SHA-256 hash on a website or in a file. But this is all an endless chain because lets say I download TBB, then download gpg to verify it but then how do I make sure that gpg it self wasn't tampered with? (assuming I don't have it installed already.) Any help or suggestions would be much appreciated. Thanks. -- Sherief Alaa pgp 0x8623B882

6 6

Re: [tor-dev] Pluggable Transport Browser Bundle FTE Integration
by David Fifield 29 Sep '13

29 Sep '13

On Sun, Sep 01, 2013 at 01:32:23PM +0300, George Kadianakis wrote: > Kevin P Dyer <kpdyer(a)gmail.com> writes: > > === How do we invoke PTs? > > I had this discussion with Roger, but I don't see any open tickets or clear > > discussion on this already. If we have N>1 PTs and at least one bridge per > > PT, how do we select which PT (and which bridge associated with that PT) to > > use? Determinism is bad because then only one PT is used. Booting up all > > PTs is bad, especially if (say) the PTs make network connections prior to > > any incoming SOCKS connections. Selecting a random PT is potentially bad, > > too, depending upon how hostile and persistent and stateful the adversary > > is. > > That's an interesting question. I'm not sure if the process of Tor > picking bridges is deterministic or not. I should test it out. David > might know. > > (A good scenario would be that Tor treats bridges like guards and > selects some at random to build circuits.) I don't know how Tor decides which PT bridges to use. I would guess that it treats them like any other Bridge lines in torrc. You should see this ticket and blog post: "Config option to declare whether you're using bridges for reachability or for security" https://trac.torproject.org/projects/tor/ticket/4624 https://blog.torproject.org/blog/different-ways-use-bridge The idea behind it is that some users want covertness (I need to hide the fact that I am using Tor), and some users want reachability (I need some way to circumvent the firewall). The way I see it, the unstated policy of the PT bundles is to optimize for reachability. By default we launch all the transports we know about, so for example if three transports are blocked and one gets through, that is a success. This doesn't work for the first kind of user, for whom a blocked transport means they have been detected. This first kind of user is likely to have to take some extraordinary steps while using Tor in any case. I don't think we have a plan for how to make a bundle that, in its default configuration, is safe to use for all such users. However we can make a bundle that does reachability with no special configuration, so that's what we're doing. The new 3.0 series bundles ask you, on startup, whether you are able to connect directly to Tor or whether you have to do your own manual configuration (like adding bridges). The option to launch only one specific safe transport could in principle be added to such a UI. David Fifield

2 1

Help make the Tor stackexchange beta succeed
by Roger Dingledine 28 Sep '13

28 Sep '13

Hello Tor developers and anonymity researchers, Our Stackexchange beta is underway: http://area51.stackexchange.com/proposals/56447/tor and we could use some more participation from actual Tor developers, anonymity researchers, and so on. The goals include a) building a good set of answers to questions around Tor research and development, and b) growing a larger army of people who know these answers and can answer more such questions. If you can help out, please send me mail off-list, including what email address I should tell them for you, and I'll hook you up. Steven, Philipp, Jens, and I can't do it by ourselves. :) (And as a carrot, if you sign up you can read my answer to "What are the options to remove Mevade botnet from Tor?") Thanks! --Roger

1 0

New GPG key for Mike Perry
by Mike Perry 27 Sep '13

27 Sep '13

Hi everyone, I've finally made a new GPG key (after a scant 7 years!). This new key will be used to sign email from me going forward, and will be used to sign software releases until such time as I get around to creating a second set of keys on a hardware token for that purpose. While I dislike the Web of Trust for a number of reasons*, my plan is to cross-certify these two sets of new keys, and also sign both with my old key. Hence I will not immediately be issuing a revocation for my old key. The new key is attached, and is available on the keyservers (with a signature from my old key) at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x29846B3C683686CC Here's the fingerprint and current subkey information for reference: pub 8192R/29846B3C683686CC 2013-09-11 Key fingerprint = C963 C21D 6356 4E2B 10BB 335B 2984 6B3C 6836 86CC uid Mike Perry (Regular use key) <mikeperry(a)torproject.org> sub 4096R/717F1F130E3A92E4 2013-09-11 [expires: 2014-09-11] sub 4096R/A3BD8153BC40FFA0 2013-09-11 [expires: 2014-09-11] This message should also be signed by my previous key, which was used extensively to sign my email and my source code releases prior to today. * Ensuing flamewars about the Web of Trust should reply only to tor-talk. -- Mike Perry

1 0

[tahoe-dev] the GNU 30th Birthday party!
by Eugen Leitl 27 Sep '13

27 Sep '13

----- Forwarded message from Zooko O'Whielacronx <zookog(a)gmail.com> ----- Date: Fri, 27 Sep 2013 05:00:04 +0000 From: Zooko O'Whielacronx <zookog(a)gmail.com> To: tahoe-dev <tahoe-dev(a)tahoe-lafs.org> Subject: [tahoe-dev] the GNU 30th Birthday party! Folks: Tahoe-LAFS is one of the featured projects at the GNU 30th Birthday Party Hackathon! https://www.gnu.org/gnu30/celebration I'm going to be there in person in Cambridge. What I want to do during the Hackathon is make Tahoe-LAFS work better with Tor and/or I2P. I know that at least a couple of Tor developers and at least one I2P developer will be there in person, so this is a good opportunity to collaborate face-to-face or side-by-side. One thing I could spend Hackathon time on is just to contribute some patch review service to the Tor project, if it seems like they want that. Issue tickets relevant to this: Go to https://Tahoe-LAFS.org, click on "View Tickets" → https://tahoe-lafs.org/trac/tahoe-lafs/wiki/ViewTickets , click on "anonymity" → https://tahoe-lafs.org/trac/tahoe-lafs/query?status=!closed&keywords=~anony… Eyeballing those, I recognize the following as especially ripe, because the I2P folks have been working on them and flagging them as blockers for I2P: #68, #1010. https://tahoe-lafs.org/trac/tahoe-lafs/ticket/68# implement distributed introduction, remove Introducer as a single point of failure https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1010# use only 127.0.0.1 as local address See also a couple of patches that the I2P people are trying to contribute to foolscap, and which are also needed for full Tahoe-LAFS+I2P integration: http://foolscap.lothar.com/trac/query?status=!closed&keywords=~i2p You can join in! Just connect to us on IRC -- irc.freenode.net channel #tahoe-lafs -- or physically show up in Cambridge. Or, I suppose, at one of the other GNU 30th Birthday celebrations around the world: https://www.gnu.org/gnu30/ (scroll down to "Satellite Events"). ☺ Regards, Zooko _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Pluggable transport biweekly meeting - Friday Sept 27
by vmonmoonshine＠gmail.com 27 Sep '13

27 Sep '13

Hello PT devs, We'll have our next meeting (almost) today Friday - Sept 27 at CEST: 18:00 BST (Summer GMT): 17:00 UTC: 16:00 EST: 12:00 MNT: 10:00 PST: 9:00 @ #tor-dev on irc.oftc.net As last time asn is going to take us through this after identifying the participant we go one by one and update the group about our recent progress and blockers. As people suggested last time after update we will have a brief code review session when each of us will take at piece of code of another developer and comment on it. If you missed last the meeting or you need a bit of reminder you can find it summary here: https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/meeti… See you in few hours, Vmon

1 0

tor-bundle:How to extend the firefox context menu?
by mabra＠manfbraun.de 27 Sep '13

27 Sep '13

Hello ! I am doing really very boosted webserach in the last month. I am using the tor-bundle, if I am searching in several different and sensitiv areas, like wiki-leaks etc. >From my long term experience with all other search engines, beside google, they really dont allow you to continue, if the browser crashes. But this happens in minimum 10 times a day :-( So I want to use google to search, without allowing them to track me. This is why I use the tor-bundle. Using tor for simple webpages is usually slow. What would beome best for me, is, to use the tor-bundle together with the google search engine, but then, have a context menue (right click) to open another browser for a given search result item. The other browser then, is not configured to use the tor network. Does anyone has an information, how I, as an end-user, can exceed the context menue in the tor-bundles browser? Thanks anyway and best regards, ++mabra

1 0

Using the consensus-health web page to debug the Tor network
by Karsten Loesing 26 Sep '13

26 Sep '13

Hi Damian, Roger and I discussed the consensus-health web page that the Java version of DocTor produces [0] but your Python version does not. Roger says he uses that page to debug the Tor network. In particular, he says he scans the huge relay flags table to spot differences between relay flags assigned by the directory authorities. I'm pasting the IRC log below, but we should move this discussion to email, because it seems unlikely that we're all present in #tor-dev at the same time to discuss this. I see four ways how we can make most people mostly happy: 1.) We add votes documents to Onionoo (#9778) and include relay flags contained in votes in relay details pages of Atlas/Globe, so that people can find out what the different directory authorities think about their relay. We write a new Onionoo client that fetches this information for all running relays and produces a long table of relay flags. Before we do all this we make sure that there's nothing else on the consensus-health web page that Roger secretly hoped to keep. Then we shut down the Java DocTor. 2.) We rewrite the website-generating part of DocTor in a language we're happier to maintain long-term. This could be part of your DocTor, or of a new tool. Then we shut down the Java DocTor. 3.) We keep the Java DocTor running to generate the website, but disable the part that sends notifications to the mailing list and to the IRC bot. Or rather, I'll want to move the page away from metrics.tpo to, say, consensus-health.tpo or consensus-explorer.tpo, because it has always been a hack to serve it on metrics.tpo. Then we hope the Java DocTor never breaks. 4.) We do something much smarter which I didn't think of yet. What do you think? All the best, Karsten [0] https://metrics.torproject.org/consensus-health.html 08:04:49 < karsten> armadev: about removing per-relay votes from https://metrics.torproject.org/consensus-health.html. that was intentional, because the page took so long to load and it seemed nobody cared. 08:05:14 < karsten> armadev: but it seems the next step will be to kill that web page entirely.. 08:05:34 < karsten> the reason is that atagar's consensus-health checker will take over very soon. 08:05:56 < karsten> so, what information from the consensus-health page do you still need, either the current one or even the one with per-relay votes? 08:06:10 < karsten> we should try to rescue that information then. 08:07:16 < armadev> karsten: is atagar's consensus health checker up yet? 08:07:22 < karsten> yes, it is. 08:07:26 < armadev> url? 08:07:33 < karsten> it's sending mail to tor-consensus-health@ and to #tor-bots. 08:07:36 < karsten> it has no website 08:07:48 < karsten> it's sending out warnings if something goes wrong. 08:07:56 < karsten> when* :) 08:08:54 < armadev> karsten: in this case, what i wanted from the consensus health page was the set of votes per authority for 000000000000myTOR2 08:08:56 < karsten> right now, both consensus-health things send mail to that list. the ones at :03 are from mine, the other ones from atagar's. 08:09:11 < armadev> i pieced it together manually from moria1's v3-status-votes, but i'm special so i can do that 08:09:16 < karsten> right 08:09:25 < karsten> I thought about this a while ago. we could include votes in onionoo. 08:09:34 < karsten> not sure how yatei will like that though. 08:09:50 < karsten> but it's the votes you care about, ok. anything else from the consensus-health page? 08:10:16 < karsten> wfn: ^^ we should talk about this. 08:11:05 < armadev> s/votes/votes about flags/ here 08:11:23 < karsten> right. 08:37:19 < armadev> it seems i used consensus-health as consensus-explorer 10:11:35 < armadev> karsten: can you fwd me a sample mail from the health checker mailing list? 10:12:07 < karsten> armadev: they're archived: https://lists.torproject.org/pipermail/tor-consensus-health/2013-September/… 10:13:43 < armadev> oh good 10:13:56 < armadev> that's a very short mail. 10:14:02 < armadev> it has, like, nothing from the consensus health checker 10:14:20 < karsten> that's the things that need fixing to make it quiet again. 10:14:42 < armadev> why is "it takes a long time to load" a bug in consensus-health.html ? 10:15:37 < karsten> well, the page is huge, and firefox can't handle that very well. that's not a bug, but an inconvenience. 10:16:09 < armadev> sure 10:16:25 < karsten> I could have split the page into two. 10:16:34 < karsten> but anyway, the entire page is going away soon. 10:16:39 < armadev> if you were planning to drop it entirely, you could just leave it alone? 10:17:12 < karsten> as unmaintained service? 10:17:36 < karsten> I'd rather take the pieces we like and integrate them in maintained services. 10:17:37 < armadev> i guess. or write a howto for how to take votes in and generate the html, and i'll run it on moria 10:17:53 < armadev> though i think it needs more than votes as input 10:18:11 < armadev> i've used most parts of this page over the past few months 10:18:13 < karsten> it downloads votes and consensuses. 10:18:19 < karsten> I see. 10:18:42 < armadev> i have votes and a consensus on moria 10:18:49 < armadev> if that's the input, i can just cron it to run on moria 10:18:58 < armadev> based on the votes i see and the consensus i see 10:19:09 < armadev> unless i guess it requires a massive tomcat engine too :) 10:19:15 < karsten> it doesn't. 10:19:17 < karsten> it requires java. 10:19:29 < karsten> and produces a static html that you can service with whatever. 10:19:55 < karsten> well, if you need it, it's easier to keep it running on yatei. 10:19:57 < armadev> i don't have any java. i guess i could add it. or we could stick it on people.tp.o or something 10:19:59 < armadev> right 10:20:09 < karsten> and just turn off the email notifications, because atagar's thing will send those. 10:20:11 < armadev> i use it for debugging the network 10:20:32 < karsten> ok 10:20:58 < karsten> would #9778 solve the problem with the missing relay flags table? 10:20:59 -zwiebelbot:#tor-dev- [tor#9778: Adding votes documents to Onionoo] 10:21:08 < karsten> assuming atlas or globe would show those? 10:21:32 < armadev> do i have to load each relay one page at a time? 10:22:05 < karsten> probably. 10:22:31 < karsten> so, you're looking through the table to spot problems? 10:22:41 < karsten> or, have been looking, when the table was there. 10:22:41 < armadev> yes. and to get a sense of trends. 10:22:44 < armadev> right 10:22:57 < armadev> i guess in this most recent case i just wanted one relay 10:23:11 < armadev> but after that, i realized that i wanted to know how many relays had a Running flag from those two authorities and no Running flag from any others 10:23:33 < karsten> ok 10:23:42 < armadev> (i still want to know :) 10:24:06 < karsten> let me re-enable the table and think about a better long-term solution.. :) 10:24:07 < armadev> (related to https://trac.torproject.org/projects/tor/ticket/9775 ) 10:24:08 -zwiebelbot:#tor-dev- [tor#9775: Authorities should report when they don't vote Running but some addresses are still reachable] 10:24:48 < armadev> we are dropping an unknown number of relays from the consensus because they enable ipv6 but screw up the reachability 10:25:16 < armadev> hopefully every relay operator who knows what ipv6 is also knows how to check relay-search for themselves 10:28:21 < karsten> the next consensus-health.html will contain the relay flags table again. in roughly 35 mins. 10:29:51 < armadev> thanks. sorry for the troubles. and i understand the drive to get rid of extra things. i wish we had more things that were actually extra. 10:32:10 < karsten> yeah, we have a lot of stuff. and some of it is really old and hasn't seen love for too long.

2 6

Kickoff Meeting Times for Project Otter [all next week]
by Tom Lowenthal 26 Sep '13

26 Sep '13

There seem to be relatively good times for all three Project Otter kickoff meetings next week. There's no need to RSVP, but if you can't make it and have something to contribute please try to provide that input as soon as possible in the form of a "comments" section on the relevant page on the wiki. Otter index page: <https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter> All the meetings will be held in #tor-dev on `irc.oftc.net`. Here are the times: * Attentive Otters [IM bundle]: Weds 2013-10-02 1100-1200 Pacific * Boisterous Otters [Help/outreach/l10n]: Weds 2013-10-02 0900-1000 Pacific * Cute Otters [Hidden services & publishing]: Weds 2013-10-02 1600-1700 Pacific If you have other questions or there are other problems, please reply here. -Tom

1 0

IRC meeting to discuss sponsor F progress on Mon September 30, 18:00 to 19:00 in #tor-dev
by Karsten Loesing 24 Sep '13

24 Sep '13

Hi all, I'd like to schedule an IRC meeting to discuss what progress we made on sponsor F deliverables in September. Time and place are: Mon September 30, 18:00 to 19:00 UTC in #tor-dev That's in roughly 6 days 3 hours from now. The time in other timezones is: 11:00 in San Francisco 14:00 in Boston 20:00 in Berlin 21:00 in Athens 23:30 in New Delhi People who should attend are: Andrea, Andrew, Arlo, Colin, David, George, Linus, Matt, Nathan, Nick, Roger, Tom, Ximin, and anyone else who wants to attend. If your name is on that list and you're working on sponsor F stuff, but the date or time doesn't work for you, please email me your progress and I'll report it for you at the meeting. Thanks, Karsten

1 0

Re: [tor-dev] File verification GUI tool
by Matt Pagan 24 Sep '13

24 Sep '13

On Mon, 23 Sep 2013 17:59:23 -0400 Roger Dingledine <arma(a)mit.edu> wrote: > On Mon, Sep 23, 2013 at 05:45:36PM -0400, Sukhbir Singh wrote: > > > I am starting to work on a small GUI tool for file verification > > > because I find guiding users through the verification process on > > > Windows/Mac through the command line painful. > > > > Just a thought: have you considered doing this through a Firefox > > extension instead? > > It does seem like a Firefox extension is a better alternative. The > "here's an executable you just fetched from the Internet, please run > it" model is likely bad news, and also isn't the right habit to be > teaching users. > If you go the browser extension route, there is a now defunct Firefox add-on called FireGPG that implemented GnuPG in the web browser. This add-on was discontinued in 2010 and it's primary focus was encrypting and decrypting gmail messages. However, the software was open source and the code is still available. If you decide to implement this project as a browser extension, you might want to see if there are any usable parts you can salvage from that rubble (there might not be). http://getfiregpg.org/s/home

3 2

Onion IPv6 transport needed [was: ed25519 HS identity keys]
by grarpamp 24 Sep '13

24 Sep '13

On 9/24/13, Bernhard R. Fischer <bf(a)abenteuerland.at> wrote: > On Thursday 19 September 2013 10:53:13 grarpamp wrote: >> On 9/13/13, George Kadianakis <desnacked(a)riseup.net> wrote: >> > This proposal is in serious need for comments. >> > >> > 1.2. From the PoV of the HS client: >> > Tor clients can distinguish new-style HS addresses from old ones by >> > their length. Legacy addresses are 16 base32 characters, while new >> > ones are 56 (XXX) base32 characters. >> > >> > If Tor is asked to connect to a legacy address it SHOULD throw a >> > warning and advocate the use of new-style addresses (it should still >> > connect to the HS however). In the future, when old-style HS >> > addresses are close to depletion, we can introduce a torrc parameter >> > that blocks client connections to old-style HS addresses. >> >> As commented earlier on this list... >> https://lists.torproject.org/pipermail/tor-dev/2013-August/005286.html >> >> This addressing change will break onioncat (IPv6) within Tor. >> https://www.onioncat.org/ >> >> I suggest a solution to transporting IPv6 within Tor be >> maintained/deployed concurrently with any change in >> current onion addressing and or transport mechanics. > > > 56 base32 characters means 280 bits. > And yes, the new addresses will break Onioncat addressing mechanism. > > Actually this is the same problem as with I2P which uses 256 bit addresses > for > the destinations. > Then, as a workaround I implemented an /etc/hosts file-based lookup. This is > > not a perfect solution but it was better than nothing ;) > > I'll think about a new method of addressing, which allows forward > compatibility (DNS comes into my mind -- I know...) I know, yet I don't mind the central nature of DNS for naming. It works on clearnet, you can subscribe to multiple roots to avoid censure and under an anonymous system someone will always be willing to carry the sensational records. So you can resolve just fine. The problem is the transport. Being able to resolve is pointless if you can't transport. And if you can transport you can resolve on top of that any which way you want, including DNS. I'm sure this is not really a naming issue but an addressing one. If people expect Tor, I2P etc to ever evolve to support for real p2p/social apps and services and build communities beyond what crippling unidirectional TCP is capable of (which I suggest we should), they need to transport IPv6. And to do that you need to have nodes fall within private RFC/48 addressing bound to an interface... whether natively as Tor currently does by byproduct with onioncat providing the layer, or via some future address mapping layer [1]. The 'DNS' you speak of could map 80bit to n-greater-than-80bit, (256/280/512 bit) within an internal backend of a new ocat that then transports to the higher bits. But if actual DNS was used for that it would invoke the root/censor/uptime/trust issues of DNS for *addressing* not naming, and we don't really want that type of breakdown there. Ocat currently does not have those problems. And if someone comes up with the likes of [1], a central trust system like DNS won't be needed. To the extent this is a wider summary, if there's an IPv6 transport (mod hidden addressing) ticket where reference to this should be lodged, please do. [1] Search for IPv6 on zzz.i2p, there were some comments found there of possible map considerations like signed announcements into DHT. Maybe also namecoin-like addressing.

1 0

Re: [tor-dev] Limiting Tor RAM usage
by Gordon Morehouse 23 Sep '13

23 Sep '13

References for prior message: 1. http://linux.die.net/man/2/setrlimit 2. http://coldattic.info/shvedsky/pro/blogs/a-foo-walks-into-a-bar/posts/40 Best, -Gordon M.

1 0

Limiting Tor RAM usage
by Gordon Morehouse 23 Sep '13

23 Sep '13

Hi all, I brought this up in tor-relay, where I'm keeping most of my relatively easy/low key stuff on getting Tor to work real solidly on the Raspberry Pi. However, the biggest problem I'm having right now (with the latest version) is occasional visits from the OOM killer, usually right after my relay gets a Stable flag and traffic increases. :( I really need a way to hard-limit the RSS (physical memory usage) of the Tor process. Would setrlimit(2)[1] work on the Tor process? This is Linux. For those that don't want to cruise the man page, here's the relevant discouraging text which may or may not apple to Tor, from a blog post on limiting memory and CPU time usage on Linux[2]: > Ulimit (the console tool, not the system call) is the first thing a Linux user would think about. You launch it in the shell, set "soft" and "hard" limits for each resource, and children, which are invoked in this shell, are limited in memory and time. > > Its limits are imposed like this: > [snip] > > Memory limit is set via the same system call. Memory limit is enforced by returning ENOMEM from a violating malloc() syscall. This usually leads to an unhandled exception of sorts, and the program (or its interpreter) is forced to terminate. If that won't work, how can I achieve this with a high degree of precision? MaxAdvertisedBandwidth *is not* going to cut it for systems that are low on RAM, but have enough CPU horsepower to happily forward a few Mbps. Thanks much, -Gordon M.

1 0

[GSOC] Status report - Tor capabilities
by Cristian-Matei Toader 23 Sep '13

23 Sep '13

Hello tor-dev, For the past two couple of weeks, stage 2 has ended [1], and stage 3 has begun [2]. Stage 2 didn't change by much, apart from a few change requests from nickm. As part of stage 3, some important changes were made: - the structures involving how a sandbox configuration is being managed has changed, in order to allow multiple configurations; the sandbox type now consists of the syscall array of no-parameter filters, and a list of parameter syscall configurations; now each parameter syscall is handled as a function pointer and a list of parameters which are used with the function pointer in order to initialise that particular filter; this all may sound over-complicated, but it's actually a quite intuitive non-hacky version of what was going on before. - a filter was developed (it's actually unexpectedly short) for worker threads only, and it is currently working just as it should in the stage 3 public branch - currently I have updated the general filter to include the prctl filter required to allow loading other seccomp filters, which is necessary for the purpose of stage 3; there is also an option for a general filter which disallows any further filters to be loaded, and I am currently working at loading this updated filter at an optimum location. I am planning to continue working on stage 3 past the hard deadline for the GSOC project, but when university starts I will probably prioritise studies over this project. It has been a pleasure working for the tor project, I will keep contributing (either sandboxing related or otherwise), and will make sure to keep in touch on IRC. [1] https://trac.torproject.org/projects/tor/ticket/9249 [2] https://trac.torproject.org/projects/tor/ticket/9730

1 0