Topic: Feature request: Implement SSH-like conn encryption into protocol (OpenSSL ?) (Read 1866 times)

Actually the reasoning behind not needing the encryption is because we always assume an adversarial peer we're communicating through. The only thing that should be considered is reducing timing attacks which would enable to track back the origin of a client, but that's a pretty slim chance, and partially solved by using Tor.

Well, maybe not completely pointless, but much less useful than i thought, and certainly not much more anonymous.

Encryption is not pointless, because it is unlikely an attacker can control enough bitcoin nodes today.

Furthermore, it is nice to not be observed when I am submitting a new transaction to the network.  Those in the coffee shop have no business knowing that I am submitting a new transaction, even if the TX is propagated in the clear throughout the network.

That is a fair point, why didn't i think of it ?
Encryption is pointless, because when an attacker can control enough bitcoin nodes, SSL won't help at all...

That wouldn't change anything.

That's anonymity you want. Why Tor isn't enough?
Actually, encrypting won't make it anonymous, the nodes you're connecting to would see the messages coming from you.


By the way, are propagated messages any different from those sent by their creators?

Simple. So that nobody knows what IP were these transactions created by.

And SSH-like connection will be almost exactly the same as a SSL-like connection, but without central certificate authorities. Of course some mechanism of reading fingerprints from a HTTPS site could also be implemented, so people could create "semi-certificate authorities" which would be simply a list of node IP's with their fingerprints.

I can see the advantage on the authentication part. You could have a set of trusted nodes to connect to in order to avoid being "surrounded" by attackers.
But, as most people minded with security (banks and other institutions included) will probably hide their IP, this wouldn't be so useful, unless the client could connect to hidden services. But then the anonymity network itself guarantees authenticity, no need for the client to sign its messages...

Now, on the encryption part of an SSH-like connection, I fail to see the advantages. All messages your client send are supposed to be propagated to the entire public network anyway. They are not secret. Why encrypt?

I'd rather change your request to something like "being able to configure a set of IPs and/or Tor/I2P hidden services ids to connect to".

I propose something that has been discussed many times on the forums - implementing connection encryption to the bitcoin protocol.

Details:
- Like SSH, people will be able to connect to each other securely, using cryptographic keys / identities they need to exchange first.
- As in SSH, each host will generate its fingerprint, and set of private/public keys. So nodes connecting will be able to verify each other
- Some nodes (like banks) will be able to publish their keys/fingerprints somewhere (like on their site), so that everybody can confirm who they are when connecting to their bitcoin clients
- When key/fingerprint of remote node changes, user will be warned & asked if he wants to connect anyway (like in SSH).

- To make things easier, one could use openssl library present in every major operating system to implement this.

Possible benefits:
- Possibility of having almost 100% anonymity for each node. (if some random traffic generator will be also implemented) A third party no longer will be able to tell who is who and which transaction is which by sniffing the traffic coming in/out of a node.
- Real security & more anonymity when connecting through TOR (right now the exit nodes can easily sniff/intercept all traffic, so using bitcoin on TOR is somewhat dangerous).
- Eleminate man-in-the-middle attacks.
- People will be able to create "semi-certificate authorities", which will store each node's fingerprints and show them publicly, so nodes of the network can be verified.
- Clients (like banks) could choose to connect only to trusted, SSL-verified nodes, and ignore the rest.

Possible disadvantages:
- Possibility of centralization of the network ?