Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Pirate Bay's Plans To Encrypt the 'Net

timothy posted about 6 years ago | from the pretty-ned8bdrnki(bdr## dept.

The Internet 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."

cancel ×

297 comments

But all decent pirating services... (5, Insightful)

joleran (1259908) | about 6 years ago | (#24150175)

Should already be encrypted. If they weren't, they were being pretty careless.

Re:But all decent pirating services... (3, Interesting)

wstfgl (912433) | about 6 years ago | (#24150233)

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...

Re:But all decent pirating services... (5, Insightful)

Lally Singh (3427) | about 6 years ago | (#24150369)

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.

Re:But all decent pirating services... (4, Interesting)

CrazedWalrus (901897) | about 6 years ago | (#24150527)

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. :-)

Re:But all decent pirating services... (4, Informative)

v1 (525388) | about 6 years ago | (#24150621)

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.

Re:But all decent pirating services... (3, Insightful)

Dracker (1323355) | about 6 years ago | (#24150765)

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.

Re:But all decent pirating services... (2, Interesting)

CastrTroy (595695) | about 6 years ago | (#24150817)

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 communication of non-sense information between you and a bunch of random parties. That way they wouldn't be able to tell who you were really communicating with, and who you were just sending random garbage to.

SSL over Tor with Pivroxy (0)

Anonymous Coward | about 6 years ago | (#24150195)

What more do we need?

Re:SSL over Tor with Pivroxy (5, Insightful)

JPribe (946570) | about 6 years ago | (#24150211)

More people running TOR servers...

Re:SSL over Tor with Pivroxy (0)

Anonymous Coward | about 6 years ago | (#24150235)

and private trackers are going to love that..

I know plenty that already block users through using tor..

Re:SSL over Tor with Pivroxy (5, Interesting)

WingedHorse (1308431) | about 6 years ago | (#24150335)

Won't work like that, I'm affraid.

When Finland started "Filtering the internet to protect the children" and among other sites filtered a website that criticized quality of the work that police was doing with the internet censoring it got difficult for me to get to that site by using TOR. Why? Because with so many tor servers in Finland it often took several extra reloads to get a server outside the borders of the censorship.

The last thing I want to do now is add more anonymous and uncontrolled hops, which could be to servers in countries that watch the traffic too closely or even ran by such governments. Every hop is an extra chance to MitM attack. Unless I first aquire the Public Key directly in which case anyone monitoring already knows what site I'll access to and makes TOR needless.

Or is there something I have missed?

Re:SSL over Tor with Pivroxy (2, Informative)

aaaaaaargh! (1150173) | about 6 years ago | (#24150523)

Assuming that the encryption cannot be broken, what difference does it make when the traffic goes over an additional node run by a malicious attacker? What matters is the first node and the exit node, all other traffic is encrypted and anonymized. AFAIK, the more hops, the better, except that traffic becomes slower. Or am I missing something?

There are other vulnerabilities to TOR's anonymity based on traffic analysis, and of course the most widespread problem is that users don't anonymize their applications or erroneously assume that the exit node is not malicious.

he last thing I want to do now is add more anonymous and uncontrolled hops, which could be to servers in countries that watch the traffic too closely or even ran by such governments. Every hop is an extra chance to MitM attack.

Or is there something I have missed?

Re:SSL over Tor with Pivroxy (1)

somersault (912633) | about 6 years ago | (#24150745)

Assuming that the encryption cannot be broken [...] Or am I missing something?

Yes.

Re:SSL over Tor with Pivroxy (4, Interesting)

Shadow-isoHunt (1014539) | about 6 years ago | (#24150475)

You cannot trust the exit node in tor, it's still plain text most of the time and you're vulnerable to MITM attacks. If you look at your traffic on tor you'll find lots of sneaky shit going on like ad replacement, swapped out cookies, and there's certainly more curious people out their watching the node traffic out of curiosity with wireshark/driftnet/snort than just me. Mind you I behave and I'm simply curious, where as most of the nodes out there will attempt to profit in some way from your ignorance that gets perpetuated repeatedly throughout the internet.

Not to be a dick, just sayin'.

Re:SSL over Tor with Pivroxy (0)

Anonymous Coward | about 6 years ago | (#24150749)

Encryption like SSL protects you from the types of actions you described.

Re:SSL over Tor with Pivroxy (1)

bconway (63464) | about 6 years ago | (#24150871)

Did you read the parent post? Communication from the exit node to the end point remains unencrypted, and exit nodes can't be trusted. SSL between nodes doesn't help, you aren't magically connecting to an unencrypted service with SSL.

Re:SSL over Tor with Pivroxy (2, Interesting)

jetxee (940811) | about 6 years ago | (#24150557)

SSL over Tor with Pivroxy What more do we need?

More exit nodes in the Tor network controlled by the governments and malicious parties (directly or indirectly with hidden remote administration tools). And then all we, Tor users, are screwed. The last hop is unencrypted and usually contains some information which helps to identify the user.

ISPs react (3, Insightful)

Ted Freeman (1319075) | about 6 years ago | (#24150201)

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.

Re:ISPs react (5, Insightful)

Jedi Alec (258881) | about 6 years ago | (#24150599)

Isn't that the point? If all your traffic is encrypted, how is the ISP supposed to tell what is what?

Re:ISPs react (1)

Ted Freeman (1319075) | about 6 years ago | (#24150693)

From the article

newer traffic management solutions can identify P2P transfers by simply looking at the patterns of your uploads and downloads and not at the individual data packets

The packet headers will not be encrypted of course, along with the size, source, destination and frequency and number of packets transmitted, that's probably enough.

What... wait... IPsec, is that you? (4, Insightful)

cyb97 (520582) | about 6 years ago | (#24150203)

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

oh wait, without the standardisation of course.

Re:What... wait... IPsec, is that you? (1)

hitmark (640295) | about 6 years ago | (#24150223)

and without all the config hassle...

Re:What... wait... IPsec, is that you? (4, Informative)

Anonymous Coward | about 6 years ago | (#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:What... wait... IPsec, is that you? (4, Informative)

Zarhan (415465) | about 6 years ago | (#24150633)

I'm wondering how much overlap there will be compared to Better-than-nothing-security [ietf.org] .

Re:What... wait... IPsec, is that you? (2, Insightful)

Threni (635302) | about 6 years ago | (#24150653)

> 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.

Re:What... wait... IPsec, is that you? (3, Insightful)

Kent Recal (714863) | about 6 years ago | (#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.

IPSec + no MTU/NAT issues + zeroconf (5, Informative)

Zarhan (415465) | about 6 years ago | (#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..

Re:IPSec + no MTU/NAT issues + zeroconf (1)

ArikTheRed (865776) | about 6 years ago | (#24150635)

WTF?

Solved problem! (2, Interesting)

Anonymous Coward | about 6 years ago | (#24150763)

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-middle attacks?

Yes. However, note that this would require interception of traffic which is much more costly than sniffers in parallel and legally more troublesome for the attacker. Additionally, userland crypto protocols could be extended to include the shared secret in their certified handshakes, thus giving them MITM-proof security which includes the TCP layer.

Q: Doesn't this break NATs?

NATs rewrite the IP addresses and port numbers in the packets, which we don't include in our MAC protection, so everything should work. If the NAT happens to rebuild the whole packet, the OTCP offer in the SYN packet will be removed. In this case we loose OTCP but, most importantly, we don't break any users.

NATs which monitor the application level and try to rewrite IP address in there will be broken by this. However, the number of protocols which do this is small and clients may be configured by default not to offer OTCP when the destination port number matches one of these protocols (IRC and FTP spring to mind). This is a hack, but the downside to users of OTCP must be as small as possible.

Q: So can't I break this by filtering the offer from the SYN packet?

Yes. Application level protocols could be extended to sense this downgrade attack and stop working, but mostly see the points above: it's much more expensive to do this since it needs to be done in the router and it's legally more troublesome for the attackers.

Q: Won't this take too much time?

It's additional CPU load, certainly. The Crypto++ and OpenSSL benchmarks suggest that a full core should be able to handle this at 1 Gbps. Most servers don't see anything like that traffic. Maybe more concerning is the DDoS possibility of using ObsTCP to add additional load via a SYN flood. Since we're using curve25519, no computation is needed to answer a SYN. The shared key computation only occurs when the handshake completes and an optimised curve25519 can do that in about 250us (2.33GHz Core2)

Q: What about my high-performance network?

Obviously this makes no sense for "inside the datacenter" and other, high-performance networking environments. ObsTCP is disabled by default for destinations in the private IP address ranges and root can disable is for any CIDR range.

Q: But then I'm wasting CPU time and packet space whenever I'm running SSH or HTTPS

Right. Userland can turn off OTCP using a sockopt if it wishes, or it could just not enable itself for the default destination ports which these protocols use. (Again, that would be an ugly intrusion of default port numbers into the kernel, but this idea wasn't that beautiful to begin with.)

Re:What... wait... IPsec, is that you? (0, Offtopic)

KinkyClown (574788) | about 6 years ago | (#24150503)

That almost the same as ODF and OOXML, right?

Pirating or not (4, Insightful)

BiggerIsBetter (682164) | about 6 years ago | (#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.

Re:Pirating or not (5, Interesting)

Hal_Porter (817932) | about 6 years ago | (#24150345)

Makes you wonder what the internet would look like if you had real privacy actually. Hope you like /b/

Re:Pirating or not (-1, Troll)

Anonymous Coward | about 6 years ago | (#24150545)

I like /b/ just fine namefag

IPSEC? (2, Informative)

Wonko the Sane (25252) | about 6 years ago | (#24150217)

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

Re:IPSEC? (4, Insightful)

LarsG (31008) | about 6 years ago | (#24150491)

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.

Crypto Barbie: "IPSEC IS HARD" (5, Insightful)

argent (18001) | about 6 years ago | (#24150905)

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.

Re:IPSEC? (1)

Lord Bitman (95493) | about 6 years ago | (#24150505)

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.

There's a apretty-ned8bdrnki(bdr## dept? (1)

YourExperiment (1081089) | about 6 years ago | (#24150227)

This would also be a boon to anyone else concerned about civil liberties, presumably. I can't imagine many governments being particularly happy to see such a plan come to fruition.

you think you can defeat govt that easy? (4, Insightful)

circletimessquare (444983) | about 6 years ago | (#24150229)

reply:

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

Re:you think you can defeat govt that easy? (1)

ozamosi (615254) | about 6 years ago | (#24150839)

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 (5, Informative)

nahdude812 (88157) | about 6 years ago | (#24150241)

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:Man in the Middle (1)

uigin (985341) | about 6 years ago | (#24150273)

Very true. But with the level of criminal activity in the form of botnets, etc., I'd be happy to at least have that half way solution to begin with.
(and yes I know most traffic doesn't travel through hijacked bots but there are plenty of other dodgy nodes out there)

Re:Man in the Middle (1)

MoogMan (442253) | about 6 years ago | (#24150425)

A perception of security is generally far worse than no security at all.

It wouldn't be far fetched to imagine a bespoke MITM proxy that decrypts all connections and logs them to a backend.

Re:Man in the Middle (1)

Metorical (1241524) | about 6 years ago | (#24150397)

Perhaps I'm missing something and you're making a valid point but...

Doesn't public/private keys solve this problem. Encrypt with public key but can only decrypt with private key. Share public keys so anyone can send you an encrypted message but only you can decrypt it.

Re:Man in the Middle (1)

LarsG (31008) | about 6 years ago | (#24150555)

Excellent, grasshopper.

Now for the next step: how to share said keys in an efficient way.

Re:Man in the Middle (0)

Anonymous Coward | about 6 years ago | (#24150587)

the public keys could be exchanged in the handshake.
it dosent matter if the man in the middle gets them since he only can use them to encrypt and not decrypt.
So i relly dont se the problem

Re:Man in the Middle (1)

LarsG (31008) | about 6 years ago | (#24150645)

Then how do you defend against the mitm substituting his own keys?

Re:Man in the Middle (3, Insightful)

aaaaaaargh! (1150173) | about 6 years ago | (#24150405)

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.

Re:Man in the Middle (5, Insightful)

LarsG (31008) | about 6 years ago | (#24150615)

The purpose of this thing is to enable regular home users to avoid the dragnet filtering that the swedes are implementing. Forging replies for every tcp/udp connection crossing the swedish border would make that filtering a lot more expensive.

Re:Man in the Middle (1)

LarsG (31008) | about 6 years ago | (#24150419)

Yes, we all know what a mitm attack is.

This is not to defend against mitm attacks targeted at specific users, this is to defend against net-wide dragnet filtering.

https? (1)

zifn4b (1040588) | about 6 years ago | (#24150455)

What about HTTPS? Couldn't an ISP do the same thing and capture personal information such as SSN's, credit card and bank account numbers and then share that information with anyone it wants to? I would imagine that once something like this is compromised at the ISP level, it would cause people to stop using legitimate services on the internet because they can't trust their ISP's.

Re:https? (0)

Anonymous Coward | about 6 years ago | (#24150553)

No! Did you mis the whole PKI thing?

ISP can't fake google's cert unless the CAs are in on the gig (quite likely, but a different attack)

Re:https? (1)

LarsG (31008) | about 6 years ago | (#24150619)

Why do you think your web browser includes root certificates?

Re:https? (1)

huge (52607) | about 6 years ago | (#24150853)

HTTPS relies on root certificates to authenticate the remote peer.

Re:Man in the Middle (1)

linzeal (197905) | about 6 years ago | (#24150465)

The US government would have to have a datacenter with encryption the size of Rhode Island to snoop on everyone.

Re:Man in the Middle (1)

ledow (319597) | about 6 years ago | (#24150501)

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.

Re:Man in the Middle (5, Informative)

Fzz (153115) | about 6 years ago | (#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.

Re:Man in the Middle (1)

Xest (935314) | about 6 years ago | (#24150539)

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 private key
- Person 2 can then communicate with person 1 using the key sent in an encrypted form

The only way I could see man in the middle working is brute force by using the public key of person 2 to encrypt strings of text until they get a match of the key sent by person 1 to person 2 that was encrypted using person 2's public key. Person 2's private key is never sent across the network and is the only thing that can decrypt the other key that was sent encrypted by person 1. At this point the key that will be used by the two has been transferred in an encrypted form and need never be transferred again after that. As such I can't see how it would be intercepted.

Is this not possible? have I missed some blatantly obvious security gap that a man in the middle attack can exploit here? I'm pretty sure I've read about plenty of encryption systems whereby a public key can only encrypt and a private key is required to decrypt the data encrypted by the public key.

Re:Man in the Middle (5, Informative)

miro f (944325) | about 6 years ago | (#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:Man in the Middle (1)

Xest (935314) | about 6 years ago | (#24150667)

Cheers for that ;) Makes sense now!

Re:Man in the Middle (2, Informative)

huge (52607) | about 6 years ago | (#24150925)

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 still provide protection against casual eavesdropper but not against ISP or government with resources to perform such an operation. Granted, it would still bury the illegitimate traffic to majority of the legitimate traffic and only way to distinguish these two from each other would be by performing MitM attack to all encrypted traffic.

Better than nothing? Definitely yes, but this still addresses only part of the problem.

Great (2, Informative)

uigin (985341) | about 6 years ago | (#24150247)

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.

Re:Great (1)

LogicallyGenius (916669) | about 6 years ago | (#24150299)

Please tell them to make every computer a webserver by using MACID + IP instead of static IP

Let's play, reinvent the wheel (-1, Redundant)

Anonymous Coward | about 6 years ago | (#24150259)

VPN Anyone?

Watt?! (3, Insightful)

LSD-OBS (183415) | about 6 years ago | (#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 :)

Uh, 10Mbps vz 3Ghz CPU (0)

Anonymous Coward | about 6 years ago | (#24150411)

Result: CPU wins.

Re:Watt?! (1)

FlyingBishop (1293238) | about 6 years ago | (#24150513)

I don't know if you've tried the IE8 beta, but it makes FF2 look like it was written in C. And unfortunately, IE* still owns the market, so we need to convert the world to firefox to make encryption a carbon-neutral affair.

FF2? (1)

Mateo_LeFou (859634) | about 6 years ago | (#24150849)

Not totally following your point. Looking "like it was written in C" is.. a bad thing?

Re:Watt?! (3, Funny)

Anonymous Coward | about 6 years ago | (#24150535)

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:Watt?! (0)

Anonymous Coward | about 6 years ago | (#24150647)

Internet Explorer ?? Firefox 3 ??
Ditch both of them and use Opera - a much better browser.
Opera had features in it a year ago that are only now in FF3 and still has useful features that neither IE or FF3 have.

Re:Watt?! (1)

LSD-OBS (183415) | about 6 years ago | (#24150675)

I used Opera exclusively back in the 5.x days. Since then I find the interface less and less agreeable, sorry (and all the features I enjoyed are becoming more standard, and are all easily available via extensions)

Re:Watt?! (1, Funny)

Anonymous Coward | about 6 years ago | (#24150717)

oh dear god the prophecy is coming true. Pirates are about to cause global warming!

quick, beg for mercy at the noodley appendage of our one true god.

Re:Watt?! (5, Funny)

lilomar (1072448) | about 6 years ago | (#24150829)

Pirates prevent global warming. Heretic.

Re:Watt?! (0)

Anonymous Coward | about 6 years ago | (#24150819)

It's OK, more pirates will bring down the temperatures anyway.

Speaking of unfinished projects (0, Offtopic)

oodaloop (1229816) | about 6 years ago | (#24150303)

TFA mentions some unfinished projects. What about the island they wanted to buy and turn into a sovereign nation? How's that one coming along?

Re:Speaking of unfinished projects (0, Troll)

cliffski (65094) | about 6 years ago | (#24150495)

you are delusional if you think thepiratebay cares about anything but this:

Ad revenue

Thats what the site is there for, not fighting for anyone freedom, or privacy, or any other bullshit that they cloak it with. The site makes a virtue out of the fact that it hosts no technically illegal files, yet it cries about bandwidth to justify its extensive ads, and the fact that it is one of the highest earning sites on the web for ad revenue.
On top of this, they trick the poor kids who love the site into buying t shirts, and even contributing to their Swiss bank account to buy a fucking island!

Hilarious.

As a major money-making organisation, I think its especially amazing that they manage to persuade their users that they are "sticking it to the man" by using the site.
thepiratebay is just a front for a large scale criminal organisation to profit from the work of musicians, TV producers, actors and software developers. If you really think that those Swedish kids that they put on TV to represent them are the ones running that site, then you are really beyond help.
Of course its all a front. And this new idea of theirs will not happen. Its designed to get headlines because headlines == traffic == ad revenue.

Re:Speaking of unfinished projects (1)

neokushan (932374) | about 6 years ago | (#24150591)

Except that they never actually intended to buy the island and made it quite clear on the site that they didn't intend on doing it.

Re:Speaking of unfinished projects (0, Flamebait)

cliffski (65094) | about 6 years ago | (#24150639)

just goes to show how ignorant the average piratebay fans are then.

I bet the guys collecting the money were in stitches.

Re:Speaking of unfinished projects (1, Interesting)

Anonymous Coward | about 6 years ago | (#24150677)

Possibly, or it may have been a testament as to who people would rather give money to - the Piratebay or the RIAA.

Re:Speaking of unfinished projects (0)

Anonymous Coward | about 6 years ago | (#24150743)

Do you have some reference or some source for all your allegations and bias?

Of course, someone is making money, I donÂt know how much or who does, I donÂt care. But clearly, there is a political agenda behind this too, and YOU are the ones saying your words, so you better back it up if anyone is going to take you seriously.

Re:Speaking of unfinished projects (0)

Anonymous Coward | about 6 years ago | (#24150795)

Well yea... too bad nobody on Slashdot cares about ethics. Fuck you all (except the guy that wrote this comment.)

Re:Speaking of unfinished projects (0, Troll)

kv9 (697238) | about 6 years ago | (#24150809)

how much are you getting to troll here? is it like per post, per amount of bullshit spewed per post? is your sound recording still working?

Fight Global Warming! (0)

Anonymous Coward | about 6 years ago | (#24150305)

TPB is obviously related to the FSM church, and this is a good thing - they are fighting global warming (and must use encrypted connections because the planet might be listening).

Obligatory (4, Funny)

Anonymous Coward | about 6 years ago | (#24150309)

Va Fbivrg Ehffvn, lbh rapelcg gur Cvengr Onl

Re:Obligatory (1)

phagstrom (451510) | about 6 years ago | (#24150521)

When I want to encrypt something I always use rot13...twice!

Re:Obligatory (1)

jps25 (1286898) | about 6 years ago | (#24150525)

Va Fbivrg Ehffvn, lbh rapelcg gur Cvengr Onl

Arrr! Tis' unbreakable aye, me parrot concurs.
Ye'll ne'er get me buried booty!

Not just about pirating (5, Interesting)

Anonymous Coward | about 6 years ago | (#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 ;)

Re:Not just about pirating (5, Funny)

Anonymous Coward | about 6 years ago | (#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:Not just about pirating (0)

Anonymous Coward | about 6 years ago | (#24150479)

OK... I can't even find a DSL line in the midwest @ 6Megs for less than $40/month. WHERE are you getting your service?

Re:Not just about pirating (2, Funny)

Atti K. (1169503) | about 6 years ago | (#24150489)

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.

Re:Not just about pirating (1)

kv9 (697238) | about 6 years ago | (#24150859)

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?

Finally! My biggest fears adressed! (0)

Thanshin (1188877) | about 6 years ago | (#24150433)

I've been thinking about this for years now.

Go a step ahead in the arms race. Start encrypting before people the control gets to an unbearable point.

This is guillotining the king when he's still trying to make the senate make remove his position's time limit.

Just knowing that this is important for more people makes me a bit happier.

Thanks for the good news. Now tell me someone is addressing how to create an internet that doesn't depend on telecom corporations and I may cry.

Clean up your act first, encrypt later. (2, Insightful)

Shados (741919) | about 6 years ago | (#24150605)

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 of the children, ban free usage of encryption!!" And then we'll be -worse- off than we are now.

Clean up your act first, THEN advocate encryption, and all will be well.

Our Governments are failing us (1)

Hackerlish (1308763) | about 6 years ago | (#24150609)

This demonstrates the sheer stupidity of our so-called Democratic Governments. Once the pedophiles, terrorizers and crooks were the only ones who needed to encrypt their work. But governments are wasting so many tax payer dollars to spy on their own citizens for no good reason, that now the citizens are turning to encryption too. Now instead of having to concentrate on a small island of encrypted comms, Government will now have to sift through a sea of it. We've got dumb and shady politicians (hey thanks for your FISA betrayal, Obama) and public servants more interested in building empires then generally protecting the people who pay their salaries (that's the taxpayer, not the politicians).

SSL (2, Interesting)

Idimmu Xul (204345) | about 6 years ago | (#24150617)

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

Re:SSL (2, Informative)

n3tcat (664243) | about 6 years ago | (#24150885)

What is being presented is supposed to operate on a totally different level of the OSI model [wikipedia.org] than SSL does.

Re:SSL (2, Informative)

n3tcat (664243) | about 6 years ago | (#24150899)

I should also note that this is why people keep comparing it to IPSEC [wikipedia.org] , as it also operates on the network level.

default part of distro (1)

spikenerd (642677) | about 6 years ago | (#24150789)

The success of this all depends on whether the major distros will accept this as part of their core set of default packages. As long as everyone has to install it manually, it will always be an ineffective toy, but if a lot of servers start supporting it (which would only happen if it's a default), then there is incentive for the clients to use it, and in turn more incentive for servers to do it.

How to encrypt? (1)

clone_zealot (1169891) | about 6 years ago | (#24150939)

public key: pRon
private key: RIAA

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...