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's any flaw please point it out for me here or Github.

First, I use an Elliptic Curve for asymmetric encryption and AES-256-CBC for symmetric encryption.

DH-RPC NodeID is generated by hashing the Node PublicKey and an Uint256 Nonce:

NodeID := sha256(blake2b-512(NodePublicKey + Uint256Nonce))

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. 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.

GenECDHSharedSecret(APub, BPriv) == GenECDHSharedSecret(BPub, APriv)

The main procedure is described in this sequence chart: enter image description here

Because in the decentralized system NodeID is the URI, not "Bob/Alice.com". 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.


Known issues:

  1. Add a random uint64 along with NodeID and Nonce sent to remote to add some random for the shared key.
  • $\begingroup$ In a Kademlia DHT the NodeIDs is supposed to be uniformly distributed. Defining the number of consecutive 0s in front of the NodeID as difficulty will break that. $\endgroup$
    – Encombe
    Sep 10, 2018 at 13:21
  • $\begingroup$ Yes, you are right, this issue can be solved by reversing the byte order or hashing before distributing on DHT. $\endgroup$
    – auxten
    Sep 11, 2018 at 3:09


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.