↓ Skip to main content

DRAFT RFC - Cascading Trust Whitepaper

·978 words·5 mins
Arda Bakici
Author
Arda Bakici
A university student majoring in Computer Science and Mathematics in NYU Abu Dhabi.
Table of Contents

DRAFT - RFC 1
#

Cascading Trust (CT)
#

Please send the comments to [email protected]

Introduction
#

Cascading Trust is a blockchain based messaging protocol that tries to provide immutability of chat history and zero trust server architecture for near real time communication between users. CT implements a decentralized server architecture with heavy reliance on ECDSA to prove identity.

Inner Workings
#

Each CT conversation is compromised of exactly one blockchain which from now on referred to as CT chains. CT chains are constructed from three different block types. These are

InitBlock
#

InitBlocks are always at the beginning of a CT chain and they include all the metadata needed to facilitate the communication. Data entry spaces in InitBlocks are

  • Index: int, position of the block in the blockchain. This is always 0 since InitBlocks are first blocks
  • Timestamp: uint64, unix timestamp of when block was last updated
  • Users: List of ECDSA public keys of users who are participating in this chat
  • DH_Keys: List of ECDHE keys from users who are participating
  • Signatures: ECDSA signatures from users of the chat where they sign the SHA256 hash of all the previous enteries.

An InitBlock is only valid if all the users in Users sign the block and add their signatures in Signatures. Only during the handshake section of the protocol InitBlocks are sent without all the signatures and therefore not valid. These are temporary blocks and after InitBlock gets validated they are deleted. Other than these blocks, CT does not accept any unvalidated block.

MessageBlock
#

MessageBlocks are the blocks that hold the message contents. Contents of a MessageBlock are

  • Index: int, position of the block in the blockchain. Its never equal to 0 for MessageBlocks.
  • Timestamp: uint64, unix timestamp of when block was last updated
  • Sender: ECDSA pubkey of the sender of message. This pubkey should be included in the users list of corresponding InitBlock.
  • InitHash: SHA256 hash of InitBlock. Signatures section is included when calculating this hash.
  • PrevHash: SHA256 hash of previous block. Signature section is included when calculating this hash.
  • Encryption: string, describes the encryption method used in encrypting the content (could also be None which would indicate Content is plaintext)
  • Content: Encrypted message content, but can also be plaintext
  • Signature: Signed SHA256 hash of all the previous sections with private key of Sender.

For each MessageBlock sent from the user, it serves as a verification for all the chat messages and therefore verifying all the block. To test the authenticity of a CT chain, it is enough to only check the signatures in the last messages sent from the users. If a user appends a MessageBlock to the chain it is assumed that user has done the necessary verifications for the previous blocks and therefore vouching for the authenticity of this chain.

WitnessBlock
#

WitnessBlocks are blocks sent from users to verify the chain by signing. They can be sent from users included in the chat or non-included as a 3rd party observer. The contents are

  • Index: int, position of the block in the blockchain. Its never equal to 0 for MessageBlocks.
  • Timestamp: uint64, unix timestamp of when block was last updated
  • Witness: ECDSA pubkey of the witness.
  • InitHash: SHA256 hash of InitBlock. Signatures section is included when calculating this hash.
  • PrevHash: SHA256 hash of previous block. Signature section is included when calculating this hash.
  • Signature: Signed SHA256 hash of all the previous sections with private key of Witness.

Witness blocks are primarly used to increase Validity and Knot Tying.

Terminology (Tentative)
#

Validity
#

Validity value of a chain refers to a system to compare two chains with same chain ids to select which one should be preferred over the other in case of a clash. Longer chains and more blocks from different users means higher validity.

Judged vs Non-Judged Version
#

Judges refer to centralized servers that hold the chat blocks. If CascadingTrust judged version is being used then clients will put trust in the server. Judgeless version is equal trust i.e. both clients have the same trust and therefore same validity to their respective chat histories. In judged version, servers chain has higher validity.

Knot Tying
#

Knot tying is sending a witness block after a certain amount of time in order to prevent other contributors to chat from deleting previous messages.

Block Condensing
#

Block condensing is the operation to merge blocks of user if they have sent multiple messages in separate blocks and no other user sent a new block or knot tie.

RTC Post-Validity Judged Version
#

To accommodate for RTC, in judged version if there is a clash between users where they sent MessageBlock to same previous message then server will select the first received message as legitimate but still insert the other block after that one as a temporary block. Then it will ask for user to resign its block using the given lastBlock meanwhile

Relaxed Judged Trust
#

In relaxed trust, server patches clashing blocks and changes their previous_block value.

Server Identification
#

Users are identified by their ECDSA pub key User verifications are done by signing messages

Implementation
#

For server setups:

prekey = bcrypt(username + password)
chat_id = SHA of InitBlock w/ signatures

GET /user/login/<sha: prekey> 
Return {sha_prekey : ecdsa_pub}

GET /user/<ecdsa_pub>
Return {ecdsa_pub: aes_gcm(pre_key; ecdsa_priv_key || sv_store_aes_key) + nonce}

POST /user/<ecdsa_pub> update
Send: {aes_gcm(pre_key; ecdsa_priv_key || sv_store_aes_key} + sign(ecdsa_priv_key; aes_gcm(pre_key, ecdsa_priv_key || sv_store_aes_key})

POST /user/login/<sha: prekey>
Send: new sha_prekey, sign(ecdsa_priv_key, sha_prekey)

GET /block/<sha_>
Return Block with <sha_>

GET /chat/<chat_id>
Return latest block of chat

POST /chat/<chat_id>
Add message block to chat. Has to match with latest block has and has to be signed

POST /invite/<sha_>
Initialize a new chat with InitBlock, ini

Post /<sha_>
If doesn't exists and InitBlock:
Then create InitBlock, add

Name to SHA Pub Conversion
#

Not decentralized yet, for judged systems server holds a name to SHA conversion table.