Topic: Peer 2 Peer Open Source Encrypted Text, Voice & Video Communications - page 4. (Read 15415 times)

... this quote makes me think that you have got the crux of the idea.

Namecoin is already doing the job you require, i.e. keeping key integrity ... and since it is secured with merged mining by much of bitcoin network hashpower, it is possibly the most secure human-readable nameID linked key integrity system in the world waiting there to be taken advantage of ...

http://dot-bit.org/Main_Page

whoa, that does sound revolutionary indeed, And yes I get exactly what you are saying now.
I'll have to ponder on that idea, and do some research on name-coins source code (or perhaps even hire someone to do the name-coin integration), I like it though its basically everything i described but in this case instead of cost in hash power for clients, it costs in namecoins and the namecoin verification nodes(miners) are paid to keep "key integrity"

I agree, I don't think you are understanding the use correctly ... it's a little involved and I'm not sure if I want to go through all the details here. You seem to be a clever guy so I'll just out line the scheme and you can probably fill in the details.

- Users secure their 'name' in the namecoin blockchain, (i.e. only they hold the namecoin private key associated with that name)
- Also users associate with that name an EC public key using one of the appropriate namespace facilities of namecoin
- When initiating a connection the Sender creates a shared secret using their EC priv. key and EC public key of Recipient by looking up namecoin blockchain (autonomously if need be)
- Receiver can verify who the Sender is securely (and autonomously if need be) by looking-up Sender's EC public key up on namecoin blockchain and creating the required shared secret to communicate initiate ack response
- Sender-Receiver use shared secret encrypted channel to exchange AES keys for encrypting primary dialogue
- ... and etc, do the ECDH as usual from here on ...

... could also do a pay-per-secure-connection model using the namecoins/bitcoins per data-byte ... e.g. sender sends namecoins to receiver address to initiate connection, receiver (streaming server) only allows paying senders to open secure connections ... and stuff like that, hope this helps.

perhaps namecoin does something that I'm not aware of as far as man in the middle attacks but im pretty sure that if i gave you my name coin address, an attacker(lets say a moderator in this example) could replace my namecoin address/id on the post, I don't understand how namecoin is solving this MITM issue (or perhaps I'm looking at the namecoin solution different then what is being presented)

Web-of-trust is only weak protection against MITM (as is CA) versus using a namecoin ID authenticated public key for the key-sharing initiation of a connection.

http://en.wikipedia.org/wiki/Perfect_forward_secrecy

"OpenSSL supports perfect forward secrecy using elliptic curve Diffie-Hellman since version 1.0"

http://en.wikipedia.org/wiki/Key-agreement_protocol

"Protocols that are useful in practice also do not reveal to any eavesdropping party what key has been agreed upon."

Very good input,
Yes we are having the app default to AES/DES/Blowfish for streaming capabilities. the MITM attack can happen regardless of the identity generation method used. so to solve the MITM attack we use the web of trust to evade that issue; however I see your point now that I've thought it through Public key ids should be reduced down like Bitcoin/Namecoin strings for easy copy and pasting and for easy to remember as well.

You might consider using namecoin identities, alias namespace, to provide human-readable authenticated public key exchange and diffie-hellman shared-secret (ECDH) to initiate and establish the AES encrypted channel from there ... it gets around MITM and using CA's for something close to perfect forward security.

Thanks for the heads up; in that case, I'll stay the course and learn from other projects and integrate the best functions into this project.
I think I'll incorporate hashcash for all p2p crypt messages to reduce spam, and if you want to spam the network it'll cost you hashing power + electricity

i recommend u to stay away from retroshare, its a buggy code base and  the devs dont really bother to fix this, its like M$ actually.
altough u could look at theirs DHT code, but you would have to fix it since its bugged as hell -> you constantly broadcast (telling the DHT nodes that u exist) without limit, ur flooding UDP packets as shit, no way to limit it, just horible

Oh one difference between retroshare and this project is that retro share doesn’t have a "streaming" option, I'd imagine that p2p crypt nodes are only used for "key server and relaying data".

 so on a side node:
if a receiving user isn't online all nodes will be advised to save data for a optimal amount of time(nodes can refuse to relay data, but the more a node is "known" that it refuses to relay most  data received then other nodes will be label that this node is a "leech" in their local DB rating systems. Meaning it is still advisable that this node could be trusted for relaying and communicating with, they just might be asshats about their bandwidth and shouldn't rely on them as well as other nodes limit the bandwidth for the leech as well.

correct

Your question fails to provide what kind of relation ship I have with josh in the example, so I’m not sure what kind of trust we are talking about. The website-trust is for "login/sessions" and even in the future for social networks to "request data" that can been auto-filled after unlocking the requested information with a password, anything beyond that i don't understand your question.

let me clear up that you used Account and identity interchangeably but separately, if you create a new account/identity you can still load up your list of "Trusted nodes" and "untrusted nodes" but to the network you are an untrusted node/client because you are new all nodes should be advised "NOT" to trust you until you build some trust.  You can build trust by relaying data and other nodes will verify your data against other nodes thus its impossible to know (Just like Bitcoin) who trusts who. UPdate/Edit: Also makes it expensive to get anything on the network when there is super complex webs of trust/attacks going on why if half the network was being attacked that would make it difficult for more attackers to join in because its unknowable how far your "failed" data will traverse through the p2p nodes considering that nobody will ever know the "true" levels of trust everyone has applied to every other client/node.

I'd imagine in my system that you would have to take 3 months to a year to get the whole system to FULL trust a new online identity and your trust could be broken back down to 0 (or even in the negatives) in a day if you start to relaying bad data. (In the future someone could build an add-on or module or even into the protocol that alerts other "Trusted" nodes that this X node is relaying alternative data and could be bad, but i just wont know if this is possible with so many false positives that could be attributed.)

This is with out the "bitcoin" type system integrated... In the future not only will it be (CPU) costly to create the message I'd imagine the user could have to generate hashcash/bitcoin target digest output before the message is accepted by the p2p nodes for relaying (CPU Costly to send message, Easy/quick to verify and Relay messages)



Thanks for the retroshare link(and the other resources as well cheers!), that GUI looks exactly how I envisioned, Perhaps I could build on top of it and contribute to the project (didn't get a chance to see the license). Looks like a great application to fool with and thank  you for your great questions, I hope I provided some interesting answers as well.

More side nodes:
I realise this idea isn't new by any means but I think it will be the first to make it into run-time.

OK, I understand your system as planned will include all of these pieces but it is a lot to take on. I am going to describe it in the context of some existing projects that have taken on chunks of the problem, for more research areas you may want to look into...

So there would be a component that would operate like a PGP/GPG keyserver, but with additional validation over other channels like what the the CACert Web of Trust CA is doing.

Very true, you just have to make sure the validation process has air-tight security - for example, if someone posted a public key for Josh on this site (with some cleanup to make it look legitimate of course) is that enough trust? Obviously not. Systems like CACert require a face-to-face meeting with trusted community assurers and checks of government ID to finish the signing process for the Web of Trust cert. It depends on what level of trust you want to place in the system.

This would be difficult to protect against, what's to stop me from feeding a node bad data continuously with a coordinated attack from multiple new accounts, slowly increasing the percentage of bad data it relays to take it offline? How does the node itself verify the trust of the original party when it is deciding whether to pass the data along? Also, how do you know you are talking the real person's identity, and not someone that has created an account claiming to be that person?

Yes, once the trust system is in place, it could be used for many awesome things.

This I have to object to, SSL works well, is extensively tested, and highly trusted. HTTP can be stateful without any encryption at all. User authentication/captchas is a separate issue, and in that area it is true that the web of trust would provide an additional authentication option (possibly taking the place of SSL client side certificates.)

Also, how does your system compare to something like Retroshare?

I know the end goal you want to get to for the trust side, since having a working system of decentralized trust is a 'holy grail' for online systems, and a lot of research has been done in this area as it contains a lot of hard CS problems. The wiki article on Web of trust is a good resource, and there are many papers (search for 'trust management problem' or 'decentralized identity'.)

Even just a face-to-face-public-key-sharing (or via Bitcoin public keys...) crypto app would be very useful in its own right, however. In any case, I am looking forward to seeing where you take the project!

Also I'm going to declare the p2pnode server as X11/MIT license in the next commit on github. The client however will have free and pricing options

I'm looking for someone to help me develop the GUI in C and GTK2.0 I nessecary I can pay some Bitcoins if its worth it. Code should be easily flexible so I can hook actions into the pages and buttons. Contact me for more details.


https://docs.google.com/drawings/d/1NsXZZYmtuigO4SfOZAbMY2BE9Czupf06VOn1El15d7M/edit

No problem-o.

Good question; I'd imagine the p2p nodes are basically super nodes and clients only relay small bits of data .
If the client trusts the source of the private key, it doesn’t matter how the data is sent or received as. (Example, if I trade keys face-to-face it won't matter how the data gets there or received). The issue is that people from china can't all practically swap keys face-to-face, and not everyone is a "Crypto-wizard" to know how to evade "Man in the middle attacks during key exchange over an electronic interface". This is when the "P2P node trust" system comes in to play, basically two people exchange keys on the non p2p network (perhaps a facebook message or IRC). Once to people have their public keys they now can ask the p2p nodes to validate the key by asking for and validating various information transparently for the user.

Why do i think this is awsome?
As of right now for a "layman" to accomplish this they have to be educated that they need more than one channel of communication to prove that there was not a man in the middle attack during the trading of public keys, so this solution makes the whole experience transparent becuase unless you meet face to face for publickey exchange your most likely going to exchange public keys through gmail, hotmail, IRC or facebook and unless a "layman" is educated to "resend the same key on a different email address or chat channel and "match the public key letter by letter", then they are vulnerable to man in the middle attacks".


Other notes....
New clients can build trust by helping relay small chunks of data;
the actual trust is gained by other nodes if your data seems to match up with nodes that those recieving nodes trust, the more your information matches the more your trusted over time, however if your client is relaying 100% or even 20% false data all nodes are advised to deny data from that client or node (A better solution would be to lower the priority of processing from your node as an attack could be happening and "triggered block occurred")

This p2p crypt app could also provides other opportunities
*Like perhaps even be the leader of SSL certificate authority systems in the far off future: I ponder that if everyone online has everyone else’s key who is currently online along with a rating of "trust" that node is then perhaps we won't need to have CA's at all because there is no more risk of man in the middle attacks (which is why there is CAs certificate list is in browsers).

*SSL and non SSL enabled websites could rely on the p2p crypt trusted web to initiate a secure login session, cookies and other methods to turn HTTP into a "State full" protocol literally is 2+ decade old technology and computers getting faster while captcha methods failing; The sessions are under constant attack and its time to move on.
HTTP could be used to serve webpages while P2P crypt could allow websites to initiate a "secure session" regardless of an SSL connection. this could allow safe login sessions that are harder to attack on.


Just some ideas to "mull over" guys Obviously we going to see how the system works up over time but this is the ultimate picture i think.

Thanks for doing this, it is much easier to reason about the system this way than when starting with code. The diagrams are very nice.

Some questions:

Why do the Nodes need to be trusted, if the data channel is between users, and data is encrypted? Or is this for a supernode-like system?

P2P trust and reputation systems are extremely difficult, what happens if hundreds of rogue nodes come online that all trust each other 100%? Can they kick Bob off the network by spamming "Bob is not trusted" to other users?

Have you reviewed other protocols like OTR to see some of their guarantees for privacy and deniability?

City-wide decentralized wireless internet will not happen (at least not in the next 10 years, maybe on a small scale with smarter antennas.) Wireless spectrum is too scarce, and latency between hops is too high, to support even a small city full of users. I believe that internet service over city-owned fiber will be the status quo for the next 50-100+ years, run as a utility, like trash service, water, sewage, or power, and the solution for 99% of users. So possibly even more centralized than what is here now. However, after the first hop, there will be an incentive to run better paths between cities and neighborhoods, so there will be more decentralization at a higher level.

Essentialy its the same setup as a CA but this is different in that there is no stigma in "authority" just "secure communication" associated with the project. The other differences is that its more real time than "pay, generate, distribute".

how about CA?

I plan to use RSA Keypairs for the identities. Communication could be transparently chosen/negotiated in the back end or a config file. If a communication method can't be agreed upon the application should use a default that every app could "default" too in that event. Most likely AES or blowfish perhaps.

The issue at hand is that until decentralized internet is established the masses relies on one "Internet" tunnel to reach their devices, there is rare cases where someone has purchased multiple Ethernet lines to connect to that are provided by separate companies, so even in the city with high amount of wifi nodes around they general area will be considered by the same company. If there are multiple wifi nodes from multiple companies its super rare to be equipped with a WIFI chip that will connect to multiple nodes at once so until all this is fixed(hopefully in the near future the internet will become decentralized) the P2P Crypt is forced to work like the following diagrams

BLUE: Connections not safe for trading public keys, but is safe for relaying data (Unless data is being received or sent to a trusted node)
SOLID GREEN: These are "actions" that happen, and they increase the security of the network
DASHED GREEN: These are the results of the solid green actions, dashed green lines show which nodes can safely relay data to each other regardless if there is an untrusted connection/ISP
DASHED Yellow: These are the results of the green "actions", They are used for transferring encrypted and plaintext data as well as public keys. Information must be verified by requesting the checksum from other nodes and once enough yellow nodes have sent in trusted information (and atleast 1 green solid connection) have been verified then the data is marked trusted

The following shows an untrusted internet-work connections before anyone trades keys and/or builds trust.


The following shows how to solve the Man-In-The-Middle issues by trading public keys in person (or provably secure connection)



Obviously trading public keys face to face is 99% impossible to do in a practical sense for the internet, so the P2P Crypt server nodes are established to be running 24/7 all around the world. P2P Nodes would in theory trade public keys in person only once to establish trust. Now clients can connect to multiple p2p nodes and verify information from multiple sources (the diagram shows only two p2p servers nodes but a the actual client would require 20 nodes to verify information before anything is trusted).


I'd imagine that just like Bitcoin there would be an 100+ established trusted nodes included with the application, so just assume that when viewing the steps below. The steps below depicts how a new p2pnode (or client) coming online could begin to establish trust with other nodes or clients with out meeting face to face and exchanging public keys.

Whoa sweet, I was writing my own networking code and it doesn’t look pretty, I'll definitely check out libevent for sure.

I'll get back to you with how I imagine the network would process like, very soon.