Contact FAQ Guide Setup
Get Bitfi

bitfi private messaging
even more private than
face to face

Communication that isn't tied to an identity, where encryption keys are established solely between peers through assistance of a blockchain contract to eliminate involvement of intermediate servers with public key exchange.



The shared secret is a value calculated using an algorithm called Elliptic-curve Diffie–Hellman — Wikipedia (ECDH), an anonymous key agreement protocol for generating a shared secret from a key pair suitable for elliptic curve cryptography.

In the example below you'll see that both parties have an identical shared secret value, it is called shared secret because both are able to reach the same result after obtaining each other's public key then independently performing the required ECDH calculation. The derived ECDH shared secret is hashed then used as the key to AES encrypt/decrypt the respective messages between the two messaging parties.

Alice’s public key = 03c8cbdc902fc302329132c56a8c9535f9c86952ddf539679fc1ba29091aaaf2da
Bob’s public key = 03c075742edf955c47700586a849b453b21ee5a50129546576b673579600aef557
Alice’s shared secret (Bob’s public key + Alice’s private key) = 2e29b2afffecec017e3dd11e2061cae2a77957d9cc364cf7c837c8efc95f94d5
Bob’s shared secret (Alice’s public key + Bob’s private key) = 2e29b2afffecec017e3dd11e2061cae2a77957d9cc364cf7c837c8efc95f94d5


Privacy and Security

Your peer's public key is needed to calculate the shared secret but even after compression it is nearly impossible to remember and far too inconvenient to type whenever attempting communication, and using an intermediate service/database to request this information would mean that such server can trick you by supplying the wrong public key, resulting in your calculation of a shared secret which someone other than the intended peer is also able to calculate. The contract governing Bitfi messaging solves this problem, it serves to; a) ensure that all registered names are unique, so there can be only 1 "bob" and only 1 "lazymonkey"; b) ensure that no registration is ever modified or removed; c) respond with the public key whenever requested for a given name.

Before starting communication the device will send a request to the configured XDC node asking for the public key associated with the registered name, and users may switch to any node which conforms to the standard RPC (ie:, Once the public key is obtained the device will calculate the shared secret, initiate the channel, then begin sending/receiving encrypted messages through the Bitfi websocket. Without ever leaving the device the ECDH secret will both encrypt and decrypt messages between you and your peer.

So the contract effectively allows both "bob" and "lazymonkey" to communicate with absolute certainty that they have connected with no one other than the desired respective party.

The contract: xdc747D8901898c845426599A4293BD61Bb8b46B9E9