Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
The Internet Encryption Privacy Security

The Pirate Bay's Plans To Encrypt the 'Net 297

Keeper Of Keys writes "According to newteevee.com, The Pirate Bay, those fun- and freedom-loving Swedes, have embarked on a project to encrypt all internet traffic, probably by means of an OS-level wrapper around all network connections, which would fall back to an unencrypted connection when the other end is not similarly equipped. The move has been prompted by a recent change in Swedish law, allowing the authorities to snoop on network traffic. This will be a boon to filesharers and anyone else concerned about authorities and trade groups' recent moves towards 'policing' network traffic at the ISP level."
This discussion has been archived. No new comments can be posted.

The Pirate Bay's Plans To Encrypt the 'Net

Comments Filter:
  • by joleran ( 1259908 ) on Friday July 11, 2008 @06:51AM (#24150175)
    Should already be encrypted. If they weren't, they were being pretty careless.
    • Re: (Score:3, Interesting)

      by wstfgl ( 912433 )
      Looks like they thought of that... FTFA:

      NewTeeVee alumn Jackson West pointed out back in March that long-planned projects like The Video Bay, the music site PlayBle and a new and secure P2P protocol have yet to be launched

      Admittedly "secure internet" would be more useful to file sharers than "secure P2P" (better plausible deniability); but if they've failed to even do the latter so far, I wouldn't hold out too much hope...

      • by aliquis ( 678370 )

        On the other hand there haven't been much reason to care since no one have been allowed to snoop at your traffic or get your contact information from your isp earlier.

      • answer two (Score:4, Insightful)

        by aliquis ( 678370 ) on Friday July 11, 2008 @08:57AM (#24151023)

        Not to forget some people would probably argue that your general privacy and freedom to talk to others with no one listening is more important than file sharing.

        Some other people would probably not since those are the people which hopes to catch some bad guys using techniques such as this one and don't care about the breach of their own privacy since they have nothing to hide them self and trust everyone to be good.

    • by Lally Singh ( 3427 ) on Friday July 11, 2008 @07:23AM (#24150369) Journal

      Yeah, but then you can tell pretty closely what they are. Port number & encrypted protocol are pretty indicative.

      Instead, encrypting the majority of traffic would make the sniffing capability moot.

      But frankly, I'd rather see them use Tor [eff.org], maybe with some optimizations for latency-critical operations.

      • by CrazedWalrus ( 901897 ) on Friday July 11, 2008 @07:47AM (#24150527) Journal

        I don't know how this would work specifically (didn't bother to RTFA), but it seems to me that the current model of connecting to application ports is broken from a privacy perspective.

        The solution is a hopefully cheaper version of setting up a vpn tunnel and using THAT to connect to the application port. That way all traffic appears to be going to the same port, regardless of service. Because it's encrypted, no DPI can be applied.

        Of course, I could just go to that site's web site and see what they advertise, assuming that most people are going there for that purpose. If I'm sniffing the user's connection at their ISP, I could also see if they're connecting to 10-20 other user sites simultaneously, which would look a lot like bittorrent.

        The advantage to using end-to-end encryption by default would be plausible deniability. If the site carries both legal and illegal content, then it would be difficult to prove that the user was downloading one or the other by simply inspecting their traffic patterns. Because encryption is used by default, the argument of "Why encrypt if you have nothing to hide" goes out the window.

        I hope this made sense. I'm still waiting for the coffee to perk. :-)

        • by Craig Ringer ( 302899 ) on Friday July 11, 2008 @09:30AM (#24151373) Homepage Journal

          The FreeS/WAN guys were working on transparent IPSec negotiation for just this reason. It prevents many types of traffic analysis, spoofing, packet injection, etc just as you want.

          They've given up because nobody cared :S

        • Of course, I could just go to that site's web site and see what they advertise, assuming that most people are going there for that purpose. If I'm sniffing the user's connection at their ISP, I could also see if they're connecting to 10-20 other user sites simultaneously, which would look a lot like bittorrent.

          But that workaround doesn't account for :

          - Hosting service that host several web sites on a single server, thus all sharing the same IP but answering to different DNS names in the HTTP request. It happens a lot, almost any of the cheap hosting service works that way.
          => You'll get multiple connections anyway, and there's no single website to check for advertised content.

          - Although there *are* bittorrent trackers written in PHP, there are a lot of people using a simple web server for the website and indexi

        • Re: (Score:3, Interesting)

          by PigleT ( 28894 )

          That way all traffic appears to be going to the same port, regardless of service. Because it's encrypted, no DPI can be applied.

          Maybe not but your local friendly government of choice could legislate something like the RIP Act and demand keys to the traffic on that one port.

          A sensible solution would be to promote the spread of IPv6 which I gather has scope for IPSEC built into the specs.

      • by v1 ( 525388 ) on Friday July 11, 2008 @08:01AM (#24150621) Homepage Journal

        most BT servers run their web server on port 80, and they always encourage users to change the default BT port to something else. As long as you offer legitimate torrents, and run https encrypted to prevent people from seeing what torrents you download, then all you know is they are running BT on a torrent on the server. If you are using encrypted BT, they can't see what it is you're downloading when you start up the torrent. Beyond knowing they're running BT, (which is still legal, for now) there's nothing more you have on them.

        • ... until you join the swarm yourself, get a list of peers from the tracker, and connect to them directly to verify that they are uploading your copyrighted content. It works for the RIAA.
      • Re: (Score:3, Insightful)

        by Dracker ( 1323355 )
        But the Pirate Bay folks are .. well .. pirates, and Tor frowns upon using high amounts of p2p bandwidth over Tor. If The Pirate Bay is going to endorse a technology, it needs to help them pirate. Freenet or I2P look like better codebases. It all comes down to how secure and convenient they want their protocol to be.
        • by xalorous ( 883991 ) on Friday July 11, 2008 @09:57AM (#24151683) Journal

          TOR is not robust enough to handle P2P traffic. PLUS IT DOES NOT HIDE THE DATA YOU ARE TRANSFERRING. This plan by TPB is designed to encrypt the traffic. A separate TOR-like plan would be required to anonymize source/destination IP's. Or a third option that does both.

          TOR was designed to help people remain anonymous and communicate safely on the web. Misusing it for illegal purposes will cause TOR to become unavailable for its original purpose, which will be sad.

      • Re: (Score:3, Interesting)

        by CastrTroy ( 595695 )
        I think something like Tor would be useful also. Because even if your communications are encrypted, they can tell a lot about you just by the people you are communicating with, even if they don't know what you are saying. Also, things like bittorrent encryption are only good for getting past your ISPs traffic handling services, and do nothing to disguise your identity from other people connected to the same swarm. Another possibility, since Tor is so horribly slow, would be to have encrypted communicatio
      • Re: (Score:2, Interesting)

        by Anonymous Coward

        Honestly, the best possible route is not this hack upon TCP or UDP (did you read the part about how it opens and closes connections while doing the handshake?), but rather an opt-in private network like anonet [anonet.org].

      • by Hatta ( 162192 ) on Friday July 11, 2008 @09:31AM (#24151389) Journal

        Tor and encryption serve orthogonal purposes. Encryption hides what you're sending, tor hides who you're sending it to.

      • TOR != encryption (Score:5, Insightful)

        by xalorous ( 883991 ) on Friday July 11, 2008 @09:43AM (#24151505) Journal

        Please don't blindly use TOR for P2P. You'll bring TOR to its knees. TOR is supported by volunteers and isn't designed for the massive load P2P would put on it. Plus, TOR only provides anonymity at the destination, and it only hides your IP. TOR does not provide encryption. Snooping at your ISP would still show all packets in the clear.

        • Re:TOR != encryption (Score:5, Informative)

          by chihowa ( 366380 ) on Friday July 11, 2008 @10:34AM (#24152151)
          Tor provides anonymity at the source, too. Your first hop is encrypted from you to the Tor network. Your ISP only sees that you are using Tor, not to whom you are connecting. The last hop's ISP can see your traffic in the clear, though. If there's identifying (or secret) information it is vulnerable at the last hop.

          But you're right, Tor is an anonymizing network, it's not end-to-end encryption.

          • Re: (Score:3, Insightful)

            by Phroon ( 820247 )

            Tor is an anonymizing network, it's not end-to-end encryption.

            With the use of Hidden services [wikipedia.org], it is. If you connect to a Hidden service on Tor, the last hop in the Tor network is to the server your connecting to and it is end-to-end encrypted.

            Tracker data and .torrent transfer would be good uses for this channel, but not the raw data. I'm surprised TPB doesn't have it already set up.

    • Why encrypt? (Score:5, Interesting)

      by slughead ( 592713 ) on Friday July 11, 2008 @10:36AM (#24152187) Homepage Journal

      Why encrypt pirate traffic?

      AFAIK, they "get you" by joining the network as a peer and then writing down all the IPs that send them pieces of the torrent.

      I don't think they do it by monitoring network traffic--that would be a pain in the butt.

      It's not hard to gain access to many of these networks, and their real goal is just to slow piracy (stopping it is a little far out). All they really need to do to slow it is start suing users and the rest will run scared, like they did with Kazaa et al. Real pirates will go underground, for sure, but they wont have as much of an impact on sales as say, Napster.

      • Re: (Score:3, Interesting)

        by joleran ( 1259908 )
        Because the serious pirating networks are very much personal-friend invite-only. The only way to break a group like that, other than from the inside by a betrayal, is if they didn't use encryption. The stream of information goes from crack group, FXP to scene release, ultra-private trackers (as above), private trackers (invite only, more lax on how they let users invite), semi-private (registration required), and public.
        • Re: (Score:3, Interesting)

          by nexuspal ( 720736 )
          There are other routes as well, such as crack group-->FXP to scene release-->Other Routes...
  • ISPs react (Score:2, Insightful)

    This will lead to governments putting pressure on ISPs to block all P2P traffic. Say goodbye to downloading Linux or other software P2P once P2P clients default to encryption.
  • by cyb97 ( 520582 ) <cyb97@noxtension.com> on Friday July 11, 2008 @06:59AM (#24150203) Homepage Journal

    Sounds like a poor man's implementation of IPsec to me...

    oh wait, without the standardisation of course.

    • by hitmark ( 640295 )

      and without all the config hassle...

      • by Anonymous Coward on Friday July 11, 2008 @07:51AM (#24150559)

        There is little to no config hassle if you use IPSec with opportunistic encryption. IPSec tunnels through UDP if there is NAT on the way, so that isn't a problem either. The trouble with IPSec is that it only does opportunistic encryption with DNSSec for key management, and that is not deployed. The PirateBay's solution to key management however is not to use any, so their solution only helps against passive eavesdropping. I'm not impressed.

      • Re: (Score:2, Insightful)

        by Threni ( 635302 )

        > and without all the config hassle...

        If you're expecting end users to do anything, then anything more complicated than `pick a password` and then later `enter the password` is not going to work. Even then, you'll have to deal with people forgetting passwords.

      • by Kent Recal ( 714863 ) on Friday July 11, 2008 @08:36AM (#24150857)

        Parent is spot on.

        IPSEC *may* be very well engineered but few of us would want to touch it even with a 10ft pole. Especially those of us who *had* to work with it in the past.
        It should be possible to implement IPSEC without the warts. Hell, IPSEC could be zero-configuration out of the box (linklevel encryption only) with only minimal configuration for peer certificates.

        Good Crypto doesn't have to be painful, see OpenSSH, OpenVPN (commonly chosen instead of IPSEC), GnuPG.

        I just don't see what this has to do with P2P at all? Solution looking for a problem?
        When the ISPs can't sniff our traffic anymore they'll just connect to the trackers and look at the offerings.

        But then I again I never understood the legal fuzz about P2P in first place.
        To me the key is plausible deniability. Store your shared content on an encrypted drive and that's it.

        • by IgnoramusMaximus ( 692000 ) on Friday July 11, 2008 @09:24AM (#24151303)

          I concur.

          Having to set up some corporate VPNs in the past, I cannot even fathom why anyone in their right mind would choose IPsec over, say, OpenVPN, other then being forced into it by some idiot vendor or a moron manager. The difference in complexity, amount of work on the part of the network designer and sysadmins is just astronomically different between the two solutions.

          From first-hand experience I can only confirm that IPsec is for masochists. Anyone I know who ever tried to deploy the thing does only so once.

          Also note that more convoluted and difficult to control a security solution is, more chances of security vulnerabilities, both from the perspective of possible errors in design and implementation of such complex schemes, but also (more likely in practice) from the perspective of faulty deployment by people who do not have time to parse word by word 300 page deployment manuals bristling with obscure acronyms and arcane cryptography concepts.

          • Re: (Score:3, Informative)

            I setup a fixed VPN for about 40 networks using IPSec. It wasn't terribly painful, but I did go with a Hub and spoke configuration instead of a full mesh.

            I use an IPSec with L2TP network at my office all the time. We have a proper CA and certificates issued to each of the mobile computers. took about 2 hours to setup.

          • Re: (Score:3, Informative)

            by MikeBabcock ( 65886 )

            I'm obviously a masochist. IPSec is easier to deploy than SMTP service, or a properly configured Apache+PHP server. IPSec is much easier to design than a good firewall, or a decent routing architecture, or DNS systems. Obviously you haven't worked enough with other major Internet protocols.

            Last I checked, it takes me about 15 minutes, including the download time to configure a strong Openswan connection between two machines using IPSec. Download, open each machine in separate SSH sessions, copy and pas

    • by Zarhan ( 415465 ) on Friday July 11, 2008 @07:12AM (#24150291)

      Not really, from their site [tfr.org]

      The goal of transparency to the transport layer means that the user will not have to configure anything, just install the encryption software and go. It also makes sure that encrypted traffic will travel over IP carriers without trouble (except in the case of mandatory transparent proxying). Current IP-transport encryption using tunneling or IPSec do not have the same property. Many low-cost ISPs filter IP protocols and TCP/UDP ports to block encypted traffic and there is always a cost to the user in configuring key-exchange, NAT-traversal and such. Anonymity can be provided by existing IP-anonymizing networks such as tor and i2p since the encryption is transport-independent.

      So they are planning to roll out zeroconf IPSec that doesn't NEED to have specific support for NAT traversal. Now, "NAT Traversal" technically just means UDP encapsulation (which in turn results in all fancy MTU problems).

      It seems that they are only interested in encrypting the TCP/UDP payload, with key negotiation happening at the start of the session (SYN/ACK packets for TCP, and as a completely separate negotiation with UDP).

      If they can go with this, I sure hope they write an informative RFC..

      • WTF?
      • Solved problem! (Score:2, Interesting)

        by Anonymous Coward

        Better yet, they could find use for an existing proposal, complete with code: OTCP [google.com]. It transparently encrypts TCP sessions in a way that would defeat Comcast's (and China's) eavesdropping/RST forging; if they wanted to defeat OTCP, they'd have to intercept and rewrite all SYN packets, which is a lot more burdensome. It can't guarantee perfect security, but perfect security is mutually exclusive with providing full backwards compatibility with the existing Internet.

        FAQ:

        Q: Can't this be broken by man-in-the-m

  • Pirating or not (Score:5, Insightful)

    by BiggerIsBetter ( 682164 ) on Friday July 11, 2008 @06:59AM (#24150205)

    I can't see a downside from a user perspective, and the only Govt/ISP/etc justifications not to do this are an invasion of privacy (packet headers could be used for QoS, etc). It's like, I dunno, posting all your mail in an sealed envelope instead of on a postcard - you can still put an economy or airmail sticker on it, it just means the postman can't (easily) read your message anymore.

  • IPSEC? (Score:2, Informative)

    Doesn't this problem already have a solution [openswan.org]?

    • Re:IPSEC? (Score:4, Insightful)

      by LarsG ( 31008 ) on Friday July 11, 2008 @07:42AM (#24150491) Journal

      How many users do you know that (a) even knows what dns is (b) controls the dns name for their ip (c) is able to configure said dns to include their public key?

      OE works fine for geeks, but is too heavy if the goal is to get average home users encrypted.

      • You're complaining about shortcomings in implementation. That's a general problem with crypto... crypto geeks don't care about iser interfaces. RSA goes back to 1977, and we still don't have good PGP/GPG support in most email clients. The solution is not to invent a new protocol, it's to invent a new user interface that's compellingly easy. SSL is a pain in the neck... except when you're using it in a web browser it's almost invisible, and SSH bootstraps from it to make something that's much easier to set up than SSL telnet.

        Yes, Crypto Barbie, if TPB doesn't at least make it possible to use IPSEC as the encryption layer (whether they have a workaround for ISPs that block IPSEC or not) they're not part of the solution.

    • I was only half-surprised that this wasn't already mentioned. But then, didn't they say something like they expected most internet traffic to be encrypted using their system by 1998 or something? Such epic failure, it's probably safe to ignore them.

  • reply:

    "pirate bay has become a haven for child pronographers. shut it down"

    • by ozamosi ( 615254 )

      I wonder if the demonstrations against the Swedish government, which mostly have been peaceful except for DoS attacks against the government's web servers when the FRA law was approved, would continue to be peaceful if TPB was shut down...

  • Man in the Middle (Score:5, Informative)

    by nahdude812 ( 88157 ) * on Friday July 11, 2008 @07:07AM (#24150241) Homepage

    Without preshared keys, this is vulnerable to a man in the middle attack. Your ISP or the government's spies or whoever simply intercept your communications with the other peer at the time of hand shaking and key exchange, and hands their own encryption information to both parties. Decrypt each message, and encrypt it for the other party before sending it down the line.

    This protects against casual snooping, but it completely fails to account for the level of involvement that domestic spying already suffers from.

    • Re: (Score:3, Insightful)

      I'm not sure, but as it stands there seems to be an even simpler attack. Mallory, the man in the middle, just makes sure that when Alice establishes the initial, unencrypted connection to Bob, Bob's reply is forged to indicate that he doesn't support encryption. As a result, all traffic will be unencrypted.
    • by ledow ( 319597 )

      The only "defences" you could have against such MITM attacks would be either chains of trusted keys for every site that uses the system (a hefty burden and a central repository of trusted keys makes it the main target for attack, either DoS or infiltration) or: have sites supply their public key information via DNS or similar and have clients cache it, which is easily spoofed, but at least you'd know when something "changed". A bit like SSH's authorized_keys.

      • You could just use SSH to tunnel traffic to the destination. If you use DNS 'TXT' records to publish the public key then you should know that you're talking to the correct machine, except that you'd need a way to identify machines that have no DNS record.
    • Re:Man in the Middle (Score:5, Informative)

      by Fzz ( 153115 ) on Friday July 11, 2008 @07:43AM (#24150511)
      Yes, anonymous public key exchange is vulnerable to a man-in-the-middle attack, unless you use something like the Interlock Protocol [wikipedia.org], which is probably a bit heavyweight to use for all connections.

      But what this does do is tilt the balance of power against the eavesdropper. It prevents passive eavesdropping attacks - for example it prevents anyone recording all traffic and then after-the-fact deciding what they want to decode.

      Anyone wanting to decode your traffic is forced to be an active adversary, and this makes them detectable, which means they won't do it all the time because there'd be a huge outcry. No more mining all the traffic that passes on internet backbone links - you could tell when the first ISP put an eavesdropping box into their network, and switch to another ISP, which would strongly discourage anyone from doing this in the first place.

      It's much more expensive to be an active man in the middle for all traffic - the best bet would be to downgrade traffic by pretending the other end didn't support the option. Even this isn't cheap. To leave the traffic encrypted and intercept it all would require a ridiculous number of public key accelerators cards.

      In the end, it doesn't stop anyone eavesdropping if they suspect one particular person, but it does make such interception detectable if you know what you're doing, and it does stop them eavesdropping all traffic in the hope of hearing something incriminating.

    • by Xest ( 935314 )

      I've got to admit cryptography isn't my greatest strength so I could well have misunderstood here but I thought you could handle it as follows-

      You have a public key system to transfer the keys for the encryption system used for the main transfers, the public key can decrypt in such a way that only the private key can decrypt. So:
      - Person 1 takes person 2's public key and encrypts their transfer encryption/decryption key with it
      - Person 2 decrypts person 1's key encrypted with his public key using his privat

      • Re:Man in the Middle (Score:5, Informative)

        by miro f ( 944325 ) on Friday July 11, 2008 @08:04AM (#24150627)

        The main problem is in step 1.

        - Person 1 takes person 2's public key and encrypts their transfer encryption/decryption key with it

        the big problem with public key cryptography is that you get a public key from person 2, how do you know this public key is actually from person 2 and not from person 3 trying to listen to the conversation? If there's a person listening in the middle they can intercept the traffic on both ends and replace each other person's public key with their own. That way they can pretend to be person 1 to person 2, and pretend to be person 2 to person 1.

        It makes it more difficult, but it's still not impossible, to snoop on that traffic.

        It's the delivery of the public key from person 2 and person 1 that is the biggest problem with public key cryptography, and a problem which certificates and Certificate Authorities have mitigated (to an extent). But for the greater Internet, it's a more difficult proposition to give everyone certificates.

    • Re: (Score:3, Informative)

      by huge ( 52607 )

      You nailed it.

      Pre-shared keys, root certificates and and PGP-like key signing aren't likely to scale to truly ubiquitous encryption.

      Any system that wants to provide ubiquitous encryption that isn't susceptible to man-in-the-middle attacks needs to either implement chain of trust or to overcome the problem in some completely different manner.

      In order to ubiquitous encryption to really fly, we need similar break through in authentication as public-key encryption was in cryptography.

      Like you said, this would s

  • Great (Score:2, Informative)

    by uigin ( 985341 )

    With a popular site like Pirate Bay behind it. This might actually catch on. If we all had to use an encrypted protocol to communicate with Google all internet traffic would quickly switch to that format.

  • Watt?! (Score:3, Insightful)

    by LSD-OBS ( 183415 ) on Friday July 11, 2008 @07:13AM (#24150301)

    If several million people all started encrypting all of their traffic, there's gonna be a whole lot more CPU usage and therefore more power consumption going on. ThePirateBay, think of the penguins!

    (Come to think of it, the consumption increase might be offset by firefox 3 raping CPUs less than firefox 2 used too :)

    • Re: (Score:3, Funny)

      by Anonymous Coward

      might be offset by firefox 3 raping CPUs less than firefox 2 used too

      My CPU is brand new so would that be statutory rape?

    • Re: (Score:3, Interesting)

      by Woy ( 606550 )

      That sounds good but its just not true. I run on encrypted root and home and there is no noticeable performance difference, even in big file copies. Network encryption is very very little work for the cpu.

  • Obligatory (Score:4, Funny)

    by Anonymous Coward on Friday July 11, 2008 @07:14AM (#24150309)

    Va Fbivrg Ehffvn, lbh rapelcg gur Cvengr Onl

  • by Anonymous Coward on Friday July 11, 2008 @07:16AM (#24150325)
    For over 2 years I have been encrypting my internet connection using a roll-my-own solution. I trust my ISP implicitly - they are one of the few good guys left in the ISP arena. I don't trust my government.

    The sad thing is I don't even have anything to hide. But I detest the idea that someone, somewhere, might be monitoring what I'm doing. I use an anonymous email service with PGP encryption, I do all my browsing over a VPN connection to a (cheap) VPS server in another country. For added protection I can then tunnel using SSH to another server in another country which then uses tor to make my final connection.

    Security is cheap (the whole setup probably sets me back around $50/mo including my 8mbit dsl line), but it just requires the time, persistence and knowledge to set it up in the first place. If an end-to-end solution can be built-in to the OS AND we can be certain as can be there are no back doors, then this can only be a good thing.

    For those who in the meantime who want to protect themselves but are not too sure where to begin, get yourself a cheap VPS (hundreds of providers out there), set up OpenVPN and off you go. You can even use SSH to tunnel a SOCKS connection for an easier option. I would suggest OpenVPN as a starting point though, as it makes it easier to expand later, e.g. tunneling an SSH connection to another server through the VPN, which can then connect to tor running on localhost on the second machine. Should your connection be intercepted at the ISP level (the most likely?) then they'll have a double-encrypted tunnel to deal with, and then probably an ssl-encrypted https stream inside that as well if you're careful about where you surf.

    Anonymous Coward for obvious reasons ;)
    • by Anonymous Coward on Friday July 11, 2008 @07:31AM (#24150431)

      Hi Jeff. I've been archiving copies of that porn site you started with your girlfriend. Cool security setup you've got though. Glad its working out. Tor exit node campers ftw!

    • Re: (Score:3, Funny)

      by Atti K. ( 1169503 )

      For over 2 years I have been encrypting my internet connection using a roll-my-own solution. I trust my ISP implicitly - they are one of the few good guys left in the ISP arena. I don't trust my government.

      China or something? Oh, no, wait, you must be from the US!

      The sad thing is I don't even have anything to hide. But I detest the idea that someone, somewhere, might be monitoring what I'm doing. I use an anonymous email service with PGP encryption, I do all my browsing over a VPN connection to a (cheap) VPS server in another country. For added protection I can then tunnel using SSH to another server in another country which then uses tor to make my final connection.

      Do you fully trust your VPS provider? A VPS is even easier to be snooped onto than a good-ol' iron server in some datacenter, imho.

      • by kv9 ( 697238 )

        A VPS is even easier to be snooped onto than a good-ol' iron server in some datacenter, imho.

        where do you think the VPS is located? in a magic teapot?

        • Re: (Score:3, Interesting)

          by Atti K. ( 1169503 )
          Let's suppose I host VPSs on some big iron. While each of my VPS customers has root on their own VPS, I have root on the VPS host. Can I easily snoop on their network traffic, their files on the VPS, etc?

          Yes.

          Now let's suppose my customer rents the whole big iron as it is, they do whatever they want on it. They have root on it, I don't. Can I snoop on their network traffic? Yes I can, though it's not that trivial like with the VPS. Can I take a look at their files? I could, but not that easily. I guess t

  • i know it shouldn't be that way but...the world isn't as it should be. If someone wants to start encrypting anything and everything, including legitimate usages without heavily sensitive information (which is fine and dandy and helps privacy, so its all good and fine), don't start associating it with people who DO have something to hide.

    TPB is doing a huge disservice now. The idiots up there will automatically be like "SEE SEE SEE ?!?!?! Encryption == Piracy, pirates download porn, porn == child porn, think

    • Re: (Score:2, Interesting)

      I'll use the Larry Flynt defense here: by protecting pirates' (and for all it matters terrorists' and pedophiles') right to use crypto, you de facto protect yours.

  • SSL (Score:3, Interesting)

    by Idimmu Xul ( 204345 ) on Friday July 11, 2008 @08:01AM (#24150617) Homepage Journal

    Surely what they're proposing is basically SSL, everywhere, if a handshake shows that they support it?

  • This already exists; furthermore, it's been around for years. It's called Freenet: http://en.wikipedia.org/wiki/Freenet [wikipedia.org]

    Here in Buenos Aires, Argentina I use a local version:
    http://www.buenosaireslibre.org/ [buenosaireslibre.org]

  • What about Anonet? (Score:3, Interesting)

    by Anonymous Coward on Friday July 11, 2008 @09:04AM (#24151103)

    There's a project called Anonet [anonet.org] that has developed a similar wrapper infrastructure.

    Anonet [anonet.org] is a "virtual Internet" that utilizes OpenVPN [openvpn.org] and Quagga [quagga.net] to provide a layer of anonymity and deniability on top of the Internet. It uses a chaotic yet cooperative routing scheme which allows any one to use any IP address while still maintaining their existing Internet connection.

    It has everything on it that the Internet does: torrent trackers, web servers, FTP servers, DNS infrastructure, PGP keyservers, IM, IRC, streaming audio, game severs, etc. All Internet-aware applications should work fine as Anonet [anonet.org] is simply an addition to your operating system's routing table.

  • This will have approximately zero benefits. As many users have already pointed out, such a system is still vulnerable to interception, and if you think the NSA will have trouble cracking commercial encryption, you're just wrong. But more to the point, whether or not traffic is encrypted really doesn't matter. ISPs are perfectly capable of filtering and suppressing traffic without any idea of the content of the packets in question simply by analyzing the pattern of traffic. For example, a BitTorrent connec
  • Its needed (Score:4, Insightful)

    by Mick Malkemus ( 1281196 ) on Friday July 11, 2008 @09:24AM (#24151305)
    If we don't start encrypting our activities on the Net, be prepared for increased government intervention in everything we do. Here in Latvia, if you are caught with one illegal song, your entire computer is confiscated. Encryption makes sense.
  • This projects has been worked on for years now. I never read their papers, so I can't comment on the technical side, but they surely designed it for decentralization and anonymity:
    http://gnunet.org/ [gnunet.org]

  • IPv6 and IPsec (Score:4, Informative)

    by c_g_hills ( 110430 ) <chaz&chaz6,com> on Friday July 11, 2008 @11:56AM (#24153415) Homepage Journal

    This is yet another problem solved with IPv6, for which IPsec support is mandatory. RFC 4025 provides a method for opportunistic encryption between hosts using keys stored in DNS (type "IPSECKEY").

    The implementation is simple:- when initiating a connection, look up the IPsec key of the destination using the IPSECKEY record of the destination address in the reverse dns zone (ip6.arpa).

    I think Sweden's law is actually a good thing. The more governments and/or companies that are snooping on internet traffic, the more encouragement it provides for people to use encryption.

The shortest distance between two points is under construction. -- Noelie Alito

Working...