secure P2P

[Turing_Machine]

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.

[Maestr0]

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

[PuReExcTacy]

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


--PuRe

[Turing_Machine]

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.

[Syini666]

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.

[Maestr0]

"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

[Turing_Machine]

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.

[lumpyporridge]

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.

[Maestr0]

"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