[tor-talk] How do i check the archives?

[Andrew F]

How do i check the archives?  thanks

--
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] is it me or did tor talk get really quiet?

[Andrew F]

Transparency is key at all levels and on all topics.
​Without transparency, Tor will end.  It will be a slow degradation.
Tor will loose participants and funding slowly at all level and in all
capacities.
Development will slow and eventually, it will fade.

And who benefits?  Not Tor users.

If you wanted to destroy Tor, this is a perfect way to do it.
Create a separate mailing list if you want but all topics should be
free and open for conversation.

Openness and transparency is the life blood of Tor, without it, the project
is dead.
Its just a matter of time.

On Mon, Sep 19, 2016 at 6:57 AM, Alec Muffett 
wrote:

> On 18 September 2016 at 04:30, grarpamp  wrote:
>
> > No it's not just you. Ever since Jakegate / Torgate Tor Project
> > Incorporated has seemingly enforced lockdown, censorship, and
> > comms hardening, beginning with their own silence and that of those
> > they control. A chilling effect.
>
>
> I think it's awesome, to the point where I've actually resubscribed.
>
> It's nice to have a maillist which is about the topic of Tor, rather than
> filled with conspiracy drama.
>
> Now maybe I can contribute without fear of being swamped in ad-hominem
> bullshit.
>
> -a
>
> --
> http://dropsafe.crypticide.com/aboutalecm
> --
> tor-talk mailing list - tor-talk@lists.torproject.org
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>



--
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] is it me or did tor talk get really quiet?

[Andrew F]

​I ued to get several post a day.  Now I get less then a couple a week?
What is the most active Tor mailing list?
​

--
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Elliptic Curve Crypto and the NSA

[Andrew F]

spline curves.


On Mon, Nov 2, 2015 at 2:15 PM, Martijn Grooten 
wrote:

> On Sun, Nov 01, 2015 at 10:15:08PM -0500, Michael McConville wrote:
> > Dual_EC_DRBG, a random number generation algorithm, was very likely
> > backdoored by the NSA. Tor doesn't use it. There is little evidence that
> > other EC algorithms have been subverted, although it's possible.
>
> I agree with this statement, though I believe in this case people aren't
> suspecting a backdoor but a weakness in ECC that the NSA has found and
> that they are worried someone else will find (or possibly has found
> already) as well. That's possible, but I consider it extremely unlikely.
>
> Martijn.
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJWN2/kAAoJEI5dMs9dIv8ZJeoH/0nF5Gv+QEp6ehYnMjrvFYv0
> Wqd9lqp3fxHNMo3jUZd3ZE9U0XXVldlkaCiwDTyNF5unt8sVcYWPjrQqeyGuYbav
> sOXABPt1ACCdO0EGxVxcc9sPBeo1DIaqT9kvw0s5/aCl98/p8ETFTe15DYQJygee
> VASPogl4Yvx8wazl8Nc2vGA+sVS95l3fjkwh4qD9I7Nm208+SFnVVHTfF7zdr1Vc
> KyyID1CD3YRBhnmYxiGAzPQaqW2MTBCwRLl6JE4VBfK1EYMgzU1koV6TvI4tXTN2
> 7RTT7RNO7zvaLrqd9DiXtheq3ijfDi5rJYND0mmwYqO5cvJrroCjgq24g2tdLfg=
> =y/Gd
> -END PGP SIGNATURE-
>
> --
> tor-talk mailing list - tor-talk@lists.torproject.org
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>
>
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] (no subject)

[Andrew F]

Would Linux work as a rescue disk for him?


On Friday, June 19, 2015, Joe Btfsplk joebtfs...@gmx.com wrote:


 On 6/19/2015 4:17 AM, Andy Iwanski wrote:

 Can someone please help me.  I have lost access to all my files.  I do
 not understand any of this and need to access my stuff.  I can be reached
 at XXX-XXX-.  I tried following the directions but it didn't work.

  Also, it's a bad idea to post personal data (phone #, home addresses,
 etc.) anywhere on the internet that the general public* could access it.
 * Meaning, spammers, marketers, but possibly also persons w/ some
 malicious intent.
 --
 tor-talk mailing list - tor-talk@lists.torproject.org
 To unsubscribe or change other settings go to
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor2web support for HTTPS on .onion

[Andrew F]

Do you have a synopsis of what Tor2web is and what it does?  How to use
it.  thanks.

On Tue, Nov 18, 2014 at 9:37 AM, Giovanni Pellerano 
giovanni.peller...@evilaliv3.org wrote:

 Dear all,

 We’re happy to announce the release of Tor2web 3.1.30 [1] that includes
 support for access to .onion sites over TLS.

 Tor2web[2] is HTTP proxy server software used for accessing onion sites.

 The Tor2web support for TLS includes the following security features:

 - TOFU  (Trust on First Use) certificate validation by caching the
 fingerprint of the .onion site
 - Validation of CN (Common Name) and SANs (Subject Alternative Names)
 specified in the certificate of the .onion domain.

 As Facebook has recently opened its own onion site [3], we’ve been
 coordinating this release with Alec Muffett from Facebook in order to
 block access to Facebook by means of the Tor2web proxy. Because Facebook
 has a normal website, using Tor2web merely presents an option for users
 to hurt themselves.  You can see the Facebook block here:
 https://facebookcorewwwi.tor2web.org

 Current Tor2web conduits are:

 - tor2web.org (running 2 out of 3 servers after recent server takedown
 due to CryptoWall abuses)
 - tor2web.fi by Ahmia (https://ahmia.fi)
 - onion.lt
 - onion.to (temporally dead after server takedown)
 - tor2web.blutmagie.de (expired certificates)

 We remind the community that Tor2web yearns for additional operators.

 If you want to run a Tor2web conduit or otherwise support Tor2web:
 - take a look at our wiki https://github.com/globaleaks/Tor2web-3.0/wiki
 - join the tor2web-talk mailing list
 http://lists.tor2web.org/mailman/listinfo/tor2web-talk

 [1] https://github.com/globaleaks/Tor2web-3.0
 [2] https://www.tor2web.org/
 [3]
 https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs

 Giovanni Pellerano - Founding Member
 HERMES - Center for Transparency and Digital Human Rights
 http://logioshermes.org - https://globaleaks.org - https://tor2web.org -
 https://ahmia.fi



 --
 tor-talk mailing list - tor-talk@lists.torproject.org
 To unsubscribe or change other settings go to
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk


-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] anonabox : the Tor hardware router

[Andrew F]

Shawn,
I agree.  I guess my real issue is that a for-profit company's should share
the wealth and help build the TOR network via server sponsership in direct
porportion to the incrmental bandwidth thier custermers use.  This is in
there own self interest in fact.  If the network slows down, thier
customers experience will degrade.  It would also be nice to see them
support development by donations.  In addition, perhaps even offering
bounties for wish list items the core team does not have time for.  (there
is an existing list)

Now in the interest of more annonimity for tor users, I am off to watch cat
videos.



On Thursday, November 13, 2014, Mirimir miri...@riseup.net wrote:

 On 11/13/2014 06:45 AM, Derric Atzrott wrote:
 [ On 11/12/2014 17:18:15 -0700, Mirimir wrote:]
 [ On 11/12/2014 01:13 PM, Shawn Nock wrote:]
  If all users use Tor only for sensitive communications, then state
  level adversaries can round up all users of Tor and the provided
  anonymity is of little use.
 
  That's true. But there is a sense in which Tor should be used
  selectively: It's counterproductive to use Tor when identity and
  geolocation are desired and/or essential. If my bank, for example, sees
  Tor IPs, it might freeze my account. And that's a _good_ thing.
 
  I disagree.  I'd rather have more people using Tor even for things
  where identity is an essential part of authenticating you, like a bank.
 
  I'd rather see the bank move to other methods.  If we can obsolete
  automatic location based identification I think that is a good thing.
  You should be able to share your location with your banks website, but
  it should not automatically be able to gather it.

 Ideally, as a goal, I agree. That would increase the anonymity set. And
 there can be no real freedom without anonymous financial services. But
 in reality, currently, financial services care about identity and
 geolocation. So anonabox will do collateral damage.

  That's why anonabox is so dangerous, even if there were no security
  holes. Guaranteed hardware-based Tor connectivity is great, for those
  who know where, when and how to use it. But providing that to users who
  don't understand the situation is dangerous. And doing it via WiFi,
  which is virtually unsecurable, is even worse.
 
  This I can agree with.
 
  Cat photos and Amazon shopping by non-subversives gives vulnerable
  users cover and is fundimental to the usefulness of Tor.
 
  Cat photos, yes :) But Amazon shopping, maybe not so much.
 
  Why wouldn't Amazon shopping provide Tor users with cover?

 Well, it's nontrivial to buy anonymously from Amazon. For most folk
 without cover corporations and stuff, gift cards are about it. There is
 the eGifter workaround for using Bitcoins, however. But still, there's
 the fact that stuff must be sent somewhere. Most folk lack anonymous
 mailboxes and drops, so that's their home or place of business.

  Should entities encouraging heavy routine use of Tor contribute
  relays? Absolutely.
 
  Well, I gather that there's currently a surplus of non-exit relays and
  bandwidth. So specifically they should contribute exit relays. That's
  not so easy, however, and there's far too little support for it from the
  Tor Project, in my (albeit limited) experience.
 
  This is definitely a problem that I would love to see worked on some.

 What's ironic is the particular difficulty of running exits anonymously.

  Thank you,
  Derric Atzrott
 
 --
 tor-talk mailing list - tor-talk@lists.torproject.org javascript:;
 To unsubscribe or change other settings go to
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] anonabox : the Tor hardware router

[Andrew F]

Great, so now ALL traffic from a user of this product will be on
TOR?  Amazon, Facebook, looking at cute cat videos
Have they have they set aside a few dollars of profit  to host servers to
match bandwidth demand?

You see my point?  Right.  Tor should be used selectively.


On Wednesday, November 12, 2014, grarpamp grarp...@gmail.com wrote:

 On Wed, Nov 12, 2014 at 9:27 AM, Aymeric Vitte vitteayme...@gmail.com
 javascript:; wrote:
  I was wondering when this would happen.  Any idea if this is from the
  guys who put together the box or just some random dude?
 
  If they want to make a good image for themselves, I'm not sure that just
  copy/pasting their text from Indigogo onto this mailing list is the best
  way to go about it...
 
 
  I don't think there is any hazard in what they are doing, but probably
  they don't feel they sould expose themselves to this list since they
 explain
  that they are already very well connected to the Tor community:
 
  He also volunteers for the Tor support forum the Tor Stack Exchange,
 and is
  an admin for the official Tor project discussion page on LinkedIn.
 
  Still amazed that some blogers are recommending this, apparently they
  promise to send them a box.
 
  Seriously when will these guys be stopped? They have lied enough, the Tor
  project should say something (or are you really connected to them as they
  claim?)

 https://web.archive.org/web/20140516233302/http://augustgermar.com/

 There appears to be a few tech support lines for this product
 and any official-admin-ness issues.
 --
 tor-talk mailing list - tor-talk@lists.torproject.org javascript:;
 To unsubscribe or change other settings go to
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Third-parties tracking me on Tor

[Andrew F]

Anton, nothing wrong with this thread.  I just added my exp to support the
original poster.
Also I am not associated with remax.  But that is impressive. Your quite
the detective.


On Friday, August 22, 2014, no.thing_to-h...@cryptopathie.eu wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Sorry, but I guess that something is wrong with this thread. The first
 mail came from 'TerryZ at Safe-mail.net' (1) and the further replies
 of the surveilled person from 'andrewfriedman101 at gmail.com' (2)(3).
 I checked the mail-headers and the hostnames matched the addresses
 (rimon.safe-mail.net and mail-la0-x232.google.com). When you search
 for the gmail address, you get to a real estate broker in California
 (4) and some spam-lists (5)(6).

 Perhaps this is one person who changed the mail-address for this list
 from Wed to Fri, or that are two persons.

 Best regards

 Anton


 1) https://lists.torproject.org/pipermail/tor-talk/2014-August/034468.html
 2) https://lists.torproject.org/pipermail/tor-talk/2014-August/034478.html
 3) https://lists.torproject.org/pipermail/tor-talk/2014-August/034479.html
 4)

 http://www.rea-ca.com/list/117824-andrew-s-friedman-re-max-estates-in-agoura-hills-ca
 5) http://emailzz.com/category/index.php?id=398page=876
 6) http://www.emaildatalist.net/1/download-email-free-10681/10681.html

 - --
 no.thing_to-hide at cryptopathie dot eu
 0x30C3CDF0, RSA 2048, 24 Mar 2014
 0FF8 A811 8857 1B7E 195B 649E CC26 E1A5 30C3 CDF0
 Bitmessage (no metadata): BM-2cXixKZaqzJmTfz6ojiyLzmKg2JbzDnApC



 On 22/08/14 16:54, Thomas White wrote:
  To me your issues sounds like an endpoint security problem, not
  Tor. People don't just break the anonymity Tor provides and then
  just comment on the cat pictures you are looking at on the
  internet, they usually sell it where there is good money offered or
  report it back and have it fixed by the tor developers.
 
  I would make sure your system is free of malware or other local
  snooping because what you've described would align in my mind with
  a client-side problem, not something of the Tor network.
 
  On 22/08/2014 15:51, Andrew F wrote:
  I have had people contact me while i was in a technical chat
  room and tell me not only what site I went to but the name of a
  file I down loaded.
 
 
  On Thu, Aug 21, 2014 at 4:54 PM, Anders Andersson
  pipat...@gmail.com javascript:; wrote:
 
  After using Tor for some years I realized that third-parties
  can
  determine what sites I visit when watching my internet
  activity.
 
  What do you mean by third-parties?
 
 
 
  When I visit hidden services how can they know what site it
  is or know
  what site I visit that's not on Tor?
 
  Why do you think they know?
 
 
 
  How did they know I was using TorMail when it was available
  and the
  content of the e-mail I sent?
 
  Who are they? -- tor-talk mailing list -
  tor-talk@lists.torproject.org javascript:; To unsubscribe or change
 other
  settings go to
  https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
 
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)

 iQEcBAEBAgAGBQJT951uAAoJEMwm4aUww83wfOcH+wWg7sr9OMCdwjQ07QRfBgrI
 gVj1/+9N3h1qNRJEeRcAkf0Kp80F157yZ2YiqDpcYT5DoErIXeo38iCZNKOaP4qB
 o/+ezPuTUmZo6K9uPyeFbpTWaIa7rnHFaspoLnFvSJZXrzICqlfAAg7k6ZxoYSRV
 tkCHoUFrFELql5U1F8BwC1nmFCfhGBtXV1WZCXmnCQIGVoaiw3diDgeobEbV/x1v
 cIM813Byr6TD+bX/j20mNUR8y6Id4+wuuv483lAQejYVGQhWfH9AFD0gG70DBXOU
 lv89Sc1RhilA4Rlws28tLAUPCUHIy0QDasKw0F9+wCYaKHFlD/8kU0pfafnvTc0=
 =1vrI
 -END PGP SIGNATURE-
 --
 tor-talk mailing list - tor-talk@lists.torproject.org javascript:;
 To unsubscribe or change other settings go to
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Third-parties tracking me on Tor

[Andrew F]

I should add, this was the regular web, not a hidden service site.



On Fri, Aug 22, 2014 at 7:51 AM, Andrew F andrewfriedman...@gmail.com
wrote:

 I have had people contact me while i was in a technical chat room and tell
 me not only what site I went to but the name of a file I down loaded.


 On Thu, Aug 21, 2014 at 4:54 PM, Anders Andersson pipat...@gmail.com
 wrote:

  After using Tor for some years I realized that third-parties can
 determine what sites I visit when watching my internet activity.

 What do you mean by third-parties?



  When I visit hidden services how can they know what site it is or know
 what site I visit that's not on Tor?

 Why do you think they know?



  How did they know I was using TorMail when it was available and the
 content of the e-mail I sent?

 Who are they?
 --
 tor-talk mailing list - tor-talk@lists.torproject.org
 To unsubscribe or change other settings go to
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk



-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Black Hat USA 2014 will show how to break anonimity in Tor network

[Andrew F]

And?

On Sunday, July 13, 2014, AntiTree antit...@gmail.com wrote:

 Yes, it's been discussed
 https://lists.torproject.org/pipermail/tor-talk/2014-July/033664.html


 On Sun, Jul 13, 2014 at 2:27 PM, ceftrax ceft...@autistici.org
 javascript:; wrote:

  Alexánder Volynkin and Michael McCord will give a presentation about how
  to destroy the anonimity in Tor network in Black Hat USA 2014:
 
 
 
 https://www.blackhat.com/us-14/briefings.html#you-dont-have-to-be-the-nsa-to-break-tor-deanonymizing-users-on-a-budget
 
  Are you notified of this?
 
  --
  Change to GNU/Linux! http://getgnulinux.org
 
 
  --
  tor-talk mailing list - tor-talk@lists.torproject.org javascript:;
  To unsubscribe or change other settings go to
  https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
 
 
 --
 tor-talk mailing list - tor-talk@lists.torproject.org javascript:;
 To unsubscribe or change other settings go to
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] [cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL

[Andrew F]

Would be interesting if someone created an app to test for the problem and
then published which big websites are slow to upgrade.
that would certainly be good for consumers.


On Wed, Apr 9, 2014 at 9:57 AM, Joe Btfsplk joebtfs...@gmx.com wrote:

 On 4/8/2014 5:24 PM, Joe Btfsplk wrote:

 On 4/8/2014 4:25 PM, grarpamp wrote:


 https://blog.torproject.org/ covers what to do for Tor things.

 For everything else on the net, fix the clients and servers you're
 responsible for. Then...

 You're right, there's a big gotcha in all this, users won't really know
 if
 the services they interact with have been fixed [1] because huge swaths
 of services simply don't publish what they do on their pages, they bury
 it to keep quiet and shiny happy sites. Only some banks, insurers,
 utilities,
 schools, etc will post we're fixed anywhere remotely prominent. So
 you have to trust they did [2], which is a reasonable assumption given
 regulation and liability of big institutional services. You should
 already have
 a regular password changing/logout/session management regimen, so
 inserting some extra instances of that along guesstimates of [2] should
 suffice with these classes of service.
 [2] Sometime during the falloff curve starting yesterday afternoon.

 The real user risk is likely on mid to small services, embedded things,
 shared
 platforms, legacy systems, services that didn't get the news, don't have
 the resources or knowledge to fix, etc. Again, consider some form of
 reasonable regimen.

 And there are all sorts of tools and site testing services coming out
 now for which a brave user might be completely warranted in using to
 determine [1 above] so they know when to utilize [regimen 2].
 (Far better to use a testing service or email their help desks seeking
 a positive statement than risk being potentially considered an exploiter
 of things you don't own.)

 Partial list...

 http://s3.jspenguin.org/ssltest.py
 https://gist.github.com/takeshixx/10107280
 https://github.com/FiloSottile/Heartbleed
 https://www.ssllabs.com/ssltest/index.html
 (Note, this is a TLS in process bug, so more than HTTP/S services are
 affected...)

 This bug will no doubt trigger some thinking, analysis and change in
 the services,
 security, infrastructure and user communites... that's a good thing.

 Thanks.  Adding one more heartbleed vulnerability site I tried:
 http://rehmann.co/projects/heartbeat/?domain=

 It seemed to work (though tough to qualify results).  It came back
 showing my bank was *still vulnerable* (not surprising).
 So, made a payment over the phone instead of using their bill pay system
 (this should probably be taken this seriously, but some won't).

 I checked a few other major sites at the rehmann link - it showed them
 as OK.

 *So you have to trust they did...*

 When something like this comes along, you shouldn't ASS-U-ME anything,
 or your ass may regret it. :)
 Hard to imagine any reasonably large financial instit. NOT having a
 prominent banner on all main pages,
 We have (have not) fixed the openSSL issue. Customers can (should not)
 now do online banking. But not a peep.

 UPDATE:  Users should not assume that by now, their bank / other HTTPS
 sites have patched the OpenSSL software.
 Use one of the check sites, to see if a domain / server is still
 vulnerable to heartbleed bug.

 As of late morning, 4/9/14, one of my banks (takes  1 to hold all my $
 :D) still hasn't patched it.

 They have no warning on their site about it  apparently aren't
 restricting user login to access acct info or online bill pay.

 They're not cautioning users to be alert for suspicious activity in their
 acct.

 --
 tor-talk mailing list - tor-talk@lists.torproject.org
 To unsubscribe or change other settings go to
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Receiving money under a protected identity

[Andrew F]

Bitcoin.   Its just a number



On Wed, Feb 12, 2014 at 1:08 PM, 
bm-2ctpedtadjx2bqf6wuux1cper78sq3x...@bitmessage.ch wrote:

 Hello list

 I am currently negociating to publish an article, the first of a few. It
 is about someone with political power in some Easter Europe country. The
 magazine does not want a creative common article as they do not want other
 publications to copy it. Meaning I have to be paid. Now, I know there are
 enough people to have access to the list of payments, people paid bad
 enough to be easily corrupted. I am living abroad. Still, I do not want my
 relatives to suffer because of my articles. Is there a way the magazine
 can make the payment and the people working in Accountancy won't know the
 name of the receiving person?

 Cheers!


 --
 tor-talk mailing list - tor-talk@lists.torproject.org
 To unsubscribe or change other settings go to
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] FYI: TBB Process sandboxing current mozilla development

[Andrew F]

excellent thanks for posting.


On Wed, Jan 29, 2014 at 7:59 AM, Andreas Jonsson andr...@romab.com wrote:


 Hi list,

 The discussionss about sandboxing TBB, and how to this properly for all
 3 major platforms (linux, windows, osx) have been something that we have
 wanted to do for quite a while.

 However, as mozilla is moving to a multi-process model (like chrome),
 sandboxing also becomes a sane alternative for them, and they have the
 same target platforms.

 Without having tested, simply by reviewing what they intended to do, it
 seem like they are well on their way to implement this without hacks
 from me (wrapping ff in a huge sandbox).

 For those interested, this is the bug to track:

 https://bugzilla.mozilla.org/show_bug.cgi?id=925570

 It looks like they are interested in having some of this available
 around FF28.

 BR
 /a
 --
 tor-talk mailing list - tor-talk@lists.torproject.org
 To unsubscribe or change other settings go to
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Thunderbird leak

[Andrew F]

Also you might want to post this on the tails list.



On Sun, Jan 26, 2014 at 5:33 PM, Andrew F andrewfriedman...@gmail.comwrote:

 YIKES... Are you sure, how did this slip by?



 On Sun, Jan 26, 2014 at 3:06 PM, Mike Cardwell t...@lists.grepular.comwrote:

 I just blogged about a general security issue in Thunderbird which may
 also affect people who are using Tor:

 https://grepular.com/Security_Bug_Thunderbird_Websites_Tabs

 Basically, an email can be crafted such that when you click a link in
 that email it is opened within a Thunderbird tab instead of in your
 usual (potentially torified) web browser. Bypassing any other defenses
 you might also have, including NoScript etc.

 --
 Mike Cardwell  https://grepular.com/ http://cardwellit.com/
 OpenPGP Key35BC AF1D 3AA2 1F84 3DC3  B0CF 70A5 F512 0018 461F
 XMPP OTR Key   8924 B06A 7917 AAF3 DBB1  BF1B 295C 3C78 3EF1 46B4

 --
 tor-talk mailing list - tor-talk@lists.torproject.org
 To unsubscribe or change other settings go to
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk



-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Thunderbird leak

[Andrew F]

YIKES... Are you sure, how did this slip by?



On Sun, Jan 26, 2014 at 3:06 PM, Mike Cardwell t...@lists.grepular.comwrote:

 I just blogged about a general security issue in Thunderbird which may
 also affect people who are using Tor:

 https://grepular.com/Security_Bug_Thunderbird_Websites_Tabs

 Basically, an email can be crafted such that when you click a link in
 that email it is opened within a Thunderbird tab instead of in your
 usual (potentially torified) web browser. Bypassing any other defenses
 you might also have, including NoScript etc.

 --
 Mike Cardwell  https://grepular.com/ http://cardwellit.com/
 OpenPGP Key35BC AF1D 3AA2 1F84 3DC3  B0CF 70A5 F512 0018 461F
 XMPP OTR Key   8924 B06A 7917 AAF3 DBB1  BF1B 295C 3C78 3EF1 46B4

 --
 tor-talk mailing list - tor-talk@lists.torproject.org
 To unsubscribe or change other settings go to
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk


-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor-ramdisk 20131230 released

[Andrew F]

Congrats.  It sounds like a fantastic addition to increase security with
Tor severs. .
With that said,  The name is kinda misleading.  As a Ramdisk refers to a
very specific devise or software function.Might want to consider adding
something to the name that implies secure server functionality.

Just my 2 cents.

Congrats again.


On Sun, Jan 5, 2014 at 4:32 PM, Anthony G. Basile bas...@opensource.dyc.edu
 wrote:

 Hi everyone

 I want to announce to the list that a new release of tor-ramdisk is out.
 Tor-ramdisk is a uClibc-based micro Linux distribution whose only purpose
 is to host a Tor server in an environment that maximizes security and
 privacy. Security is enhanced by hardening the kernel and binaries, and
 privacy is enhanced by forcing logging to be off at all levels so that even
 the Tor operator only has access to minimal information. Finally, since
 everything runs in ephemeral memory, no information survives a reboot,
 except for the Tor configuration file and the private RSA key, which may be
 exported/imported by FTP or SCP.


 Changelog:

 This release of tor-ramdisk follows upstream's release of tor-0.2.4.20.
 The kernel was also updated to Linux-3.12.6 plus Gentoo's
 hardened-patches-3.12.4-3.extras, but all other components were kept at
 the same version as the 20131216 release.


 i686:
 Homepage: http://opensource.dyc.edu/tor-ramdisk
 Download: http://opensource.dyc.edu/tor-ramdisk-downloads

 x86_64:
 Homepage: http://opensource.dyc.edu/tor-x86_64-ramdisk
 Download: http://opensource.dyc.edu/tor-x86_64-ramdisk-downloads


 --
 Anthony G. Basile, Ph. D.
 Chair of Information Technology
 D'Youville College
 Buffalo, NY 14201
 (716) 829-8197
 --
 tor-talk mailing list - tor-talk@lists.torproject.org
 To unsubscribe or change other settings go to
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] VOIP and tor

[Andrew F]

Is mumble secure over tor?
Is it the best to use for Voip call on tor?


What are the other options?
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Tor Stymies NSA- great article, Good job Tor developers and review staff!

[Andrew F]

Tor Stymies NSA- great article,  Good job Tor developers and review staff!

http://www.theregister.co.uk/2013/10/04/nsa_using_firefox_flaw_to_snoop_on_tor_users/
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsusbscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] best distro to use Tor

[Andrew F]

BSD is great, but its does not have the same level of hardware support as
Linux.
I would go with Tails or Mint Cinnamon.   Have heard good things about
Whonix, but last time I checked. it was not set up for the casual user.
But I am guessing it will be the set up of choice when it is further along
in development.



On Mon, Oct 7, 2013 at 12:34 AM, Gerardo g3r9...@gmail.com wrote:

 Thank you all for your answers,


 On 06/10/2013 21:11, Luther Blissett wrote:

 But if your question is really which is best for Tor, tor-devs are
 sourcing .deb and .rpm packages, so support is probably better if you
 run debian, rhel or one of its many derivatives.


 Since I'm no to experienced, may be my best option is to stay close to
 where Tor is developed, so, I think I'll go for Debian, which also looks
 solid in terms of community, ethics, etc.

 Cheers,

 --
 tor-talk mailing list - tor-talk@lists.torproject.org
 To unsusbscribe or change other settings go to
 https://lists.torproject.org/**cgi-bin/mailman/listinfo/tor-**talkhttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsusbscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor 0.2.5.1-alpha is out

[Andrew F]

Congratulations to all participants.   It looks fantastic.


On Wed, Oct 2, 2013 at 12:25 PM, Roger Dingledine a...@mit.edu wrote:

 Tor 0.2.5.1-alpha introduces experimental support for syscall sandboxing
 on Linux, allows bridges that offer pluggable transports to report usage
 statistics, fixes many issues to make testing easier, and provides
 a pile of minor features and bugfixes that have been waiting for a
 release of the new branch.

 This is the first alpha release in a new series, so expect there to
 be bugs. Users who would rather test out a more stable branch should
 stay with 0.2.4.x for now.

 I'm going to leave the download pages listing 0.2.3.x and 0.2.4.x,
 so we don't have the confusion of three branches at once. I'm also not
 sure yet how the packaging people plan to handle three branches.

 https://www.torproject.org/dist/

 Changes in version 0.2.5.1-alpha - 2013-10-02
   o Major features (security):
 - Use the seccomp2 syscall filtering facility on Linux to limit
   which system calls Tor can invoke. This is an experimental,
   Linux-only feature to provide defense-in-depth against unknown
   attacks. To try turning it on, set Sandbox 1 in your torrc
   file. Please be ready to report bugs. We hope to add support
   for better sandboxing in the future, including more fine-grained
   filters, better division of responsibility, and support for more
   platforms. This work has been done by Cristian-Matei Toader for
   Google Summer of Code.
 - Re-enable TLS 1.1 and 1.2 when built with OpenSSL 1.0.1e or later.
   Resolves ticket 6055. (OpenSSL before 1.0.1 didn't have TLS 1.1 or
   1.2, and OpenSSL from 1.0.1 through 1.0.1d had bugs that prevented
   renegotiation from working with TLS 1.1 or 1.2, so we had disabled
   them to solve bug 6033.)

   o Major features (other):
 - Add support for passing arguments to managed pluggable transport
   proxies. Implements ticket 3594.
 - Bridges now track GeoIP information and the number of their users
   even when pluggable transports are in use, and report usage
   statistics in their extra-info descriptors. Resolves tickets 4773
   and 5040.
 - Make testing Tor networks bootstrap better: lower directory fetch
   retry schedules and maximum interval without directory requests,
   and raise maximum download tries. Implements ticket 6752.
 - Add make target 'test-network' to run tests on a Chutney network.
   Implements ticket 8530.
 - The ntor handshake is now on-by-default, no matter what the
   directory authorities recommend. Implements ticket 8561.

   o Major bugfixes:
 - Instead of writing destroy cells directly to outgoing connection
   buffers, queue them and intersperse them with other outgoing cells.
   This can prevent a set of resource starvation conditions where too
   many pending destroy cells prevent data cells from actually getting
   delivered. Reported by oftc_must_be_destroyed. Fixes bug 7912;
   bugfix on 0.2.0.1-alpha.
 - If we are unable to save a microdescriptor to the journal, do not
   drop it from memory and then reattempt downloading it. Fixes bug
   9645; bugfix on 0.2.2.6-alpha.
 - The new channel code sometimes lost track of in-progress circuits,
   causing long-running clients to stop building new circuits. The
   fix is to always call circuit_n_chan_done(chan, 0) from
   channel_closed(). Fixes bug 9776; bugfix on 0.2.4.17-rc.

   o Build features:
 - Tor now builds each source file in two modes: a mode that avoids
   exposing identifiers needlessly, and another mode that exposes
   more identifiers for testing. This lets the compiler do better at
   optimizing the production code, while enabling us to take more
   radical measures to let the unit tests test things.
 - The production builds no longer include functions used only in
   the unit tests; all functions exposed from a module only for
   unit-testing are now static in production builds.
 - Add an --enable-coverage configuration option to make the unit
   tests (and a new src/or/tor-cov target) to build with gcov test
   coverage support.

   o Testing:
 - We now have rudimentary function mocking support that our unit
   tests can use to test functions in isolation. Function mocking
   lets the tests temporarily replace a function's dependencies with
   stub functions, so that the tests can check the function without
   invoking the other functions it calls.
 - Add more unit tests for the circid,channel-circuit map, and
   the destroy-cell-tracking code to fix bug 7912.
 - Unit tests for failing cases of the TAP onion handshake.
 - More unit tests for address-manipulation functions.

   o Minor features (protecting client timestamps):
 - Clients no longer send timestamps in their NETINFO cells. These were
   not 

[tor-talk] NSA paid French hackers to develop software exploits, windows, chrome etc

[Andrew F]

FYI
http://www.thedailysheeple.com/contract-reveals-nsa-paid-french-hacking-company-unknown-sum-in-2012-to-develop-software-exploits_092013

Happy hump day.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsusbscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor browser can be fingerprinted

[Andrew F]

The graphics subsystem,  are being used today.
100%.  No doubt.  If your targeted, this may be used to find you.  It takes
a lot resources but its happing right now.   Opening one domain at a time
helps, but the longer your connected and the more you down load more
identifiable you are.

If your not targeted, you have nothing to worry about.



On Wed, Sep 11, 2013 at 4:43 PM, Roger Dingledine a...@mit.edu wrote:

 On Wed, Sep 11, 2013 at 12:50:41PM -0400, Marthin Miller wrote:
  1024bit RSA keys which can be cracked in a few hours

 I believe this to be false currently.

 (But that doesn't mean we shouldn't fix it, because it will become true
 some time in the next few decades, and we don't know when that will be.
 (Good thing we're fixing it.))

  Also if you let users choose how much security they want that's better
 (for example choose high padding and time delay on relays if security
 have more priority than speed)

 Unfortunately, this one is more complex than you imply as well. Take a
 look at Anonymity Loves Company: Usability and the Network Effect
 for much more discussion here:
 http://freehaven.net/anonbib/#usability:weis2006

 --Roger

 --
 tor-talk mailing list - tor-talk@lists.torproject.org
 To unsusbscribe or change other settings go to
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsusbscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor users are not anonymous

[Andrew F]

From http://translate.google.com/

On the basis of patterns can be easily identified despite Tor users
anonymity than expected. The have Aaron Johnson , Chris Wacek , Micah Sherr
and Paul Syverson studied in a scientific study . The authors have
investigated here the data that go into the Tor network and compared with
those who come out . Especially users of BitTorrent or IRC via gate can be
exposed quickly . The problems , however, are known and Tor team has
adequately in their FAQs out .

Provided that both the attacker can also monitor the incoming and outgoing
traffic of at least one or more gateway relays the data can be analyzed and
assigned on the basis of comparative patterns of a given IP address . It
was only a matter of time , write the authors of the study, at least six
months , a user with up to 80 - percent probability 'll identify . For
example, since few users abriefen BitTorrent over Tor and a few relays
opened the ports for BitTorrent , they also stayed open long , so
decreasing the duration of a clearly de-anonymization .
Quickly identified by larger attack surface

The deanonymisation will accelerate when either the attacker complete
control over a portion of the traffic would , for example through an
autonomous system (AS ), or even an Internet Exchange Point ( IXP ) . Then
the period of identification partly reducing by half. A scenario that
classify the scientists in the context of the current discussion of the
work of the intelligence services to be realistic.

Additional tools that speed up the traffic on Tor network , increase the
risk deanonymization also , such as Congestion -Aware Path Selection ,
identified in the bottle necks and data can be redirected accordingly. The
higher the number of guards used by users , the higher the probability to
catch a guard, which is overseen by an attacker .
countermeasures

The four authors of the study but also give hints on how the
de-anonymization may be at least delayed , for example by the number of
entry guards would be reduced . An increase in the decay time of a Guards
could prolong the time until a user is identified. The study indicates that
the Tor team this measure have been used in version 0.2.4.12 -alpha. In
addition, users could manually reduce the number of entry , exit and
exclude nodes. This would indeed sent at the expense of speed more packets
of different clients by individual nodes , but they are less likely to be
assigned .

Although the results of their study are very pessimistic, the authors write
. But yet Gate means confidentiality over the Internet for thousands of
users . They were optimistic that the Tor team could offer the service and
continue to improve .


On Thu, Sep 5, 2013 at 10:22 PM, sigi torn...@cpunk.de wrote:

 Hi,

 two main german technology news sites are spreading news about the
 study: »Users Get Routed: Traffic Correlation on Tor by Realistic
 Adversaries« [1]

 They write about 'broken anonymity' for Tor-users:
 Tor-Nutzer surfen nicht anonym - Tor users do not surf anonymously
 
 http://www.golem.de/news/anonymisierung-tor-nutzer-surfen-nicht-anonym-1309-101417.html
 

 Tor-Benutzer leicht zu enttarnen - Tor users to easily expose
 
 http://www.heise.de/security/meldung/Tor-Benutzer-leicht-zu-enttarnen-1949449.html
 

 The articles are german-only - The main point was always stated by the
 Tor-devs [2], that anonymity »fails when the attacker can see both ends
 of the communications channel« - can anyone out there assess how
 serious or new this really is?

 Regards,
 sigi

 [1] http://www.ohmygodel.com/publications/usersrouted-ccs13.pdf
 [2] https://www.torproject.org/docs/faq.html.en#EntryGuards
 --
 tor-talk mailing list - tor-talk@lists.torproject.org
 To unsusbscribe or change other settings go to
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsusbscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Contents of PirateBrowser 0.6b

[Andrew F]

Are these guys sponsoring any Servers?   Kinda rude if they are not.


On Sat, Aug 31, 2013 at 8:42 PM, Roger Dingledine a...@mit.edu wrote:

 On Sat, Aug 31, 2013 at 12:35:19AM -0400, krishna e bera wrote:
  On 13-08-31 12:25 AM, Roger Dingledine wrote:
   On Fri, Aug 30, 2013 at 04:29:18PM +, Matt Pagan wrote:
   # Configured for speed
  
   Just for the record, the three lines here don't help speed much (or
   maybe at all).
  
   ExcludeSingleHopRelays 0
  
   This first line says it's ok to use relays that allow you to make
 one-hop
   circuits. Roughly speaking, there aren't any relays like that in the
   network (it's not the default). And even if there were, it wouldn't
 make
   the circuits your client builds any speedier (except I guess through
   a second-order effect where you're willing to use relays that all the
   other clients are unwilling to use).
 
  Perhaps they meant latency?
  That could affect the response time and perceived speed of page
  rendering more than the total byte throughput.

 To be clear: you will still use 3-hop circuits when you set
 ExcludeSingleHopRelays to 0.

 --Roger

 --
 tor-talk mailing list - tor-talk@lists.torproject.org
 To unsusbscribe or change other settings go to
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsusbscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Contents of PirateBrowser 0.6b

[Andrew F]

I hope they are supporting servers on the network..
have they talked about that?



On Fri, Aug 30, 2013 at 11:53 AM, Matt Pagan m...@pagan.io wrote:

 On Fri, 30 Aug 2013 16:29:18 +
 Matt Pagan m...@pagan.io wrote:

  The Pirate Browser is based off Firefox 23.0
  
  Extensions:
FoxyProxy Standard 4.2.2
 
  Plugins:
Google Update 1.3.21.153
Microsoft(R) DRM 9.0.0.4503
Microsoft(R) DRM 9.0.0.4503
Windows Media Player Plug-in Dynamic Link Library
 

 Note here the exclusion of HTTPS-Everywhere, NoScript, Torbutton, etc.
 --
 tor-talk mailing list - tor-talk@lists.torproject.org
 To unsusbscribe or change other settings go to
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsusbscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Is Tor still valid?

[Andrew F]

 On 08/05/2013 06:53 PM, Crypto wrote:

On 8/5/2013 1:29 PM, Andrew F wrote:

 Is Tor still Valid now that we know the nsa is actively exploiting holes in
technology anonymity tools?  We know that Tor and hidden services has
issues, not to mention the whole fingerprinting problems.

Is Tor too vulnerable to trust?Watch the video below.

XKeyscorehttp://www.youtube.com/watch?v=TSEbshxgUas

 I'm curious as to why everyone is so intent on blaming Tor itself? Tor
was not exploited. It was a hole in FF 17 in conjunction with the
application running behind the hidden service. It's like saying My car
got a flat tire! Should I ever drive again? I agree that the exploit
was a bad one and in turn it's a big security issue. But if we're going
to point fingers let's not point at Tor. Let's focus on the underlying
issue(s) that caused this to happen. FF 17 was the target, not Tor.
Mozilla has addressed the issue. How did the exploit occur? Let's look
at the application(s) that were running behind the hidden service.


 That was not my focus. My concern is for known Tor venerabilities that are
documented and know by all.
If we know that Government agencies are actively and successfully attacking
soft technology targets. then how can we assume the know Tor Venerabilities
are not being used at this very moment.   The Tor Venerabilities are going
to be dealt with one day.. but what about right now.  We know about them,
therefore everyone knows about them.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsusbscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Is Tor still valid?

[Andrew F]

This is one of the reasons I only use tails.  As tails is a live cd every
time you boot up you get a fresh system.  So any viruses are wiped away.
Of course they have already done there work in the last session.   But with
windows.. every time you fire up Tor, they could be watching with this
exploit.  At least with tails you gotta make them work for it and install
fresh every time.


On Tue, Aug 6, 2013 at 5:00 AM, Andrew F andrewfriedman...@gmail.comwrote:

  On 08/05/2013 06:53 PM, Crypto wrote:

 On 8/5/2013 1:29 PM, Andrew F wrote:

  Is Tor still Valid now that we know the nsa is actively exploiting holes in
 technology anonymity tools?  We know that Tor and hidden services has
 issues, not to mention the whole fingerprinting problems.

 Is Tor too vulnerable to trust?Watch the video below.

 XKeyscorehttp://www.youtube.com/watch?v=TSEbshxgUas

  I'm curious as to why everyone is so intent on blaming Tor itself? Tor
 was not exploited. It was a hole in FF 17 in conjunction with the
 application running behind the hidden service. It's like saying My car
 got a flat tire! Should I ever drive again? I agree that the exploit
 was a bad one and in turn it's a big security issue. But if we're going
 to point fingers let's not point at Tor. Let's focus on the underlying
 issue(s) that caused this to happen. FF 17 was the target, not Tor.
 Mozilla has addressed the issue. How did the exploit occur? Let's look
 at the application(s) that were running behind the hidden service.


  That was not my focus. My concern is for known Tor venerabilities that
 are documented and know by all.
 If we know that Government agencies are actively and successfully
 attacking soft technology targets. then how can we assume the know Tor
 Venerabilities are not being used at this very moment.   The Tor
 Venerabilities are going to be dealt with one day.. but what about right
 now.  We know about them, therefore everyone knows about them.

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsusbscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Is Tor still valid?

[Andrew F]

Is Tor still Valid now that we know the nsa is actively exploiting holes in
technology anonymity tools?  We know that Tor and hidden services has
issues, not to mention the whole fingerprinting problems.

Is Tor too vulnerable to trust?Watch the video below.

XKeyscore
http://www.youtube.com/watch?v=TSEbshxgUas
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsusbscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Successful experiment boosting the number of users using OpenPGP verification for file download

[Andrew F]

Quite impressive Adrelanos.  I used to run these types of studies when
developing interfaces years ago.
Well done and thank you for sharing.





On Wed, Jul 31, 2013 at 5:30 PM, adrelanos adrela...@riseup.net wrote:

 Hi!

 I hope you are interested in the results of a little experiment.

 Q: How many users downloaded OpenPGP signatures with the old design of
 download page? (You can see the design here: [1] [2])

 A: 1 in ~30 users.

 Q: How many users downloaded OpenPGP signatures after adding a colored
 download table, which indicates, that http downloads without OpenPGP
 verification is the least secure method, to the download page? (You can
 see the design here: [3])

 A: 1 in ~11 users.

 Note: This is only an approximation. No experiment meeting scientific
 standards. However, while the number of downloads didn't decrease, the
 number of signature downloads significantly increased. Which is a good
 thing, isn't it? Downloading a signature doesn't imply, the user
 successfully managed to use OpenPGP verification or that the user
 couldn't be tricked or just ignored an invalid signature error message.

 You can get some more information and more detailed statistics here: [5]
 [6]

 This is also a follow up to: [liberationtech] secure download tool -
 doesn't exist?!? [4]

 Cheers,
 adrelanos

 Footnotes:

 [1] http://www.webcitation.org/6IWk5h4E9
 [2] Please ignore the Moved to https://www.whonix.org; part. That
 snapshot has been forgotten and made later. Nevertheless it gives an
 impression how the old download page looked like.)
 [3] http://www.webcitation.org/6IWk5h4E9
 [4]
 https://mailman.stanford.edu/pipermail/liberationtech/2013-July/009625.html
 [5] https://whonix.org/wiki/Dev/Download_Statistics
 [6] http://www.webcitation.org/6IWlyqokZ
 --
 tor-talk mailing list - tor-talk@lists.torproject.org
 To unsusbscribe or change other settings go to
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsusbscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Using Mumble with Tor

[Andrew F]

I thought Mumble data packets were encrypted to the server and back out to
the other participants.
If so, they would have to decrypt the packets first to get your voice for
matching.

Are the mumble data packets not encrypted?

Unless you are referring to somone logging in
to a chat room and recording the voices from there?




On Thu, Jul 18, 2013 at 4:52 AM, David Huerta huerta...@opentil.com wrote:

 On Sun, Jul 14, 2013 at 10:58 PM, adrelanos adrela...@riseup.net wrote:

  David Huerta:
   Hey all,
  
   I've put together a guide on how to use Mumble (TCP only!) with Tor if
   anyone would find that sort of thing handy:
  
 
 http://huertanix.tumblr.com/post/55261352264/location-anonymous-voice-communication-a-step-by-step
  .
 
  Thanks for doing that. Seems you're good at writing tutorials. Maybe we
  can share/remix? Under which license is your tutorial?
 
 
 Just added a CC-BY 3.0 badge to the post, feel free to
 remix/share/sell/etc.


  Some time ago I wrote about anonymous Voip as well, although its a bit
  Whonix specific, since the confidence of not leaking anything comes from
  the Whonix design. Many other points are portable though, it also
  includes using Voip clients/ZRTP.
 
  I recommended using a hidden service as mumble server.
 
  https://whonix.org/wiki/Voip
 
 
 A mumble server as a hidden instance is something I thought about but I
 couldn't figure out where to start at the time. Glad there's some
 documentation on it though, I'll take a look! A few friends of mine have
 been experimenting with mumble over tor a lot so we'd definitely be
 interested in spending some time trying out a Whonix mumble hidden service
 setup.


   * Assuming it can be detected after being filtered/optimized to a pulp,
   the hum of the mains frequency of the electrical grid might tip off
   which country you're in based in.
 
  Yes, and a voice recording of yours leads straight to you (voice
  recognition)? I assume the voice of every person has made a
  non-anonymous call and been sampled at least once (PRISM), probable a
  sane assumption. Comparing that with a voice sample from the anonymous
  server, and its no longer anonymous.
 
  In conclusion, I think the only safe use cases for Voip or Tor are
  location hiding while not being anonymous; hiding who is talking to
  whom; and talking to people you trust while hiding that you are talking
  to them and your locations from outside observers.
 

 That's roughly what I meant by location-anonymity, but I realize I never
 really explained the term in my post; I've added an addendum to the post
 which explains that and lists potential issues mentioned here and in the
 HeatSync Labs mailing list.

 --
 david [.dh] huerta
 davidhuerta.me

 -BEGIN PGP PUBLIC KEY BLOCK-
 Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
 Comment: GPGTools - http://gpgtools.org

 mQENBFDlBaMBCADDRmcSL+YpVzawcjwCtm61lQT32VILEPE3o9mZMAfKlYiEtfJY
 8r4ggOCdWRoqglPUGOoTSANsQfahxxmyLylFz1D9iNerx9/23iQ8hcFcokoOAdwA
 fhmNHEdkgyQg9Lyy5KcfGsrzJyxd7SBwMOvbRGudWpuA0+Dp84sQXTxHawp/LUVU
 G+zCrrc39jeyHWVLdNESxXCW7nOSRe/jU92/PiMTS0VAYZuHE9j93bH37JjLvXZx
 MgozTZImBxB9SmvT8ztuU1BS9jdmtO9/XD/XjWdvdbWS7z6fjambB8zWWAOkQvz/
 TbCeaIVqYEaQspDaAs4jhdzfpRYRUAfk20cpABEBAAG0IkRhdmlkIEh1ZXJ0YSA8
 aHVlcnRhbml4QGdtYWlsLmNvbT6JAT8EEwECACkFAlD9jbgCGyMFCQlmAYAHCwkI
 BwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRA11ya9rgnzKGv1CACBZzhAEGpA5IAB
 k58CbcDJ4hXg8OSoay24SNi7jdCemp0CEbr1EhHGw3s05sUExl/KRgeQxgazvXtk
 +Y0ynyguA39U+nu/kkRVhB7vNPXj2GKdcsO9cw92KmCcRhKZiYL3OEAiGXYa/kvl
 6YqXxzbw7oshcceDmSAKctsiBHhS/zwpdb4Co1v260H8HXAf+tsDPbkZHVRSNX/V
 PyhxQFtnFvdEiLE6D6hsMXJWAvNBoeaGb/xaQnU9Elu0JqY+n2372oc2F9ZYsg/D
 WcwcKb5SkucyXnlph8AXTx3SCTISVVN95Pj8anv2Z1XwKV0iM+K3dp/v0bWsIvRq
 07ZFT/hKtCREYXZpZCBIdWVydGEgPGh1ZXJ0YW5peEBvcGVudGlsLmNvbT6JAUIE
 EwECACwCGyMFCQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAUCUP2N2gIZ
 AQAKCRA11ya9rgnzKBPcB/4ltGkLGpzhH+4OxI+zRk7qRnF3sFLYJUh/VUSSDU8l
 Bu8eEYPol1DJ/MGIKqZytvLC6kvevHBRGT3YpEWJ3q97Iqvzpg52RftN8IZpN8dQ
 6L8Tr1DLCcIl+F3J0rHBxrU54pXBlPpeo2Yppv2nGo+plFwKkg711A4ZJIUSaG6V
 hmslIovxoUxo4F0QyRNZ9dPqCzzTP63xJCgh0Ez+WVT8gaan1iE4Ck4xlEH6vMZB
 8tVjXx0tCYPyNRwl0DDXkIfX+9s92stIQVDt4srNKcu6yjjQs7f+0UiULotZ3fKX
 skykx4wBk59BT92VQwBM/tFxgf+p0BLcbasFhCpfTNepiQE/BBMBAgApBQJQ5QWj
 AhsjBQkJZgGABwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQNdcmva4J8yj6
 /gf/f4lSeMMK3yHLxcRQ7vqHJ+TrWCh62AxTHbbabnozGaug42ekZUJWqf+O97DT
 TpKRhknaTleXWontnotIdHcv/ciFM85SSlO2+k3jouxnyPEIP45wgabAAG55zUZ4
 lUGH9z4OZo0j/OuxfTj/EWc1AciuJAONd5Cz6wFpbPMQ4811cB7IrDKPd5pTOe7M
 B+Y3SpWo95i0DWWeoa3MfXoBUjTjF8c79ZRel+M/9Qxqi9GkD+NWrJbSh1G9Rrkf
 4FXFDO2tYadsnXV8+PnR0hoHXHoXSpWQzmbNhYa/OZOhPdgqAuOKTgAoT8rR9ELq
 vSHsuacDQOli8WqWd/IR4Szi8rkBDQRQ5QWjAQgA0oAIKM8AFYqHIrQocHmTGR/j
 YybKQ41u+RUkrhzQPGm9lNSIR7MdD+DEwyEPeZLezNzuUk/huA2eZrjI7P/6aire
 0CtUePzkrY93/OuDS5Tb9FtduyclCFMVm+OlOkMjBiqUofQsei4mB6FLKKtKRdiH
 0jng3UUkTbJY7iAlKannKBWtsuDCTQuguLh1+Z9bQmINiKSefYgYGJgCklhvYahc
 kX/NKnisepYOwiCldwvbGs6ify962qG14xPf1y/Q4dSCxgSjzLdXDxpp90XEZNiT
 

Re: [tor-talk] Ninja Stik?

[Andrew F]

Jacob,
What are the issues with Hardware cypto?
Have you addressed this in a talk?  If so would
pass on a link?  Youtube I assume?
Thanks


On Thu, Jul 18, 2013 at 4:55 AM, Jacob Appelbaum ja...@appelbaum.netwrote:

 Andrew Lewman:
  Anyone used one of these ninja stik usb drives?
 
  http://www.ninjastik.com
 
  It seems to be stock ubuntu with tor installed.  People keep coming
  to me asking how come we called it ninja stik and why we used ubuntu
  when we have tails.
 
  The first question is why people think we produce it at all.
 

 I tend to prefer tails on a TrekStor disk - it has a write protect
 switch which seems to actually do something useful. With tails, LUKS
 does the job of crypto without the concerns that hardware crypto raises
 for me...

 That said - wow, what a website - and also, yeah, wow, why not Tails? :(

 All the best,
 Jacob
 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Ninja Stik?

[Andrew F]

Amazing..
Thanks
Eugen
Jacob



On Thu, Jul 18, 2013 at 1:29 PM, Jacob Appelbaum ja...@appelbaum.netwrote:

 Andrew F:
  Jacob,
  What are the issues with Hardware cypto?
  Have you addressed this in a talk?  If so would
  pass on a link?  Youtube I assume?
  Thanks

 Hardware crypto is difficult to verify on a number of different levels.
 I don't even trust these write protected switches but at least those can
 be verified to a degree that is reasonably comfortable...

 All the best,
 Jacob
 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Hidden Service Scaling --- How bad is it?

[Andrew F]

I read on the tor blog that Hidden services do not scale well and there are
several potential attack vectors on hidden services.  Also, they are very
slow.How slow are we talking?

thanks
Andrew
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Ninja Stik?

[Andrew F]

Andrew,

The real question is about flash.  They say that flash sites, including
youtube and other tube sites work.
Do you no of a way to use flash safely with tor and Ubuntu?
I don't.




On Wed, Jul 17, 2013 at 3:07 AM, Andrew Lewman and...@torproject.is wrote:

 Anyone used one of these ninja stik usb drives?

 http://www.ninjastik.com

 It seems to be stock ubuntu with tor installed.  People keep coming
 to me asking how come we called it ninja stik and why we used ubuntu
 when we have tails.

 The first question is why people think we produce it at all.

 --
 Andrew
 http://tpo.is/contact
 pgp 0x6B4D6475
 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] [Question] How to use chutney to test private network for TOR

[Andrew F]

what is chutney


On Fri, Jul 12, 2013 at 9:28 AM, LEE zeusy...@gmail.com wrote:

 I received tip that I can use chutney to test private network for TOR

 But I don't now how to use chutney

 I already read readme.txt but that doesn't enough for me

 I hope to get detailed usage for chutney
 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] ISP surveillance through Tor?

[Andrew F]

Seth,
Fantastic graphic.  Thanks for posting.


On Thu, Jul 11, 2013 at 3:43 PM, Seth David Schoen sch...@eff.org wrote:

 Marcos Eugenio Kehl writes:

  2. What informations my ISP manager sees when I connect Tor Browser?
 Something like Https Tor Network? Could my ISP catch or sniff some
 download from the first node to my pc, or the download is encrypted?
 
  Regards from Brasil!

 Bom dia,

 We prepared a graphic last year ago to try to help people visualize
 which data is concealed by the use of Tor.

 https://www.eff.org/pages/tor-and-https

 This graphic lets you click to turn Tor and HTTPS on and off.  (Here,
 HTTPS means that your browser is using an HTTPS connection to the
 particular web site that you're communicating with.)  The kinds of
 data that different entities along the way see or don't see is
 displayed.

 There are some surveillance possibilities that the graphic doesn't
 directly address, for example that the timing or amount of data
 you send might allow one of the eavesdroppers to confirm a hypothesis
 or guess about you or what you're accessing.  Instead, the graphic shows
 what each entity directly learns from its own eavesdropping or data
 requests, not what they might be able to figure out with further
 analysis.

 --
 Seth Schoen  sch...@eff.org
 Senior Staff Technologist   https://www.eff.org/
 Electronic Frontier Foundation  https://www.eff.org/join
 815 Eddy Street, San Francisco, CA  94109   +1 415 436 9333 x107
 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] safety of exit nodes

[Andrew F]

How about we eliminate the issue by pushing a campaign for every website to
offer an ssl option.  It really should be the standard.

Anyone a marketing Guru or PR specialist?


On Tue, Jul 2, 2013 at 3:47 AM, Jimmy Chen m...@jimmychen.com wrote:

 I never said properly and ethically certified, did I.
 On Jul 1, 2013 8:25 PM, adrelanos adrela...@riseup.net wrote:

  What happens if JonDo certified mixes do things forbidden by
 certification?
 
  Jimmy Chen:
   If you want your exit nodes to be certified, it's probably best at this
   time, to use JAP instead of TOR.
 
  Or combine both, tunnel JonDo through Tor (user - Tor - JonDo). (Not
  saying it's necessarily a good idea.)
  ___
  tor-talk mailing list
  tor-talk@lists.torproject.org
  https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
 
 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Identify requests made by the same user

[Andrew F]

krishna,
Tor minimizes the variables that can Identify you via fingerprinting
techniques, but
a dedicated team can still track you with enough effort.  I know form
personal experience


On Thu, Jun 20, 2013 at 9:19 PM, krishna e bera k...@cyblings.on.ca wrote:

 On 13-06-20 03:38 PM, NoWhereMan wrote:
  Hello all,
 
  i've ran trough your docs, without finding a complete answer. If my
  question is covered by a FAQ or something like that, please don't
  hesitate to RTFM me :)

 Some of your question is answered here:

 https://trac.torproject.org/projects/tor/wiki/doc/TorFAQ#SoImtotallyanonymousifIuseTor

 
  The point: does a tor client have a kind of unique ID in the
  network? I mean, let's put 2 users create 2 hidden services,
  completely unrelated between them, under 2 different .onion domains.
  Then, I set up my tor client and use both hidden services. Is someway
  possible to know that those 2 requests have been made by me (by my tor
  client, as my IP and identity is completely hidden)?
 
  Hope you understand what I mean. A practical example would be:
 
  I go to the aaa.onion forum and describe my plan to kill Obama. I'm
  completely anonymous. Then, from the same Tor client, I open
  bbb.onion, and comment on a post giving my home address. If the client
  had an unique id, it would be possible to associate those 2 actions.
  You don't know what is the IP address of that client, or where is it,
  but you actually know that the post on aaa.onion and comment on
  bbb.onion have been written by the same person (actually, from the
  same client).

 1) By design, you cannot know whether aaa.onion and bbb.onion are
 running on the same machine or are run by the same operator.

 2) If either .onion site requires registration, you must be careful to
 use different email userid and password on each, and those must also be
 different from anything you use in non-Tor contexts.

 3) If you check the tests at
 http://ip-check.info/?lang=en
 you will see how much browser fingerprinting is possible.  So you
 must be careful not to change any settings that will make your browsing
 session look different from any other person using TBB.
 TBB is designed to make all its users have the same browser fingerprint,
 i.e. no unique id.




 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk


___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor 0.2.4.13-alpha is out

[Andrew F]

Congratulations to all the contributers and project managers.
Thanks for all the hard work you have put in on this up date


Andrew


On Sun, Jun 16, 2013 at 10:18 PM, Mike Perry mikepe...@torproject.orgwrote:

 Roger Dingledine:
  Tor 0.2.4.13-alpha fixes a variety of potential remote crash
  vulnerabilities, makes socks5 username/password circuit isolation
  actually actually work (this time for sure!), and cleans up a bunch
  of other issues in preparation for a release candidate.
 
  https://www.torproject.org/dist/

 As a heads up, a bug was introduced in this release that allows
 malicious websites to discover a client's Guard nodes in a very short
 amount of time (on the order an hour), if those Guard nodes upgrade to
 this release.

 Unfortunately, the bug was introduced by fixing another issue that
 allows Guard nodes to be selectively DoSed with an OOM condition, so
 Guard node (and Guard+Exit node) operators are kind of in a jam.

 I think the best course of action is to suggest that nodes with the
 Guard flag *not* upgrade to this release, unless they are experiencing
 unexplained OOMing?

 If we can't find a solution that rigorously fixes both issues, I think
 that future releases should have the OOM DoS fix off by default but
 available through a torrc option.

 See also:
 https://trac.torproject.org/projects/tor/ticket/9072


  Changes in version 0.2.4.13-alpha - 2013-06-14
o Major bugfixes (robustness):
  - Close any circuit that has too many cells queued on it. Fixes
bug 9063; bugfix on the 54th commit of Tor. This bug is a further
fix beyond bug 6252, whose fix was merged into 0.2.3.21-rc.
  - Prevent the get_freelists() function from running off the end of
the list of freelists if it somehow gets an unrecognized
allocation. Fixes bug 8844; bugfix on 0.2.0.16-alpha. Reported by
eugenis.
  - Avoid an assertion failure on OpenBSD (and perhaps other BSDs)
when an exit connection with optimistic data succeeds immediately
rather than returning EINPROGRESS. Fixes bug 9017; bugfix on
0.2.3.1-alpha.
  - Fix a directory authority crash bug when building a consensus
using an older consensus as its basis. Fixes bug 8833. Bugfix
on 0.2.4.12-alpha.
 
o Major bugfixes:
  - Avoid a memory leak where we would leak a consensus body when we
find that a consensus which we couldn't previously verify due to
missing certificates is now verifiable. Fixes bug 8719; bugfix
on 0.2.0.10-alpha.
  - We used to always request authority certificates by identity
 digest,
meaning we'd get the newest one even when we wanted one with a
different signing key. Then we would complain about being given
a certificate we already had, and never get the one we really
wanted. Now we use the fp-sk/ resource as well as the fp/
resource to request the one we want. Fixes bug 5595; bugfix on
0.2.0.8-alpha.
  - Follow the socks5 protocol when offering username/password
authentication. The fix for bug 8117 exposed this bug, and it
turns out real-world applications like Pidgin do care. Bugfix on
0.2.3.2-alpha; fixes bug 8879.
  - Prevent failures on Windows Vista and later when rebuilding the
microdescriptor cache. Diagnosed by Robert Ransom. Fixes bug 8822;
bugfix on 0.2.4.12-alpha.
 
o Minor bugfixes:
  - Fix an impossible buffer overrun in the AES unit tests. Fixes
bug 8845; bugfix on 0.2.0.7-alpha. Found by eugenis.
  - If for some reason we fail to write a microdescriptor while
rebuilding the cache, do not let the annotations from that
microdescriptor linger in the cache file, and do not let the
microdescriptor stay recorded as present in its old location.
Fixes bug 9047; bugfix on 0.2.2.6-alpha.
  - Fix a memory leak that would occur whenever a configuration
option changed. Fixes bug 8718; bugfix on 0.2.3.3-alpha.
  - Paste the description for PathBias parameters from the man
page into or.h, so the code documents them too. Fixes bug 7982;
bugfix on 0.2.3.17-beta and 0.2.4.8-alpha.
  - Relays now treat a changed IPv6 ORPort as sufficient reason to
publish an updated descriptor. Fixes bug 6026; bugfix on
0.2.4.1-alpha.
   - When launching a resolve request on behalf of an AF_UNIX control
 socket, omit the address field of the new entry connection, used
 in
 subsequent controller events, rather than letting tor_dup_addr()
 set it to unknown address type. Fixes bug 8639; bugfix on
 0.2.4.12-alpha.
 
o Minor bugfixes (log messages):
  - Fix a scaling issue in the path bias accounting code that
resulted in Bug: log messages from either
pathbias_scale_close_rates() or pathbias_count_build_success().
This represents a bugfix on a previous 

Re: [tor-talk] Running a Tor exit node on a VPS: does location of node matter?

[Andrew F]

There should be an FAQ for this.   This question comes up often.
I would do it, but I don't have the information.


On Wed, Jun 5, 2013 at 4:47 PM, Sean Alexandre s...@alexan.org wrote:

 On Wed, Jun 05, 2013 at 04:02:19PM +0100, Bernard Tyers - ei8fdb wrote:
  I am researching running a Tor exit node on a hosted VPS. I am currently
 looking at a big list of VPSs (www.lowendbox.com - thanks Moritz).
 
  Most are similar - bandwidth, RAM, disk, IPs, etc.
 
  For me as the operator of the node, does the location of the node, or
 more importantly the location of the datacentre/s where the VPS will live
 have any impact?
 
  As a European country citizen does it make sense to locate the node in
 the US/Canada/Asia/Europe?

 Here are some useful useful links on running a Tor exit node...

 The Legal FAQ for Tor Relay Operators
 https://www.torproject.org/eff/tor-legal-faq.html.en

 Tips for Running an Exit Node with Minimal Harassment
 https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment

 GoodBadISPs
 https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs

 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] The Google Browser, Sand boxing and Tor.

[Andrew F]

Thanks for the correction.


On Thu, May 23, 2013 at 5:32 PM, Seth David Schoen sch...@eff.org wrote:

 Andrew F writes:

  I does appear that chrome is a free software but not open source. They
  call it proprietary but free software. Is the licensing the issue?
  Apparently they locked down the code with there terms of service.

 Free software and open source software are intended to refer to the
 _same software_.

 Chrome is proprietary (non-open source) software, complete with a
 proprietary EULA.  There is also a free and open source software
 version called Chromium.

 --
 Seth Schoen  sch...@eff.org
 Senior Staff Technologist   https://www.eff.org/
 Electronic Frontier Foundation  https://www.eff.org/join
 815 Eddy Street, San Francisco, CA  94109   +1 415 436 9333 x107
 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] The Google Browser, Sand boxing and Tor.

[Andrew F]

After doing some research and Mike from Tor pointing me in the right
direction,
It appears there are several key issues with Google Chrome that allow for
Leaks.

This would require big adjustments by Google to correct the situation.   At
this point, it does not appear Google will participate.

An arguably better option would be to work with Mozilla to create a
Sandboxed feature.  This could be used for many thing, not just flash.

As I have not heard of any talk much less planning for such a feature, I
would say this topic is dead.




On Thu, May 23, 2013 at 8:31 PM, Nathan Suchy 
theusernameiwantista...@gmail.com wrote:

 You can just use Chromium it is open source and it works great. The
 downside is using Chromium would require the Tor Project to change its
 development procedures. Chromium is designed to be a personalized browser
 while Firefox focuses on making a usable and secure, and decently fast web
 browser. I don't want the Tor Project to switch the Chromium as it would be
 a huge waste of time.


 On Thu, May 23, 2013 at 3:49 PM, Gregory Disney gregory.dis...@owasp.org
 wrote:

  -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well either way V8 json is
  open-source and thats what this question related too. -BEGIN PGP
  SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux)
  iQEcBAEBAgAGBQJRnnKsAAoJEHJ6fv5JwWqhxfcH/RKdvlMgHLWnVdJL4aF/AhOu
  kxn+AP7h/eMqg4DrjamsPUUTEPJnTHvZNosOeBJiCiydtzQgp7KO3zf4ZOojjNUO
  76yts39XSYRJCxzOeLrQQTWoFResFRnLgpAgUKskQnA9kisL6bc3DvuNUpdkeCBX
  5ST0Y/6K9phHARpgJrtq8Um/WVqkCECl60qsUMJs+5wiJk9y9XwxPQfFtIqUG5hX
  00OcncP/bI1udJf60ljC+OGBanKEFfFmXnAsMBzGnpx5xAxOk6O0sn4s3qRFL1/H
  kwjtmVQz980wWNzPMPS9mI6wy5eMhkbVlUEJaI7mPxyNMxWCUn41mbIdVx4ZeSE= =oECN
  -END PGP SIGNATURE-
 
 
  On Thu, May 23, 2013 at 2:55 PM, Zece Anonimescu z...@riseup.net
 wrote:
 
   Seth David Schoen:
Free software and open source software are intended to refer to the
_same software_.
  
   Of course not.
  
   Free software is about helping people be free. It has to do with
   freedom. Open source is just one of the requirements.
  
   Open source movement is about corporate PR.
  
   The confusion comes when people are happy with freeware or one of the
   apps with available source and think free software is about the same.
   ___
   tor-talk mailing list
   tor-talk@lists.torproject.org
   https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
  
  ___
  tor-talk mailing list
  tor-talk@lists.torproject.org
  https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
 
 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] HTML5 video and Tor anonymity.

[Andrew F]

True,
But if you use tor, and you go to news sites, youtube, vimo, or almost any
TV station on the web, they want flash Today.  I Don't know what will be
the standard in 2 or 5 years but right now, its flash.

Go to ABC and You need flash, go to NBC and you need flash, So until  HTML5
takes over the world flash is needed... even it is also good for games not
just videos.


On Fri, May 17, 2013 at 6:51 PM, Griffin Boyce griffinbo...@gmail.comwrote:

 On Thu, May 16, 2013 at 6:41 PM, Lodewijk andré de la porte
 l...@odewijk.nl wrote:
  Regardless you're fighting for dinosaurs. The word is out, flash isn't
  required and it's really unsafe.

   Flash isn't even as useful as current alternatives (webm video).
 You could make the case that Flash allows for amazing video games, but
 that seems like the perfect use-case for high-throughput/low-lag VPNs.

 ~Griffin
 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Finger printing

[Andrew F]

Some one in Tor-Dev said that finger printing of the system and video card
in particular allows someone to be tracked as well as having a cookie on
there system.

That sound pretty serious to me.  Anyone working on this issue?

Do we have any projects on obfuscating Finger print data?

Seems like it should be a top priority.
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] WebGL forbidden in NoScript but Flash is not?

[Andrew F]

I am coming in late on this topic and know very little about it,
But I have to ask, would it be possible to send fake information?
I know that they use many variables to create a mosaic to identify people.
So why not change several variables.  Create some randomness
and change several variables on an irregular basis.
I am sure this will not be the last salvo in the on going war of
identification, but
it may help for a while.



On Tue, May 7, 2013 at 10:27 PM, Moritz Bartl mor...@torservers.net wrote:

 On 07.05.2013 20:38, Joe Btfsplk wrote:
  TBB may have NoScript settings to not have checked Forbid Flash
  because it doesn't contain Flash Player.
 
  What about WebGL being blocked by default in NoScript?  I thought this
  was supposed to be a much safer (not a threat to Tor) than Flash?

 https://www.torproject.org/projects/torbrowser/design/

 WebGL can reveal information about the video card in use, and high
 precision timing information can be used to fingerprint the CPU and
 interpreter speed.
 [...]
 The adversary simply renders WebGL, font, and named color data to a
 Canvas element, extracts the image buffer, and computes a hash of that
 image data. Subtle differences in the video card, font packs, and even
 font and graphics library versions allow the adversary to produce a
 stable, simple, high-entropy fingerprint of a computer. In fact, the
 hash of the rendered image can be used almost identically to a tracking
 cookie by the web server.
 [...]
 WebGL is fingerprintable both through information that is exposed about
 the underlying driver and optimizations, as well as through performance
 fingerprinting.

 Because of the large amount of potential fingerprinting vectors and the
 previously unexposed vulnerability surface, we deploy a similar strategy
 against WebGL as for plugins. 

 --
 Moritz Bartl
 https://www.torservers.net/
 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] WebGL forbidden in NoScript but Flash is not?

[Andrew F]

What is tor doing about finger printing?
Is there a project to deal with that?



On Wed, May 8, 2013 at 12:13 AM, Joe Btfsplk joebtfs...@gmx.com wrote:


 On 5/7/2013 5:27 PM, Moritz Bartl wrote:


 https://www.torproject.org/**projects/torbrowser/design/https://www.torproject.org/projects/torbrowser/design/

 WebGL can reveal information about the video card in use, and high
 precision timing information can be used to fingerprint the CPU and
 interpreter speed.
 [...]
 The adversary simply renders WebGL, font, and named color data to a
 Canvas element, extracts the image buffer, and computes a hash of that
 image data. Subtle differences in the video card, font packs, and even
 font and graphics library versions allow the adversary to produce a
 stable, simple, high-entropy fingerprint of a computer. In fact, the
 hash of the rendered image can be used almost identically to a tracking
 cookie by the web server.
 [...]
 WebGL is fingerprintable both through information that is exposed about
 the underlying driver and optimizations, as well as through performance
 fingerprinting.

 Because of the large amount of potential fingerprinting vectors and the
 previously unexposed vulnerability surface, we deploy a similar strategy
 against WebGL as for plugins. 

  OK, thanks for detailed reply.  Now that the adversary has a
 fingerprint of my machine (therein lies the problem - the data being given
 out), unless they're the gubment  I'm a bad guy (or living in a represses
 society), what are they going to do w/ that info?  In the real world, not,
 theoretically, they could...  Let's assume I haven't done anything that
 falls under criminal court jurisdiction  very unlikely anything even
 falling under civil court jurisdiction.

 This is good info to know.  My wondering about another method of using a
 stand alone media player (not browser plugin) that plays Flash or WebGL
 content,  whether it avoids some of these issues, is in another post,
 today.

 __**_
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/**cgi-bin/mailman/listinfo/tor-**talkhttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] NSA supercomputer

[Andrew F]

How about he BSD license?


On Fri, Apr 19, 2013 at 11:28 AM, NoName antispa...@sent.at wrote:

 On 19.04.2013 16:43, grarpamp wrote:

 Oh! The Romantic Life of a Beancounter.
 How about The Politics of Heroin in Southeast Asia? Does that get listed
 in
 the Congress debate for budget?


 Ever see Indiana Jones? Somewhere in that giant warehouse
 is the answer you seek. Bring your beancounters and be sure
 to pack a lunch :) Suffice it to say, something like that might
 fall under executive branch discretionary funds which, assuming
 a closed system, have to roll up somewhere in the ledger.
 We have some surplus cots and a nice deli next door if you
 need more time :)


 Last time I have checked Indiana Jones is a franchise ready to squeeze the
 last penny out of a guillable child. I'll honor them with my time once they
 place it under GPL v3 or at least some Creative Commons license.

 __**_
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/**cgi-bin/mailman/listinfo/tor-**talkhttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Cowardice and Hypocrisy

[Andrew F]

G
riffin... its comments like that which make me wish we had a like button on
e-mail.

Well said!


On Mon, Apr 15, 2013 at 1:23 AM, Griffin Boyce griffinbo...@gmail.comwrote:

 SiNA Rabbani s...@redteam.io wrote:

  If you mattered at all, you would have been owned by now
 

 Snaaap.

 You may fork our code, but you'll never fork our ~freedom!~

 or my cuddliness,
 Griffin Boyce

 --
 Please note that I do not have PGP access at this time.
 OTR: sa...@jabber.ccc.de / fonta...@jabber.ccc.de
 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Bad Exit Node Control

[Andrew F]

Aaron, Do you know the answer or where I can find the information?  a doc
file perhaps?

When Tor sends out packets over the Tor network, are they always the same
size?  If not is there a max size?

thanks


On Thu, Apr 11, 2013 at 1:17 PM, Andrew F andrewfriedman...@gmail.comwrote:

 Aaron, thanks for clarification.  I thought we were talking about exit
 nodes that are run by people that are sniffing data.
  Sure would be nice to identify those exit nodes and deal with them.


 On Wed, Apr 3, 2013 at 9:15 PM, Aaron aag...@extc.org wrote:

 On Mon, Apr 1, 2013 at 10:01 PM, Andrew F andrewfriedman...@gmail.com
 wrote:
  Why kick of bad exits?  If you identify an exit that is gathering data
 or
  manipulating data, then simply take them out of rotation and feed them
  false connections so that they stay on line and wast resources.
  Otherwise
  they will shut down and be back up the same day.

 BadExit means that relays will not pick this relay as an exit, but it
 will still be used as a non-exit relay.

 --Aaron
 
  If you can lead them on for a while it will make all tor users safer.
 
 
  On Mon, Apr 1, 2013 at 8:21 PM, Aaron aag...@extc.org wrote:
 
  On Sun, Mar 31, 2013 at 4:45 PM, Roc Admin onionrou...@gmail.com
 wrote:
   I took another look at the OONI project. Although it's oriented
 towards
   ISPs etc, isn't this almost exactly what's needed - or at least a
 start?
   The tests for many of the items that Mike Perry identified in the
 spec
  are
   already there.
  
  
 
 https://gitweb.torproject.org/ooni-probe.git/blob/16ec7a88d426b30a7bd604e97e6b5d7225b9bb91:/README.md
  
   Thoughts?
 
  This is a thought I've also had. There are some missing parts (namely,
  Tor circuit control) that don't yet exist, but intend to add in the
  future. There should be an OONI test template (see ooni/templates) for
  tests that need to interact with Tor.
 
  Some other things to address:
  * how are exits selected for testing? From an input file? Or Tor
 consensus?
  * how are the output reports formatted? What data is included? Where
  are they submitted?
  * Who runs the tool? Would it work like the current BwAuth, where a
  DirAuth and BwAuth operator pair up, or could anyone report BadExit?
 
  This sounds like a project needing a proposal (see tor-spec.git if
  you're not familiar). I'd be happy to collaborate, if anyone is
  interested in going this direction.
 
  --Aaron
 
   ROC
  
  
   On Sun, Mar 31, 2013 at 11:12 AM, Aaron aag...@extc.org wrote:
  
   On Sat, Mar 30, 2013 at 4:18 PM, Roc Admin onionrou...@gmail.com
  wrote:
Does this mean that you're planning to expand the SoaT codebase?
  Write
a revised version? If the project is going to be revived then it
  would
make sense for it to take advantage of one of our newer
 controller
libraries...
   
Yeah the plan is to do a complete rerwrite of SoaT. That guy was a
beast and almost did its job too well. I talked a little about
 this on
the tor-dev side but I'm definitely using Stem. I didn't know
 about
the other project though so thank you. There was also some
 discussion
about interfacing with Onionoo but now we're talking too far down
 the
line.
   
2. Even when a bad exit *is* reported our process for flagging
 it is
pretty well broken. To be flagged at least two of the three
 authority
operators that vote on the BadExit flag need to take manual
 action.
All three operators are highly busy people so in practice relays
  don't
get flagged without considerable nagging.
   
Exactly. I think Mike Perry's proposal that Aaron linked to is
 still
spot on in terms of what we want from a solution. In the
 deployment
section it notes three phases where the final one is an automatic
communication between the scanning engine and the Tor Network so
 that
it alerts Directory Authorities. This interface in itself requires
some thought. It's threat model includes accidentally causing a
 DoS on
all hosts on the network if something goes wrong, or
 inappropriately
flag a good node, or the fact that knowing how to tool works, a
malicious node could change it's activities to avoid detection.
   
The other issue that is stuck in my head is that I think exit
 scanning
is always going to be a losing battle and this is a best-effort
 game.
I see it in the same way that Android has tried to keep track of
malware on the Play market. It will be days in even the best case
scenario before we find out an exit node is malicious and properly
report them. It's high effort for little return.
  
   While it may be an arms race. I don't think it's as bad as you might
   think. For starters, there's a lot of low hanging/high reward fruit
 --
   just two volunteers running BadExit scans collaboratively would be a
   huge improvement.
  
In an ideal - not-Tor world - there could be some kind of
 activation
process for exit nodes that validate

Re: [tor-talk] NSA supercomputer

[Andrew F]

I know a chip designer who explained to me that when they are testing chips
for functionality, workability and general integrity, they will run test
chips on a wafer.   So while expensive, it is possible to do short runs on
custom cpu's.  Test runs happen everyday at every foundry.  It is
completely plausible that a company might have a few thousand custom chips
used to crack various algorithms.  all it takes is money and motivation.


On Thu, Apr 11, 2013 at 6:57 PM, The Doctor dr...@virtadpt.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 04/05/2013 02:01 PM, Andrew F wrote:

  Basically he said that with quantum computing all bets are off and
  every cipher today will likely be cracked. Quantum computing will
  require new kinds of ciphers and only those with Qcomputers will be
  able to decrypt the messages.

 I will just leave this here...

 https://www.google.com/search?q=post+quantum+cryptography

 - --
 The Doctor [412/724/301/703] [ZS]
 Developer, Project Byzantium: http://project-byzantium.org/

 PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F  DD89 3BD8 FF2B 807B 17C1
 WWW: https://drwho.virtadpt.net/

 Long story short, that's how I wound up on Wikipedia.

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.19 (GNU/Linux)
 Comment: Using GnuPG with undefined - http://www.enigmail.net/

 iEYEARECAAYFAlFnB6UACgkQO9j/K4B7F8GdRgCfVAaTUosAHn4Rz9AH7YQxdscv
 3A8An3qfJ27MG2SkfWtJ5KeEMdjjdZOs
 =OVuj
 -END PGP SIGNATURE-
 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] NSA supercomputer

[Andrew F]

FYI,  2011  AES  cracked... Sorta.   4 time faster  but still takes 2
billion years.

To put this into perspective: on a trillion machines, that each could test
a billion keys per second, it would take more than two billion years to
recover an AES-128 key, the Leuven University researcher added.

http://www.theinquirer.net/inquirer/news/2102435/aes-encryption-cracked


On Tue, Apr 9, 2013 at 2:53 AM, Andrew Lewman and...@torproject.is wrote:

 On Mon, 08 Apr 2013 19:20:02 +
 adrelanos adrela...@riseup.net wrote:

  Paul Syverson:
   http://www.onion-router.net/History.html
  
   covers what I said and then some, basically gives a brief history
   roughly 1995-2005. Althought the site seems to be down right now.
 
  How long will that page be available anyway?

 As long as Tor exists and the domain is registered.

 --
 Andrew
 http://tpo.is/contact
 pgp 0x6B4D6475
 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] NSA supercomputer

[Andrew F]

I would love to see an analysis of a 128 bit AES encryption VS a 10 exoflop
computer. How long to crack it?  Anyone got the math on this?

Andreas, your absolutely right, However we can do some estimating.
Just keep in mind... garbage in, garbage out.. but  this is a pretty good
guess.

So the fastest super computers use general cpus and Nvidia k20s. This is
important to note because they scale in a linear fashion based on available
space.   Now we know that Oak ridge national labs has about an acre of
space, 43,560 Sq. Feet,  for its super computer, the Cray XK7 Named Titan.
Which runs at 17.59 Pentaflops.  (yes PENTAFLOPS)
http://www.top500.org/lists/2012/11/

According to a Cray press release Titan can scale up to 50 Pentaflops.

Now the new facility in Utah will have over 200,000 sq. feet dedicated to
its super computer.

(
http://www.forbes.com/sites/andygreenberg/2012/03/16/nsas-new-data-center-and-ultra-fast-supercomputer-aim-to-crack-worlds-strongest-crypto/)


So If we assume, the a linear relationship between Square footage and
computing power then we can calculate that Utah will have 4.59  time more
space then Oak Ridge, so they will have room for at least 80.73
pentaflops.

Several articles have stated that the center is designed to house an
Exoflop computer.  Thats a fast computer. Thats 10 followed by 18 zeros. Or
1000 petaflops.

There is more.  Lets look at our growth rate.   4.5 years ago Roadrunner
was the first super computer to brake the pentaflop barrier. Today we have
titan at 17.59 pentaflops. So if we can assume a growth rate of 380% per
year.  And that the center will be up graded with each new version of GPU
from Nvidia and CPUs from Intel, We can assume that we will hit one Exoflop
in about three years or 2015.

The power production at the new facility supports these numbers.

So what does this mean?   Any article that suggest that brute forcing
present day encryption is not possible should be taken with a grain of
salt.  While the article may be correct today, come September 2012, Utah
goes on line and we will be stepping into a world that will lead to exaflop
computers and may challenges to our present day encryptions.

AES is safe for a longtime, but other encryptions should be of concern in
the coming years.Don't forget about tracking and fingerprinting
possibilities with these massive systems.

I would love to see an analysis of a 128 bit AES encryption VS a 10 exoflop
computer. How long to crack it?  Anyone got the math on this?

The good news, no one is going to care about your stuff... unless your
making waves.   Then the only safe encryption is a non mathematical method,
such as a  library code run on a system that does not go on the net.


On Fri, Apr 5, 2013 at 8:00 AM, Eugen Leitl eu...@leitl.org wrote:

 On Thu, Apr 04, 2013 at 01:55:40PM -0400, Gregory Disney wrote:
  Just saying TOR was created by the Naval Research Laboratory a part of

 The name's Tor, not TOR.

  DARPA. Since it's inception they could index, spider and track the dark
  net.
 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] NSA supercomputer

[Andrew F]

I saw a lecture a while back, I think it was given by Whitfield Diffie of
public/ private  key fame although it was quite a while ago... , The
speaker said that the gov was storing encrypted messages that have been
intercepted from critical sources in hopes that quantum computing will
allow them to crack the encryptions eventually.

Basically he said that with quantum computing all bets are off and every
cipher today will likely be cracked. Quantum computing will require new
kinds of ciphers and only those with Qcomputers will be able to decrypt the
messages.

So a new class of people / government will emerge.   One class will be able
to decrypt or crack all messages sent with encryption.  And the other class
of people, those without Qcomputers, will only be able to decrypt ciphers
that they can encrypt. One class can only view messages they create,
the other class can see everything.

I am guessing that the cost of Qcomputer technology will keep these
machines out of the hands of Joe public for decades to come...?


On Fri, Apr 5, 2013 at 5:19 PM, Andreas Bader noergelpi...@hotmail.dewrote:

 Some days ago I read that the first usable Quantumcomputing System is on
 the market. Can some estimate how this possibly influences the decryption
 of different ciphers?

 Andreas
 -Original Message-
 From: Andrew F andrewfriedman...@gmail.com
 Date: Fri, 5 Apr 2013 13:51:06
 To: tor-talk@lists.torproject.org
 Subject: Re: [tor-talk] NSA supercomputer


 I would love to see an analysis of a 128 bit AES encryption VS a 10 exoflop
 computer. How long to crack it?  Anyone got the math on this?

 Andreas, your absolutely right, However we can do some estimating.
 Just keep in mind... garbage in, garbage out.. but  this is a pretty good
 guess.

 So the fastest super computers use general cpus and Nvidia k20s. This is
 important to note because they scale in a linear fashion based on available
 space.   Now we know that Oak ridge national labs has about an acre of
 space, 43,560 Sq. Feet,  for its super computer, the Cray XK7 Named Titan.
 Which runs at 17.59 Pentaflops.  (yes PENTAFLOPS)
 http://www.top500.org/lists/2012/11/

 According to a Cray press release Titan can scale up to 50 Pentaflops.

 Now the new facility in Utah will have over 200,000 sq. feet dedicated to
 its super computer.

 (

 http://www.forbes.com/sites/andygreenberg/2012/03/16/nsas-new-data-center-and-ultra-fast-supercomputer-aim-to-crack-worlds-strongest-crypto/
 )


 So If we assume, the a linear relationship between Square footage and
 computing power then we can calculate that Utah will have 4.59  time more
 space then Oak Ridge, so they will have room for at least 80.73
 pentaflops.

 Several articles have stated that the center is designed to house an
 Exoflop computer.  Thats a fast computer. Thats 10 followed by 18 zeros. Or
 1000 petaflops.

 There is more.  Lets look at our growth rate.   4.5 years ago Roadrunner
 was the first super computer to brake the pentaflop barrier. Today we have
 titan at 17.59 pentaflops. So if we can assume a growth rate of 380% per
 year.  And that the center will be up graded with each new version of GPU
 from Nvidia and CPUs from Intel, We can assume that we will hit one Exoflop
 in about three years or 2015.

 The power production at the new facility supports these numbers.

 So what does this mean?   Any article that suggest that brute forcing
 present day encryption is not possible should be taken with a grain of
 salt.  While the article may be correct today, come September 2012, Utah
 goes on line and we will be stepping into a world that will lead to exaflop
 computers and may challenges to our present day encryptions.

 AES is safe for a longtime, but other encryptions should be of concern in
 the coming years.Don't forget about tracking and fingerprinting
 possibilities with these massive systems.

 I would love to see an analysis of a 128 bit AES encryption VS a 10 exoflop
 computer. How long to crack it?  Anyone got the math on this?

 The good news, no one is going to care about your stuff... unless your
 making waves.   Then the only safe encryption is a non mathematical method,
 such as a  library code run on a system that does not go on the net.


 On Fri, Apr 5, 2013 at 8:00 AM, Eugen Leitl eu...@leitl.org wrote:

  On Thu, Apr 04, 2013 at 01:55:40PM -0400, Gregory Disney wrote:
   Just saying TOR was created by the Naval Research Laboratory a part of
 
  The name's Tor, not TOR.
 
   DARPA. Since it's inception they could index, spider and track the dark
   net.
  ___
  tor-talk mailing list
  tor-talk@lists.torproject.org
  https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
 
 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
 ___
 tor-talk mailing list
 tor

Re: [tor-talk] NSA supercomputer

[Andrew F]

George, thank for posting. And perhaps you should read a little closer
before you get critical
I posted this question at the top of my post because I was looking for
someone like you, (well a little nicer) to help us with the math.
Also, I was only restating lectures that I have heard over the last two
years.

I think it is important to distinguish between Brute forcing the complete
cipher in a true sense, or as you say using an
interesting attack.   You are correct new methods will be found and  many
of those methods will use Brute force as a component on some of the
variables in the attack.  So gobs of computing power + clever attack
strategies, will reveal new methiods.

So lets look at this from another view.   How fast does a computer have to
be to fully bruit force a 64,128,256 key?  ZettaFlops?  YottaFlops?
http://en.wikipedia.org/wiki/Flops   Lets assume a classical
computer.

George, crankup that abacus of yours and let us know.  I for one would be
very interested.
Or anyone else with big fat calculator?  My is the wimpy drugstore kind...

Thanks for the calculations above.
Andrew




On Fri, Apr 5, 2013 at 8:57 PM, Gregory Maxwell gmaxw...@gmail.com wrote:

 On Fri, Apr 5, 2013 at 6:51 AM, Andrew F andrewfriedman...@gmail.com
 wrote:
  I would love to see an analysis of a 128 bit AES encryption VS a 10
 exoflop
  computer. How long to crack it?  Anyone got the math on this?
 [...]
  So what does this mean?   Any article that suggest that brute forcing
  present day encryption is not possible should be taken with a grain of
  salt.  While the article may be correct today, come September 2012, Utah
 [...]
  I would love to see an analysis of a 128 bit AES encryption VS a 10
 exoflop
  computer. How long to crack it?  Anyone got the math on this?

 You really should take just a _moment_ to do a little figuring before
 posting to a public list and consuming the time of hundreds or
 thousands of people.

 Lets assume that decrypting with a key and checking the result is one
 Floating point operation (since you're asking us to reason about
 apples and oranges, I'll just grant you that one apple stands for all
 the required oranges).

 To search a 128 bit keyspace on a classical computer you would expect
 that on average the solution will be found in 2^127 operations.

 2^127 'flops' / 10 exaflop/s =  2^127 flops / 10*10^18 flops/second =
 17014118346046923173 seconds = 539,152,256,819 years.

 ...Or, about 39x the currently believed age of the universe.

 Surely with a lot of computing power there are many very interesting
 attacks— particularly in the domain of traffic analysis, weak user
 provided keys, discovering new faster than brute force attacks, etc.
 But to suggest that they're going to classically brute force a 128 bit
 block cipher is laughable, even with very generous thinking.
 Honestly, these other things are arguably far more worrisome but
 they're all just handwaving... which is all any of this discussion
 is...
 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] NSA supercomputer

[Andrew F]

Anthony, good point.  And worth a lot more then $0.02


Thanks Seth excellent write up.  I will have to brake out the sci
calculator and run some number.
I know the flops issue is a big one, but thats the only measure I could
find for the big system in Utah.
However, your point is well taken.  No way to really know without testing.
How about a road trip... we could knock on the the door and ask for 10
minutes of computer time?
Knock knock... hello Mr NSA, can we use your super secret spy computer for
10 minutes?
And Yes, My next post after asking that question will be from sunny
Guantánamo Bay.  As I am sure I will get an all expense paid trip
 from our friends in the (*Redacted *).

You know, if anyone has an Nvidia Xk20 and an AMD 16 core working together,
we could test on a small scale and then extrapolate from there, get an
estimate of efficiency per second and do the calculations.  If anyone wants
to mess around with it and has the hardware...  :-)  I'll buy the pizza and
beer. In fact, It would be a fun article to write.So just how fast is
the NSA supercomputer?

Ok, everyone, have a good weekend.








On Fri, Apr 5, 2013 at 9:33 PM, Anthony Papillion anth...@papillion.mewrote:

 On 04/05/2013 01:01 PM, Andrew F wrote:
 
  Basically he said that with quantum computing all bets are off and every
  cipher today will likely be cracked. Quantum computing will require new
  kinds of ciphers and only those with Qcomputers will be able to decrypt
 the
  messages.

 Not entirely correct, as I understand it. Granted, quantum computing
 will shred most (all?) of the ciphers we currently use. But that's
 mostly because they will be able to do massively efficient prime
 factorization using something like Shor's algorithm
 (https://en.wikipedia.org/wiki/Shor%27s_algorithm). If I understand
 correctly, resisting such technology doesn't require creating a cipher
 that takes a quantum computer to decrypt but one that is resistant to
 efficient factorization.


 Just my $0.02,
 Anthony
 ___
 tor-talk mailing list
 tor-talk@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Bad Exit Node Control

[Andrew F]

Why kick of bad exits?  If you identify an exit that is gathering data or
manipulating data, then simply take them out of rotation and feed them
false connections so that they stay on line and wast resources.  Otherwise
they will shut down and be back up the same day.

If you can lead them on for a while it will make all tor users safer.


On Mon, Apr 1, 2013 at 8:21 PM, Aaron aag...@extc.org wrote:

 On Sun, Mar 31, 2013 at 4:45 PM, Roc Admin onionrou...@gmail.com wrote:
  I took another look at the OONI project. Although it's oriented towards
  ISPs etc, isn't this almost exactly what's needed - or at least a start?
  The tests for many of the items that Mike Perry identified in the spec
 are
  already there.
 
 
 https://gitweb.torproject.org/ooni-probe.git/blob/16ec7a88d426b30a7bd604e97e6b5d7225b9bb91:/README.md
 
  Thoughts?

 This is a thought I've also had. There are some missing parts (namely,
 Tor circuit control) that don't yet exist, but intend to add in the
 future. There should be an OONI test template (see ooni/templates) for
 tests that need to interact with Tor.

 Some other things to address:
 * how are exits selected for testing? From an input file? Or Tor consensus?
 * how are the output reports formatted? What data is included? Where
 are they submitted?
 * Who runs the tool? Would it work like the current BwAuth, where a
 DirAuth and BwAuth operator pair up, or could anyone report BadExit?

 This sounds like a project needing a proposal (see tor-spec.git if
 you're not familiar). I'd be happy to collaborate, if anyone is
 interested in going this direction.

 --Aaron

  ROC
 
 
  On Sun, Mar 31, 2013 at 11:12 AM, Aaron aag...@extc.org wrote:
 
  On Sat, Mar 30, 2013 at 4:18 PM, Roc Admin onionrou...@gmail.com
 wrote:
   Does this mean that you're planning to expand the SoaT codebase?
 Write
   a revised version? If the project is going to be revived then it
 would
   make sense for it to take advantage of one of our newer controller
   libraries...
  
   Yeah the plan is to do a complete rerwrite of SoaT. That guy was a
   beast and almost did its job too well. I talked a little about this on
   the tor-dev side but I'm definitely using Stem. I didn't know about
   the other project though so thank you. There was also some discussion
   about interfacing with Onionoo but now we're talking too far down the
   line.
  
   2. Even when a bad exit *is* reported our process for flagging it is
   pretty well broken. To be flagged at least two of the three authority
   operators that vote on the BadExit flag need to take manual action.
   All three operators are highly busy people so in practice relays
 don't
   get flagged without considerable nagging.
  
   Exactly. I think Mike Perry's proposal that Aaron linked to is still
   spot on in terms of what we want from a solution. In the deployment
   section it notes three phases where the final one is an automatic
   communication between the scanning engine and the Tor Network so that
   it alerts Directory Authorities. This interface in itself requires
   some thought. It's threat model includes accidentally causing a DoS on
   all hosts on the network if something goes wrong, or inappropriately
   flag a good node, or the fact that knowing how to tool works, a
   malicious node could change it's activities to avoid detection.
  
   The other issue that is stuck in my head is that I think exit scanning
   is always going to be a losing battle and this is a best-effort game.
   I see it in the same way that Android has tried to keep track of
   malware on the Play market. It will be days in even the best case
   scenario before we find out an exit node is malicious and properly
   report them. It's high effort for little return.
 
  While it may be an arms race. I don't think it's as bad as you might
  think. For starters, there's a lot of low hanging/high reward fruit --
  just two volunteers running BadExit scans collaboratively would be a
  huge improvement.
 
   In an ideal - not-Tor world - there could be some kind of activation
   process for exit nodes that validate configurations and performs
   simple checks before they join the network, and contact information is
   confirmed (or at least attempted). This assuredly will never happen
   for a variety of reasons one of which is that it's a deterrent for
   those volunteer operators that we need lots and lots of. I wonder if
   this has already been discussed or if it's worth at least documenting
   the design decision somewhere. It's valid to say We won't do this
   because of X Y and Z but I would like to see how the debate would go
   against a realistic solution (that has yet to be proposed).
 
  This isn't likely to work either, as bad exits can wait arbitrary
  amount of time after passing any tests before attacking clients. I
  think it's preferable that tests are unpredictable, periodic, and
  looks as much like a real user as possible.
 
  
   ROC