Re: [tor-talk] Secure hosting
On 10/26/2014 01:21 PM, Johnny Cash wrote: I'm setting up a blog and I need a secure hosting service. First, I signed up with HostGator, but received an email telling me I needed to call and confirm my account. When I did, they told me my application was rejected, because they refuse registrations made over the TOR network, due to abuse (to be fair, other proxies too). Second, I tried SiteGround, but their live chat requires a plugin, which could reveal my location. Since the Snowden documents revealed government complicity, I won't use GoDaddy, because of their relationship with Microsoft products. Last, I'm looking at host, A Small Orange, but they're based in Texas (like HostGator), and that entire state makes me hear the theme music from the Empire play in my head: dum, dum, duh, dum. ::chills:: Can anyone recommend a good hosting site for a WordPress blog? What about having some small device [at home] running some wordpress instance and a Tor Hidden Service? This means: - no way to know who's behind the content unless you let traces (like captcha…) - you own the hardware, you can put it wherever you want - thus you know who's accessing the device (physically I mean). Downside: users must use Tor in order to access it, or any tor2web gateway that aren't pwned by some gvt instance, if any. Cheers, C. -- 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] recent firefox releases
registered user bigi...@cheapnet.it Dear Sirs, as far as I understand, recent Firefox releases do not support anymore Vidalia and its related possibility to browse anonymously. Though the onion button is still present on the top left corner, it will not work, as you know. The alternative is to use Tor Browser. The problem is that you don't always want or need to browse anonymously every time you connect to internet and have then to wait for a few seconds (30+) your browser till it gets the line through its Tor. Of course Icould use and older version of Firefox, like release 4, for instance, but this is far to old for a satisfactory and safe browsing. So what can I do? I can not have two different versions of Firefox (i.e. Tor Browser + Firefox 31) on my PC, because they interfere the one with the other, trying to share, for example, the same Extensions folder and so on. The alternative is to use two different browsers, like Chrome and Tor Browser. But what about if I only wanted to use Firefox? Is'n there a way to have a version of Firefox with the option to browse anonymously on demand only anymore? Thanks Giorgio -- 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] recent firefox releases
On Mon, Oct 27, 2014 at 09:48:55AM +0100, Gigi Bigio wrote: as far as I understand, recent Firefox releases do not support anymore Vidalia and its related possibility to browse anonymously. Though the onion button is still present on the top left corner, it will not work, as you know. Vidalia was just a program to help you visualize what's going on with Tor, and help you launch your Tor program. It didn't have anything to do with Firefox. But yes, you're right that long ago the Torbutton extension provided a way to switch your Firefox between using Tor and not using Tor. But that turned out to be hard to keep safe: https://blog.torproject.org/blog/toggle-or-not-toggle-end-torbutton and in retrospect it was probably a good decision: http://arstechnica.com/security/2013/10/how-the-nsa-might-use-hotmail-or-yahoo-cookies-to-identify-tor-users/ The alternative is to use Tor Browser. The problem is that you don't always want or need to browse anonymously every time you connect to internet and have then to wait for a few seconds (30+) your browser till it gets the line through its Tor. Have you tried the recent Tor Browser releases? They start much faster for me than the old ones. Of course Icould use and older version of Firefox, like release 4, for instance, but this is far to old for a satisfactory and safe browsing. Agreed, this is not a wise choice. So what can I do? I can not have two different versions of Firefox (i.e. Tor Browser + Firefox 31) on my PC, because they interfere the one with the other, trying to share, for example, the same Extensions folder and so on. This is exactly what many of us do. Tor Browser is designed to not interfere with your other Firefox install. They shouldn't be interfering in any way. If they are, either you're using it wrong (in which case maybe there's a usability issue we can fix), or there's a bug that it would be great to hear about. --Roger -- 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] using UDPGW and tun2socks over Tor
On Fri, Oct 24, 2014 at 1:35 AM, Nathan Freitas nat...@freitas.net wrote: Is there any reason we shouldn't consider supporting UDP over Tor with Orbot, by tunneling the packets using the combination of badvpn's tun2socks and udpgw (udp gateway) feature? There's no reason raw IP itself (any/none of its numbered protocols) shouldn't / couldn't be transported over Tor using OpnVPN (at least until Tor itself is extended as such). This has come up as we are implementing the Android VPNService, and discovered how easy to implement and well performing the badvpn UDP tunneling capability is. This means we can support SIP calling over Tor, video conference and streaming, among other applications... https://code.google.com/p/badvpn/ https://code.google.com/p/badvpn/wiki/tun2socks https://github.com/ambrop72/badvpn ... Not necessarily, unless you're statically mapping all the people (IP's) you want to communicate with beforehand, (which you can't with random unknown participants ie: Bittorrent, or people on dynamic or mobile), you're currently constrained by address collisions: - Trying to pack the entire IPv4 address space you might want to 'call' into your tiny 10.0.0.0/24 adapter space. Same for put entire IPv6 space into your private IPv6/48 adapter space. - Similarly what you're going to do when Tor moves to wider than 80bit onion addressing which currently fits nicely into a private IPv6/48. (Need a secure IPv6-onion address mapping layer pushed into a DHT/blockchain or just resorting to trusting some volunteer run in-net lookup service.) edit: Just noticed badvpn's mention of pushing a *VM* on a 10 address through socks with this, at least for TCP, which is simpler. As opposed to pushing any app on the raw iron through a *VPN* which could be constrained as above. Left this anyway for thought in related things. It does mean that someone would have to operate the gateway/infrastructure portion of udpgw at a capacity necessary to handle all udp streaming traffic sent for all Orbot users, but I would consider that to be feasible. Perhaps udpgw instances can be run along side all Tor exit nodes? Read below thread flowing on both tor-talk and tor-relays, flows over May and June, with better specification/answers in later posts. https://lists.torproject.org/pipermail/tor-relays/2014-May/004516.html Subject: Ops request: Deploy OpenVPN terminators -- 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] using UDPGW and tun2socks over Tor
On Fri, Oct 24, 2014 at 1:35 AM, Nathan Freitas nat...@freitas.net wrote: This means we can support SIP calling over Tor, video conference and streaming, among other applications... Tor as a client also needs support for inbound binds for some apps, at least at the single per port level when interacting with internet at the far end. OpenVPN might, or could be extended to arbitrate those port binding requests. Hidden services do support such binds in hs-to-hs mode, at least statically. -- 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] Bitcoin over Tor isn’t a good idea (Alex Biryukov / Ivan Pustogarov story)
On Thu, Oct 23, 2014 at 7:35 PM, Erik de Castro Lopo mle+to...@mega-nerd.com wrote: http://arxiv.org/pdf/1410.6079v1.pdf Could this situation be improved if people ran limited exit nodes that only alloed the bitcoin p2p protocol to exit? I for one don't have enough There are about ten exit nodes that do only this today. [One of which is run by Mike Hearn who has advocated building in censorship capabilities to Tor, and blocking (historically) tainted coins (such as you have now or might receive through otherwise completely innocent transactions with you, or from your own trans/mixing with others).] Then there is question if your client will select such 'only *coin' nodes versus those with high bandwidth and open exit policies. There are also a fair number of hidden services in Tor/I2P/CJDNS that act as bitcoin nodes. As related tangent, yes, the bitcoin protocol needs to be encrypted on the wire, at least bitcoin node to bitcoin node with TLS, obviously and urgently so, particularly if you wish to guard your trans from wire listeners. You might be best to in fact run bitcoin always and entirely over Tor, especially while transacting. But then also routinely compare that received blockchain to one you receive via alternate/trusted sources, such as clearnet or signed bittorrent checkpoints. -- 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] Bitcoin over Tor isn’t a good idea (Alex Biryukov / Ivan Pustogarov story)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I didn't realise my nodes didn't allow the bitcoin port. I'll get right on it. Also, if anyone in the Tor community has spare capacity, you can also setup a full bitcoin node on the same server you use as an exit/relay/bridge and it doesn't take up a great deal of resources other than disk space (16Gb I think right now and growing slowly). On my series of exits there is also full bitcoin nodes accessible exclusively over hidden services and others which are accessible over regular clearnet. - -T On 27/10/2014 19:58, grarpamp wrote: On Thu, Oct 23, 2014 at 7:35 PM, Erik de Castro Lopo mle+to...@mega-nerd.com wrote: http://arxiv.org/pdf/1410.6079v1.pdf Could this situation be improved if people ran limited exit nodes that only alloed the bitcoin p2p protocol to exit? I for one don't have enough There are about ten exit nodes that do only this today. [One of which is run by Mike Hearn who has advocated building in censorship capabilities to Tor, and blocking (historically) tainted coins (such as you have now or might receive through otherwise completely innocent transactions with you, or from your own trans/mixing with others).] Then there is question if your client will select such 'only *coin' nodes versus those with high bandwidth and open exit policies. There are also a fair number of hidden services in Tor/I2P/CJDNS that act as bitcoin nodes. As related tangent, yes, the bitcoin protocol needs to be encrypted on the wire, at least bitcoin node to bitcoin node with TLS, obviously and urgently so, particularly if you wish to guard your trans from wire listeners. You might be best to in fact run bitcoin always and entirely over Tor, especially while transacting. But then also routinely compare that received blockchain to one you receive via alternate/trusted sources, such as clearnet or signed bittorrent checkpoints. - -- Fingerprint: 9DB0 082F 8FE2 E691 DA2A 6D03 4DAE 4226 9EB0 EB0B Fingerprint: FAA4 2253 AA4B 38D0 1BC4 085E F688 CEF6 F9BF D57F OTR IRC: DF63021D 27973EAA 02FA4DF6 9E52C9E0 8821E0EF OTR XMPP: 77DB65BC C417C4DD 19F9664D 83D6D3FB 6C3D3A0E Twitter: https://twitter.com/CthulhuSec Not familiar with PGP? Get started today: http://www.bitcoinnotbombs.com/beginners-guide-to-pgp/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUTqUCAAoJEE2uQiaesOsL23QQAJG4XGhiMRCtAMhb6dbq9jHo OZ5CPysEkXwMSK6dTwpCm9GuMHloK3Dq+CzKa6dDeBmEVslWxbXtsx0by0pDjJbS I7tiIpjHrCJTrKgDbPQWJP3yZQ8W+fu3JYW+OxZxbrRXEvrX9vgD2pF3zVn2vb76 n5LEtlmR8rMCC5JAq2tjFY7665xMkloYXay/VE7E2d9eZ5W1/4V1nHcm5cn7RTix PxDvD6FAJCNAH7F5rGoGHzC9V9mPAatBfV5S/3Ya49PRtM70tWWBJD/L3KrB71k0 F7P5eNrfL7gOgFgAIJ1FWuJH7Ri9kCyntsLSgEZBSwYeHEACfFL2qGO1IEw1qRCj nxopXSMCNBQu8XP1568ha6KPyKLOTD0kVehE3tgVizabRMTwkuXqiUslbMCRthwy y7WmPAaVgEYnGhIhnRHnf/G0tbfsBcInIyCrBuqfJfLnVfx7IPMDP52JLIg71tyM RamPUNIv840HkpvTlYwTVIRwL5hFpeW327hxhcnkWFi0mUwb12Lr+N7BlB3aQGE9 bVmqS4oq1qb6y0TTUlcEg42CDs9GpdVB3Amdcm9Y5scE6upDq+J9yO6322eh82Kq qlJK1mnVHMyf3ZGS0ItqGuu54SjiB4kzVt4FV2einjYu4gXT+WiMRCmx1Hzk2hgO t6iZ3nLBtWK19kpt4UVD =jdgx -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] using bridges with dns name
Here is my problem: The network administrator of my job search the firewall's (squid) log for anything strange, so when tor connects using a bridge, the firewall's log show: ... mail.google.com www.frootvpn.com 23.54.23.32 - bridge's ip bits.wikimedia.org startpage.com ... I get the dns name of the bridge's ip and put it in the configuration of Vidalia, but the ip keeps showing in the log. My question is, is there a way to tell tor to use dns names for bridges instead of ip, in a way that the dns name is registered by the firewall instead of the ip? -- 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] Bitcoin over Tor isn’t a good idea (Alex Biryukov / Ivan Pustogarov story)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here are some Bitcoin reliable nodes sponsored by Thomas (TheCthulhu) accessible via Tor hidden services: h2vlpudzphzqxutd.onion sbow7bnje2f4gcvt.onion dioq2yg3l5ptgpge.onion All use Bitcoin default port 8333. These servers are up all the time and very fast. Hidden services are end-to-end encrypted so the risk of MITM between nodes does not exist. Also, if you run bitcoin in such a way with onlynet=tor enabled in config, nobody listening your wire can have a slight clue that you use bitcoin. We think tor-hidden-services only Bitcoin nodes are a very important part of the Bitcoin ecosystem. Getting them running is quite simple. You just need disk space, at least 50GB free for now. Here are some guides: https://www.sky-ip.org/configure-bitcoin-node-debian-ubuntu.html https://www.sky-ip.org/configure-bitcoin-node-freebsd.html On 10/27/2014 10:03 PM, Thomas White wrote: I didn't realise my nodes didn't allow the bitcoin port. I'll get right on it. Also, if anyone in the Tor community has spare capacity, you can also setup a full bitcoin node on the same server you use as an exit/relay/bridge and it doesn't take up a great deal of resources other than disk space (16Gb I think right now and growing slowly). On my series of exits there is also full bitcoin nodes accessible exclusively over hidden services and others which are accessible over regular clearnet. -T On 27/10/2014 19:58, grarpamp wrote: On Thu, Oct 23, 2014 at 7:35 PM, Erik de Castro Lopo mle+to...@mega-nerd.com wrote: http://arxiv.org/pdf/1410.6079v1.pdf Could this situation be improved if people ran limited exit nodes that only alloed the bitcoin p2p protocol to exit? I for one don't have enough There are about ten exit nodes that do only this today. [One of which is run by Mike Hearn who has advocated building in censorship capabilities to Tor, and blocking (historically) tainted coins (such as you have now or might receive through otherwise completely innocent transactions with you, or from your own trans/mixing with others).] Then there is question if your client will select such 'only *coin' nodes versus those with high bandwidth and open exit policies. There are also a fair number of hidden services in Tor/I2P/CJDNS that act as bitcoin nodes. As related tangent, yes, the bitcoin protocol needs to be encrypted on the wire, at least bitcoin node to bitcoin node with TLS, obviously and urgently so, particularly if you wish to guard your trans from wire listeners. You might be best to in fact run bitcoin always and entirely over Tor, especially while transacting. But then also routinely compare that received blockchain to one you receive via alternate/trusted sources, such as clearnet or signed bittorrent checkpoints. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUTseIAAoJEIN/pSyBJlsRvDsH/1JTXOExUnLAtec2uGhloCAu xuacUvwPAY9iJ102/PMQhFS6O2kc9tABiKPPWa2GSAx2pBlXuBSq74Rij8Q+bpv/ 8VYAxT0uyVEGvXs2k579exuWrNkQ3uRQZcBnh/+EGBC+8UybaT9HGN1qnZ0vcI0r +zW54ma8P+FY8JfxQVauDEJZtsrAXnr+2Riwzqd47l6aScM7PVKoVq/eLBuTwf5x TqoxmxVuFdLxDxiReq73/8g2x9ecFjvrGb1/qkLo7mdV5f01/24gYP1EpXbbN8Rf 2C2fuYXihvJfGVtRkug1X9Wf+hwTIGgiGnIc+rhwg24NP62qPm3+Kxngs/zfysE= =law6 -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
Re: [tor-talk] Bitcoin over Tor isn’t a good idea (Alex Biryukov / Ivan Pustogarov story)
s7r writes: All use Bitcoin default port 8333. These servers are up all the time and very fast. Hidden services are end-to-end encrypted so the risk of MITM between nodes does not exist. Also, if you run bitcoin in such a way with onlynet=tor enabled in config, nobody listening your wire can have a slight clue that you use bitcoin. I don't mean to disparage the contribution of people who are running Bitcoin hidden service nodes. I think that's a very useful contribution. I do want to question three things about the benefits of doing so. First, the security of hidden services among other things relies on the difficulty of an 80-bit partial hash collision; even without any new mathematical insight, that isn't regarded by NIST as an adequate hash length for use past 2010. (There has been some mathematical insight about attacking SHA-1, which Tor hidden service names use, although I don't remember whether any of it is known to be useful for generating partial preimages.) Tor hidden service encryption doesn't consistently use crypto primitives that are as strong as current recommendations, though I think they matched recommendations when the Tor hidden service protocol was first invented. That means that the transport encryption between a hidden service user and the hidden service operator is not as trustworthy in some ways as a modern TLS implementation would be. Second, a passive attacker might be able to distinguish Bitcoin from other protocols running over Tor by pure traffic analysis methods. If a new user were downloading the entire blockchain from scratch, there would be a very characteristic and predictable amount of data that that user downloads over Tor (namely, the current size of the entire blockchain -- 23394 megabytes as of today). Not many files are exactly that size, so it's a fairly strong guess that that's what the user was downloading. Even submitting new transactions over hidden services might not be very similar to, say, web browsing, which is a more typical use of Tor. The amount of data sent when submitting transactions is comparatively tiny, while blockchain updates are comparatively large but aren't necessarily synchronized to occur immediately after transaction submissions. So maybe there's a distinctive statistical signature observable from the way that the Bitcoin client submits transactions over Tor. It would at least be worth studying whether this is so (especially because, if it is, someone who observes a particular Tor user apparently submitting a transaction could try to correlate that transaction with new transactions that the hidden services first appeared to become aware of right around the same time). Third, to take a simpler version of the attacks proposed in the new paper, someone who _only_ uses Bitcoin peers that are all run by TheCthulhu is vulnerable to double-spending attacks, and even more devious attacks, by TheCthulhu. (You might say that TheCthulhu is very trustworthy and would never attack users, but that does at least undermine the decentralization typically claimed for Bitcoin because you have to trust a particular hidden service operator, or relatively small community of hidden service operators, not to attack you by manipulating your view of the blockchain and transaction history.) Using Bitcoin over Tor hidden services might be a good choice for most users today who want their transactions and private key ownership to be as private as possible, but it's not free of risk, and it's probably not an appropriate long-term solution to recommend to the general public without fixes to some of the technologies involved! -- 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 To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Bitcoin over Tor isn’t a good idea (Alex Biryukov / Ivan Pustogarov story)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seth, Totally agree about undermining decentralization by having to trust a single provider. Nobody recommended that, the addresses were for informative purpose only, to be used in parallel with other nodes run by other operators / organizations. No user is forced to use exclusively peers run by the same operator. An user is free to add as many hidden nodes for bootstrapping as desired. Once connected to a node that node will exchange information about other nodes and so on. I agree the hidden services are old. There is a nice proposal, hopefully it will be analyzed more and implemented as soon as possible. On 10/28/2014 1:19 AM, Seth David Schoen wrote: s7r writes: All use Bitcoin default port 8333. These servers are up all the time and very fast. Hidden services are end-to-end encrypted so the risk of MITM between nodes does not exist. Also, if you run bitcoin in such a way with onlynet=tor enabled in config, nobody listening your wire can have a slight clue that you use bitcoin. I don't mean to disparage the contribution of people who are running Bitcoin hidden service nodes. I think that's a very useful contribution. I do want to question three things about the benefits of doing so. First, the security of hidden services among other things relies on the difficulty of an 80-bit partial hash collision; even without any new mathematical insight, that isn't regarded by NIST as an adequate hash length for use past 2010. (There has been some mathematical insight about attacking SHA-1, which Tor hidden service names use, although I don't remember whether any of it is known to be useful for generating partial preimages.) Tor hidden service encryption doesn't consistently use crypto primitives that are as strong as current recommendations, though I think they matched recommendations when the Tor hidden service protocol was first invented. That means that the transport encryption between a hidden service user and the hidden service operator is not as trustworthy in some ways as a modern TLS implementation would be. Second, a passive attacker might be able to distinguish Bitcoin from other protocols running over Tor by pure traffic analysis methods. If a new user were downloading the entire blockchain from scratch, there would be a very characteristic and predictable amount of data that that user downloads over Tor (namely, the current size of the entire blockchain -- 23394 megabytes as of today). Not many files are exactly that size, so it's a fairly strong guess that that's what the user was downloading. Even submitting new transactions over hidden services might not be very similar to, say, web browsing, which is a more typical use of Tor. The amount of data sent when submitting transactions is comparatively tiny, while blockchain updates are comparatively large but aren't necessarily synchronized to occur immediately after transaction submissions. So maybe there's a distinctive statistical signature observable from the way that the Bitcoin client submits transactions over Tor. It would at least be worth studying whether this is so (especially because, if it is, someone who observes a particular Tor user apparently submitting a transaction could try to correlate that transaction with new transactions that the hidden services first appeared to become aware of right around the same time). Third, to take a simpler version of the attacks proposed in the new paper, someone who _only_ uses Bitcoin peers that are all run by TheCthulhu is vulnerable to double-spending attacks, and even more devious attacks, by TheCthulhu. (You might say that TheCthulhu is very trustworthy and would never attack users, but that does at least undermine the decentralization typically claimed for Bitcoin because you have to trust a particular hidden service operator, or relatively small community of hidden service operators, not to attack you by manipulating your view of the blockchain and transaction history.) Using Bitcoin over Tor hidden services might be a good choice for most users today who want their transactions and private key ownership to be as private as possible, but it's not free of risk, and it's probably not an appropriate long-term solution to recommend to the general public without fixes to some of the technologies involved! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUTtX0AAoJEIN/pSyBJlsRbQUIALs7C0PRT2IJa8OO5x+fVk9D 7bqL+1K1Aom62wyhBtkII2Z3/5yE6vMVmNgWfbn/oTfp1nLTmt1dGsJ7ZJmBwOXB 6tTchxeaphZzkTxGTAalE/TQ3Hdtpp0J3Z7kvXFWCyEnDfpAOc0ALF0sDNj56fGp g9v5oifUBtu5s8XC6i+v+UkiKdZXEgZlvwHCPBTsJwNcSr64VYVu9m6bR45izfkI RWH7dHsgxcnDsHaMd5p7oN4HFU8Gm2yooGHFdrHl5lNGtyfCHF2Jf7EnYBnzbHUN B7J+NRR2wkj2WT6kTR4yRVr1vgeK0u66g0FPaRpMFinDT/h1MpKs5Rke15h6CKI= =gHtN -END PGP SIGNATURE- -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or
Re: [tor-talk] Bitcoin over Tor isn’t a good idea (Alex Biryukov / Ivan Pustogarov story)
On 10/28/14, s7r s...@sky-ip.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seth, Totally agree about undermining decentralization by having to trust a single provider. Nobody recommended that, the addresses were for informative purpose only, to be used in parallel with other nodes run by other operators / organizations. No user is forced to use exclusively peers run by the same operator. An user is free to add as many hidden nodes for bootstrapping as desired. Once connected to a node that node will exchange information about other nodes and so on. I agree the hidden services are old. There is a nice proposal, hopefully it will be analyzed more and implemented as soon as possible. Do you have a link to what you are thinking of? What comes to my mind just now is DJB's black box (i.e. make it simple for the developer to do the right thing): http://nacl.cr.yp.to/ http://rdist.root.org/2009/07/14/nacl-djbs-new-crypto-library/ -- Banned for life from Debian, for suggesting Debian's CoC is being swung in our faces a little too vigorously. -- 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
