
TLS – Cert + DHT = DH-RPC - auxten
To implement a decentralized system, I wrote a TLS like P2P net stack.
The main idea is removing CA Cert from the whole system by using a DHT for Naming and Key Exchange. 
I am not a crypto expert, so if there&#x27;s any flaw please point it out for me here or Github<p>I use an Elliptic Curve for asymmetric encryption<p>DH-RPC NodeID is generated by hash of Node PublicKey and an Uint256 Nonce:<p><pre><code>    NodeID := sha256(blake2b-512(NodePublicKey + Uint256Nonce))
</code></pre>
I refer to S&#x2F;Kad idea to define the number of consecutive 0s in front of the NodeID as difficulty and to impose a minimum limit on the difficulty of the NodeID allowed to be stored on the DHT.
DHT is used to hold the NodeID:PublicKey NodeID:Addr map. NodeID and Nonce are sent to do ECDH getting shared secret after TCP connection established.<p><pre><code>    GenECDHSharedSecret(APub, BPriv) == GenECDHSharedSecret(BPub, APriv)
</code></pre>
The main procedure is described as sequence chart: https:&#x2F;&#x2F;github.com&#x2F;CovenantSQL&#x2F;CovenantSQL&#x2F;blob&#x2F;develop&#x2F;logo&#x2F;rpc.png<p>Because in the decentralized system NodeID is the URI, not &quot;Bob&#x2F;Alice.com&quot;. So anyone tries to fake NodeB by overwriting the address or public key on DHT without the private key of NodeB will be failed to get the correct shared secret.<p>Github: https:&#x2F;&#x2F;github.com&#x2F;CovenantSQL&#x2F;CovenantSQL&#x2F;tree&#x2F;develop&#x2F;rpc<p>Known issues:<p>1. Add a random uint64 along with NodeID and Nonce sent to remote to add some random for the shared key.
======
dustindecker
Not a crypto, DHT, or any expert, but this sounds interesting very to me.

It definitely sounds like there are some potential security concerns with DHT:
[https://en.wikipedia.org/wiki/Distributed_hash_table#Securit...](https://en.wikipedia.org/wiki/Distributed_hash_table#Security)
A new implementation called Tonika is mentioned that sounds promising to
defend against the sybil attack but I don't see much activity on the project
post-2012.

As you mentioned, nodeID becomes the URI (You can CNAME a domain to that) and
protects from node spoofing, but it seems like a if someone could affect the
DHT, they could cause a DOS. I supposed that'd be analagous to BGP spoofing
routes? If the only way to falsely modify the DHT is a mount a sybil attack (I
have no idea), then it could actually be an improvement over the current state
with BGP.

The other concern of course, is if the DHT implementation is intergalactic-
internet scale.

~~~
auxten
I refer to S/Kademlia's idea to define the number of consecutive 0s in front
of the NodeID as difficulty and to impose a minimum limit on the difficulty of
the NodeID allowed to be stored on the DHT. As the S/Kademlia paper said, they
just use the PoW NodeID way to obviate Eclipse Attack(Make Kademlia Network
Fork), Sybil Attack(Fake Nodes), Churn Attack(Frequently Join & Leave),
Adversarial Routing(Spread Bad Route).

Adversarial Routing is a bit related to DOS Attack you described. As the DHT
is a gossip protocol organized network, maybe some Peer Rating stuff with PoW
NodeId will work out an intergalactic-internet scale DHT. Just a well behaved
proper difficulty NodeID will be trusted to spread more NodeID routing info.

~~~
dustindecker
Okay, I'll do a bit more reading on it.

I found the paper you referenced here:
[http://www.spovnet.de/files/publications/SKademlia2007.pdf](http://www.spovnet.de/files/publications/SKademlia2007.pdf)

Also found your overview here:
[https://github.com/CovenantSQL/research/wiki/Secure-
Kademlia](https://github.com/CovenantSQL/research/wiki/Secure-Kademlia)

Thanks for sharing.

