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 hash of 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 as 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.

Github: https://github.com/CovenantSQL/CovenantSQL/tree/develop/rpc

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 '18 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 '18 at 3:09

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.