secure P2P

Found this article, After the previous discussions, i thought that being out numbered
5 billion to 1, i would post it to provide some info for the many people involved in P2P.

Quote:

---

With the copyright police increasing its monitoring of popular file-sharing networks like KaZaA and eDonkey, savvy users are turning to WASTE, a new program that relies on file encryption and ad hoc networks of trusted members to escape prying eyes.What makes WASTE different from other file-swapping systems is that it has no central server. Instead it operates as a mesh in which each user connects to a few other users to form a loosely-structured P2P network. However, this group is virtually impenetrable to anyone who hasn't been specifically authorised to join the group using PKE(public/private key encryption) technology. PKE encryption in general works like this;each user has two keys---a private key and a public key. The public key can be given out to anyone, because it only allows them to encrypt a message to you. The same public key cannot be used to decrypt that message. Once you've received the message, you decrypt it with your private key, which you never disclose. WASTE uses public keys to ensure that each user is known on the network, and bona-fide. As each public key is unique, and linked to the private key stored in your copy of WASTE, there's no chance that someone can pretend to be you in order to gain access to the network. The initial setup of WASTE guides you through creating a unique username and private key, as well as automatically generating a matching public key. To be accepted onto a network of WASTE users, a member of that group has to email you their public key, which is simply a block of what looks like random letters and numbers. This is entered into your WASTE client software through the Preferences panel's Public Keys section---the same location to which you export your own public key so it can be shared with someone else. If you're not too concerned with security and are just curious, there's a database of public keys at www.s4s.ip3.com/wasteb. You'll also need to submit your public key there and wait for at least one other user to manually add your key to their system. Alternatively, you can chat to other WASTE users on IRC. Join the WASTE channel on the http;//irc2.p2pchat.net server and swap your public key with anyone who's online at the time. To connect to a network of WASTE users, enter the IP address of one user with whom you've swapped public keys into the WASTE connect box. You'll also need to open port 1337 on your firewall, which is the port used by WASTE( this is a joke on the part of WASTE creator Justin Frankel, as 1337 is hacker-speek for "leet"---shorthand for "elite") Once you've both swapped keys, you'll be accepted as a trusted member of the network and permitted to make connections to other people on the same network, because your key is automatically broadcast to the rest of the group and added into their copy of WASTE. You can brows other users' directories, search for specific files,and also chat using the WASTE chat client. Chat sessions and file swapping goes directly between the active computers rather than via the central server. When you start a file transfer it's encrypted using the fast but secure, open source "Blowfish" model to protect you from monitoring. Even 128- bit encryption is vertually crack-proof through brute-force, so you can be certain that any files you transfer, and any discussions you have with other users, are completely secure. Of course, one weakness in WASTE's security model is that it's easy for other users on the same network to get hold of your public key. If you're worried about this, simply reject other users' public keys. Remember; if both of you don't have each other's public keys, neither of you can connect and view what's on the other's computer. To do this, open Preferences, select Pending keys, then remove the tick from Auto-accept broadcasted public keys. The latest WASTE client for Windows is included on this months cover cd set. ( i will post this after posting) There's a Mac OS X client in development that allows encrypted chat and file serving but not downloading from other users( you can find it at www.hummusandpita.com/waste) A command-line Linux version is in alpha developmentat http;//grazzy.mjoelkbar.net/waste.

---

You can download WASTE here

You can also read more here

Hmmm ... they make a lot of claims. I suppose that would work best from a home system on a DSL or cable. Intalling that app on a workstation in a network would cause no end of problems, especially in one like mine that uses Kerberos/IPSec and a Certificate Server. It would probably get the workstation kicked off the network and one of use net-dudes would have to go kill a user and then clean up the mess.

Don't go passing strange keys around in someone else's network.

Having some experience in security and encryption, I find this article's explanation a bit disturbing.

If it is, as it states, a shared key community, then that means the community has and is aware of a key.

What makes KaZaa and Gnutella work is the fact that so many users are able to connect to each other.

If everyone has to have a key to access the network, suddenly the available hosts from which you can download a file is DRASTICALLY reduced.

If everyone HAS the key, then the monitoring software will as well. As is the standard, I'm sure the software will use a specific port, or allow for the specification of another port in the original negotiation, so someone who wants to monitor the communication will be able to, if they have the key.

The moral of this story...
If only a few people have the key, then there are fewer files available.
If lots of people have the key, then the monitors will as well.

Encryption that creates a separate key per connection would be one answer, but the processing overhead would probably be prohibative.

Another answer would be binary segmentation, basically jumbling the file even before it is transferred, so recombining the TCP packets would not match any signature, since it is not raw data, and not processing intensive encrypted data, but just jumbled with the key as part of the data.

Yes, that could be broken easily, and there is no easy answer, but as far as blind sniffing of packets, with some re-assembly based on ports, jumbling would be as effective.

I just perused the source for the linux version, and it is a very nice try. One obvious problem? Now that you have created a key, and that key is yours, guess what? Its yours. You can't say that someone hijacked your machine, or that they spoofed your IP. Your key is YOURS.

I'm not sure that's a great idea.

Also, once someone is accepted into the network, it broadcasts the key outward to others who, if they have the default setup, will accept connections from that key.

And since you have a unique key that identifies YOU, and each connection is, in essence, an authenticated transaction, there seems to be NO way to claim ignorance or that it wasn't you.

If you DON't accept the keys, then you are limited to a very small group of people with which to share.

*Shrug*

The idea of waste is probably a little overboard , but really it is the classic and proper response to being "attacked". The formation of "cells"/decentralization is very important and ceates a very hard target for RIAA and such as the expense/time for them to infiltrate would be very high and prohibitive.Private ftps is probably a better solution than waste, standard, less overhead, easy control of use.... Personally i was thinking of setting up a proxy in a "safe country" and charging $ for USians to make use of it. Good business idea possibly or good way to be sued into oblivion by a billion dollar company?

Quote:

---

If everyone has to have a key to access the network, suddenly the available hosts from which you can download a file is DRASTICALLY reduced.

---

Have to agree w/ u on that one.

Sound like a good prog

I can say from experience that having fewer keys out there doesnt mean less being shared. In two or three users you can easily have about 40-60gb, especially if the people are heavy downloaders. In fact I know of one user that has at least 30gb of shared material, so if you have two or three people like that, you set as far as downloads go, the main problem is influx of new material into the network, which either means someone has to buy or copy the matrial, and rip it to the hdd. WASTE isint as much overhead as you would think, I run it on a 1.5ghx Xeon with 1024Mb of RAM, along with other apps, and i hardly notice any slow down, and it doesnt bother my bandwidth either. The only noticable part is when doing the IMs, it encrypts it, sends, and verifies that the message was recieved, which only takes half a second i think. If your paranoid about the RIAA snooping onto you, WASTE is definately the way to go imho.

hi,
on the same topic APC magazine october issue has an article regarding p2p.new motherboards with built in encryption which come with bootable key.in case you dont have it hard disk is no readable.on the same magazine monthly disc you can find a waste 1.1.
have a look at www.apcmag.com if interested
have fun

I've been using the CryptoAPI top encrypt my file system. Since it isn't broadcast, and it is only dependant on your processor as to how much overhead you can afford, using a 1024bit encryption algorhythm on your filesystem makes it ALOT less likely that once then subpoena your disk, that they will have any evidence.

Even local accounts don't have access.

if you are so enclined, you can put a passcode protected program into your boot script for the admin/root user, and if answered wrong, can do a quick format of the filesystem (separate partitions are great) if it is answered incorrectly.

paranioa is fun!

P.S. my password is an MD5 checksum of a particular file plus a few characters. Even I don't know what the password is.

I have been and continue to be a Kazaa user. I'd say a majority of my data has come from the fasttrack network in one form or another.

That having been said, I've gone to great pains to setup a dedicated waste server for my particular circle of friends, and I've found that the private sharing on waste to be in some ways superior to that of the files found on fasttrack.

For example, most movies whether they are unsteadycam captures at a local theatre or rips direct from DVD usually go through a certain ammount of degredation during transfer. This is normally not a problem, except when that one file has been traded more than half a dozen times. On fasttrack, it's concievable that a file will change hands at least 10 times before it enters a user's sphere of influence. There are also a few other dynamics that promote sharing files of inferior quality, usually based solely on when the "l33t 0-day \/\/ar3z and /\/\0vi3z" are released.

Yet with waste, not only am I assured of personally knowing the person I'm trading with, (And one of my requirements for trading keys with someone is that it be done face to face, just like a good ol' PGP party) but I can be relatively sure that the files will conform to a high level of quality. (This is not typical for your average user, but most of my crowd are avid infojunkies, and take great pains to insure good rips.)

Another benefit I've noticed is in transfer speed. I suspect that this is due to most of my network being supplied by broadband connections, once again due to most of my friends taking media VERY seriously.

I guess waste isn't a superior form of P2P, but I will say that I appreciate being able to connect directly with people I know to be immediate friends. And perhaps making P2P more community-based instead of having a free-for-all will be a better move anyhow. At least, those of us who use the technology and take it seriously arn't going to let it die... not without a fight anyway!

I just want to point out in respect to turing_machines post, this is the use of public/private key encryption. No one will be able to monitor you whether they have a key or not. The public key which is shared can only ENCRYPT data not De-crypt. This means any traffic will be encrypted and render useless to anyone except the PRIVATE key holder (you). Having the public key will not help you other than to encrypt the data before transmitting to the reciever. And as far as the key belonging to you, what does that mean? Its not a drivers license, its a block of numbers and letters, that doesnt mean anything to anyone except you- and you can change keys whenever you want.

-Maestr0

Looking into the functionality of this particular program, your key is, in fact, broadcast from someone who has decided to trust you to all people who have decided to trust them. Also, if ou change your key, then you need to re-introduce yourself into the network.

changing your key will, in fact, drop you from the network. Check it out. As it is written, once you are accepted into the network, as your key, then you ahve access. You change your key, and poof.. gone.

As far as changing keys, if it was that easy, then verisign would be out of business. Once you propagate a key as being you, and people trust that key, for you to simply change it on a whim makes it valueless.

Your key will indeed be an identifier. or it is useless.

Your public key will identify you to the network and your private key will decrypt data encrypted using your public key. It will not identify with your computer/name/IP/dog or anything else. And changing your key, well I know its pretty hard, it goes like this:

"Hey Bob, I'm changing my key in Waste will you swap in my new key?"
Bob: "Sure, what it is?"
"blah-blah-blah" <---- Insert key
"Thanks."

-Maestr0

I only wish waste had a *nix client available.
For now, I'll stick to ftp downloads and uploads, largely still unmonitored.
: )


--PuRe

That is great.

I'm not saying that you CAN'T change your key.

In fact, you can. Any time you want. And each time, you will need to reinitialize yourself with the entire network, unless they are replicating trusted keys internally.

So its more like this..

Hey Bob....

Hey Tim...

Hey bill...

etc etc.

expecting that most networks will need at least 100+ members to have a decent collection of files and download points, that's not a negligible work.

And also, they would want the ability to change keys as well. giving that it is probably more work than anyone would wont to do, say one key addition per day. That means you have your key for a minimum of 4 months before being able to change it. Since 100 people, 1 per day, 100 days, etc.

Or find an easier method, such as dynamically created keys based on request, ttl of packets, etc.

then jumble the actual data, etc.

There are ways.

I suggest reading more on what this software actually does, and its limitations. I was surprised as to how robust the software was, but again, its limitations are not negligible.

Its strength comes from having a trusted set of users (keys) that do not allow anyone else to share their private keys.

The default setting is that if any user in that group accepts that new users key, it is broadcast as a trusted key into the rest of the group.

You can set it so that you must manually approve, but then you run into the 4 month limitation... where everyone must manually approve everyone else and all their changes as they happen.

If this is manageable for you, then so be it. I think it is a great alternative for some, but the last thing people need to think is that in its default configuration it is somehow secure.

It is more secure than what is currently available.

That's all that can be said.

...
...
Pure-- they do have a *ux client.

Its command line, but writing a quickie GTK wrapper I'm sure is in the works. doesn't look all that hard.

That's the source that I looked through to see how it was designed to work.

Interesting read.

..
For instance -->
WASTE cryptography

Since WASTE requires a small trusted network to function efficiently, it benefits greatly from cryptography. Using public-key encryption for session key negotiation and user authentication allows both the prevention of unknown users from joining the network as well link data security to prevent unknown users from “sniffing” network traffic.

WASTE also provides for an additional “network name or ID” that can be used to secure a network against people who do not have the name or ID. This can be useful if you wish to easily prevent multiple networks from merging, or change it to easily remove access of user(s) without having to make everybody ban those user(s) public keys.

WASTE uses a (hopefully) cryptographically secure random number generator based on the implementation in the RSA reference code. The code uses a 32 byte state, with 16 bytes of counter and 16 bytes of system entropy constantly mixed in, and produces random values by using MD5.

WASTE connections use RSA (with 1024 bit or greater public key sizes) for exchange of 56 byte Blowfish session keys, and 8 byte PCBC initialization vectors.

The link connection negotiation, where A is connecting to B, goes something like this:

1. A sends B 16 random bytes (randA), or blowFish(SHA(netname),randA) if a network name is used.
2. A sends B blowFish(randA, 20 byte SHA-1 of public key + 4 pad bytes).
3. B decrypts to get the SHA-1 of A’s public key.
4. If B does not know the public key hash sent to it, B disconnects.
5. B sends A 16 random bytes (randB), or blowFish(SHA(netname),randB) if a network name is used.
6. B sends A blowFish(randB,20 byte SHA-1 of public key + 4 pad bytes).
7. A decrypts to get the SHA-1 of B’s public key.
8. If A does not know the public key hash sent to it, A disconnects.
9. A looks up B’s public key hash in A’s local database to find B’s public key (pubkey_B).
10. A generates sKeyA, which is 64 random bytes.
11. If a network name is used, A encrypts the first 56 bytes of sKeyA using the SHA-1 of the network name, to produce EsKeyA. Otherwise, EsKeyA is equal to sKeyA.
12. A sends B: RSA(pubkey_B,EsKeyA + randB) (+ = concatenated).
13. B looks up A’s public key hash in B’s local database to find A’s public key (pubkey_A).
14. B generates sKeyB, which is 64 random bytes.
15. If a network name is used, B encrypts the first 56 bytes of sKeyB using the SHA-1 of the network name, to produce EsKeyB. Otherwise, EsKeyB is equal to sKeyB.
16. B sends A: RSA(pubKey_A, EsKeyB + randA), (+ = concatenated).
17. A decrypts using A’s private key, and verifies that the last 16 bytes are equal to randA.
18. B decrypts using B’s private key, and verifies that the last 16 bytes are equal to randB
19. If a network name is used, A decrypts the first 56 bytes of sKeyB using the SHA-1 of the network name.
20. If a network name is used, B decrypts the first 56 bytes of sKeyA using the SHA-1 of the network name.
21. Both A and B check to make sure that the first 56 bytes of sKeyA does not equal the first 56 bytes of sKeyB. If they do (which is statistically unrealistic and would lead one to believe it is an attack), they disconnect.
22. Both A and B check to make sure the final 8 bytes of sKeyA differs from the final 8 bytes of sKeyB. If they are equal, disconnect.
23. A uses the first 56 bytes of sKeyA XOR sKeyB to initialize Blowfish for send and receive. A uses the final 8 bytes of sKeyA as the PCBC IV for send, and the final 8 bytes of sKeyB as the PCBC IV for receive.
24. B uses the first 56 bytes of sKeyA XOR sKeyB to intialize Blowfish for send and receive. B uses the final 8 bytes of sKeyB as the PCBC IV for send, and the final 8 bytes of sKeyA as the PCBC IV for receive.
25. All further communications in both directions are encrypted using the initialized Blowfish keys and PCBC IVs.
26. A sends B the constant 16 byte signature (“MUGWHUMPJISMSYN2”)
27. B decrypts verifies the signature
28. B sends A the constant 16 byte signature (“MUGWHUMPJISMSYN2”)
29. A decrypts and verifies the signature
30. Message communication begins (each message uses a MD5 to detect tampering – if detected, connection is dropped)


to repeat, its for a small network, and it makes no allowance of rotating keys. The entire conversation is based on the keys which, by another "trusted" user of both the sender and reciever, has access to, and the "unencryption" piece is defined above. If you have the keys, you have the conversation.

Hrm, since WASTE is open source, its changing all the time. Perhaps someone will figure out how to build a keyserver for larger networks to facilitate keeping things up to date, of course that also brings into play a whole new area to secure and control, and possibly could cause a decrease in the overall security and anonymity of the software.

"WASTE connections use RSA (with 1024 bit or greater public key sizes) for exchange of 56 byte Blowfish session keys, and 8 byte PCBC initialization vectors."

Unless the RIAA acquires the computing power of several small universes, I dont think you need to worry about rotating your keys.

"If you have the keys, you have the conversation."

Not unless you give away your private key. In which case you're an idiot and should'nt be using encryption..

17. A decrypts using A’s private key, and verifies that the last 16 bytes are equal to randA.
18. B decrypts using B’s private key, and verifies that the last 16 bytes are equal to randB
27. B decrypts verifies the signature <--- PRIVATE KEY DECRYPTS
29. A decrypts and verifies the signature <--- PRIVATE KEY DECRYPTS


-Maestr0

Syini already been done,
Check this out, Mixter's Six-Four: http://www.eweek.com/article2/0,3959,919681,00.asp

Okay.. I used the "complex" version of the conversation for arguements sake. Here is the actual comements in the source.

On connection:


1)
A sends B 16 random bytes (bfhpkA)
A sends B blowFish(bfhpkA,20 byte SHA-1 of public key + 4 pad bytes)
B sends A 16 random bytes (bfhpkB)
B sends A blowFish(bfhpkB,20 byte SHA-1 of public key + 4 pad bytes)

2)
if A knows B's public key, and B knows A public key, continue.

A sends B: RSA(pubkey_B,sKey1 + bfhpkB), sKey1 is 64 random bytes. (+ = concat)
B sends A: RSA(pubKey_A,sKey2 + bfhpkA), sKey2 is 64 random bytes. (+ = concat)

Check to make sure bfhpkA and bfhpkB are correct, and to make sure sKey1^sKey2 is nonzero,
with the last 8 bytes of sKey1 differing from the last 8 bytes of sKey2.

3)
each side initializes blowfish using the first 56 bytes sKey1^sKey2 as key.
A uses the last 8 bytes of sKey2 as recv CBC IV.
B uses the last 8 bytes of sKey1 as recv CBC IV.

4)
each side sends a 16 byte signature, blowfished.
each side verifies 16 byte signature.
message communication begins.
further messages are verified with a MD5 to detect tampering.


In other words, just as I said, if you only give your key to a single person, and they do not propagate that key, you are fine.

But if ANYONE gets that key who you don't know, or is subpoened, or is a general a$$hat, and they also have the other person's key, look above. The math is there and is EXTREMELY simple.

No universe of processing necessary.

In fact, if you have JUST the access to step 2 (public keys of both parties *NOT PRIVATE*) you have all the math you need.

check the source.

or just do the math above.

I can do it on a 486 and snoop whatever I like. That's why people HAVE revolving keys now.

VPN's are EASILY broken and sniffed if you know both keys.

the MD5 encryption just checks the checksum of the last chunk.

I think it is better than what is available without encryption, but is NOT some ubersecure solution requiring nitrogen cooled machines to begin to crack.

If you keep your keys to yourself, and everyone you connect to does the same, you have a limited secure vpn. That's what you have.

Think about it. You have a TCP connection with authentication, and key swapping.

In other words, you have a VPN from about 7-10 years ago.

But unlike a VPN, the software pushes your key to other VPNS in order to expand the available universe.

Here's another note from the source.

---- some things that would be good to do eventually:

permissions per key:
C=chat
S=search/browse out
s=search/browsable
X=file transfer
K=key distribution
U=uploads
P=pings/ips/etc
?=unknown (all others)
have the connection keep track of the flags and key hash, then have the
prefs update all connections' flags.

improve ip list sorting (use a sorted listview?)

plugin interface
ipv6 support
Ephemeral Diffie-Hellman for session key exchange?


That last line is the key. In other words, they are aware of the issue in the key exchange security (there really is none other than the sniffer being ignorant of the algorhythm above)

Notice that K security switch above. That would be to LIMIT someone from being able to distribute your key.

that's not implemented yet.

Check the code. Its more than a motto, its good business.

I think the major problem is being totally overlooked here, encryption is totally pointless if you have "trusting relationship" with a RIAA bot/downloader , the only thing encryption saves you from is someone interrupting/capturing your stream which would be impossible legally unless you were doing something like trading child porn. A method of verification is what is needed and the only way to do that(that i can think of) is through smaller groups. which then makes encryption pretty much a waste of time and resources.
I wan't to address something mentioned on the first page also , A movie that has been broadcast does not degrade any from being traded , at least on the edonkey network , a hash is made and all sections(9mb) you download are checked for corruption and redownloaded if corrupted , you are getting the movie from tons (sometimes 100s) of different people and it may have already come through hundreds of people.

"Ephemeral Diffie-Hellman for session key exchange?
That last line is the key. In other words, they are aware of the issue in the key exchange security (there really is none other than the sniffer being ignorant of the algorhythm above)"

Yes this refers to key exchange, but it has nothing to do with what you are talking about. The Diffie-Hellman key exchange is a diffrent method of key exchange(The one here is the RSA key exchange) using an agreed group which defines a prime and a generator for a 2 part key exchange, which I will not go into any deeper for fear of further complicating an issue you are already unclear on. The weakness in the RSA key exchange lies in that anyone can use someone elses public key to begin a key exchange but unencrypting any response will not be possible without the private key(Signing the key and encrypting both key and signature can be used in this situation). Lets go through this step by step and see if we can clear it up: A is Alice, B is Bob and our snooper is Eve (of course)

A sends B 16 random bytes (bfhpkA)
A sends B blowFish(bfhpkA,20 byte SHA-1 of public key + 4 pad bytes)

-First we send the blowfish(128 bit) key plain text. Then we send a hash of the RSA public key, and 4 bytes padding as a bf block.

B sends A 16 random bytes (bfhpkB)
B sends A blowFish(bfhpkB,20 byte SHA-1 of public key + 4 pad bytes)

-Our friend does the same.
-So far Eve has sniffed the blowfish exchange and all is looking good except all we got was a hash of the key and not the actual key. Now the next part.

if A knows B's public key, and B knows A public key, continue.

-This is basically a signature check.Here we decrypt the bf block,extract the hash of the key and see if it will match a hash of a key in our databse, if yes continue

A sends B: RSA(pubkey_B,sKey1 + bfhpkB), sKey1 is 64 random bytes. (+ = concat)
B sends A: RSA(pubKey_A,sKey2 + bfhpkA), sKey2 is 64 random bytes. (+ = concat)

-Here each party uses the the others RSA public key to encyrpt: a nonce (random number used as part of the next key) concatenated with the bf key.

Check to make sure bfhpkA and bfhpkB are correct, and to make sure sKey1^sKey2 is nonzero,with the last 8 bytes of sKey1 differing from the last 8 bytes of sKey2.

-Here we use our Private key to decrpty the RSA exchange and get our new key plus the bf key as a check. But wait, Eve cant decrypt this data without the private keys so she will be unable to discover the next key to be used in the blowfish exchange.

each side initializes blowfish using the first 56 bytes sKey1^sKey2 as key.
A uses the last 8 bytes of sKey2 as recv CBC IV.
B uses the last 8 bytes of sKey1 as recv CBC IV.

-Here the legitimate users have initiated a new bf cipher using the nonces exchanged in RSA with the last 8 bytes as the initialization vector for the new cipher.

each side sends a 16 byte signature, blowfished.
each side verifies 16 byte signature.
message communication begins.
further messages are verified with a MD5 to detect tampering.

-Now we check and make sure Bob and Alice are on the same page by each checking a known signature. At this point any third party has been locked out and the session procedes via the new bf cipher and is checked with md5 to avoid anyone messing around with our cipherdata.

-Maestr0