Secure Messaging With Ethereum
Reasoning about Ethereum's Role
Presented by: Cayman Nava (caymannava@gmail.com)
Outline
- Messaging Requirements
- Ethereum's Role
- Message Storage
- Examples
- Rendezvous Point
- Interlude - WebRTC
- Examples
Messaging Requirements
- What kind of messages?
- Voice/Video
- Picture/Text
- Who can read the messages?
- One-on-one (ex: text message)
- Group-messaging (ex: Google hangouts)
- Broadcast messaging (ex: Reddit)
- How are the messages stored and transported?
- Synchronous communication - messages sent to online parties
- Asynchronous communication - messages stored for later retrieval
- How to identify a person/persona? ethereum address or list
Ethereum's Role
- Message storage
- Messages stored in the blockchain
- the WHAT of messaging
- Rendezvous Point
- Relationships stored in the blockchain
- the WHO, WHERE, HOW of messaging
- Others (not going to discuss)
Message Store
- Benefits
- Ease of broadcast
- Anyone with the blockchain can access the message
- No off-chain transport/storage
- Asynchronous messages
- Acts as a 'mailbox' that can be retrieved at any time
- Parties don't need to be online to access messages
- Considerations
- Public message boards vs. Private mailboxes
- read protection - encrypted data
- write permission - contract rules limiting access (whitelist of ethereum addresses)
- Other rules (ex: voting, categorizing, 'replying')
Message Store - Examples
Naive Eth-mail
- How to use for messaging:
- Creator can suicide mailbox if necessary
- Any other address can send messages in tx.data[0]
- Use app logic to display messages in contract
if tx.sender == CONTRACTCREATOR: if tx.data[0] == 1: suicide(CONTRACTCREATOR) else: NEXTINDEX = contract.storage[999] contract.storage[1000 + NEXTINDEX] = tx.data[0] contract.storage[999] = NEXTINDEX + 1
https://gist.github.com/WeMeetAgain/10010529
Message Store - Examples
Naive Message Board
- How to use for messaging:
- Use tx.data[0] as topic, tx.data[1] as message
- Use app logic to display messages for a topic
// data[0] = topic
// data[1] = message
if tx.data[0]:
NEXTINDEX = contract.storage[sha3(tx.data[0])]
contract.storage[sha3(tx.data[0]) + 1 + NEXTINDEX] = tx.data[1]
contract.storage[sha3(tx.data[0])] = NEXTINDEX + 1
https://gist.github.com/WeMeetAgain/10010830
Rendezvous Point
- Benefits
- Flexible in approach
- use any sort of transport
- Possibly cheaper (less blockchain editing)
- Possibility of more real-time communication
- Not limited by 1 minute block updates
- Considerations
- Transport medium (ex: WebRTC, Bitmessage, etc)
- Sync vs. Async (who needs to be online)
- storing WHO vs HOW - tradeoffs
- WHO - is less likely to change, still worrying about how
- HOW - 'Trusted' communication, but long connection times if multiple handshakes need to be exchanged
Interlude - WEBRTC
webrtc.org
- Web Real-time communications
- P2P connections from browser (native, no plugins)
- Secure communication, end-to-end encryption
- Audio, video, data connections
- Centralized component in peer discovery
Interlude - WebRTC
Connecting to a peer
Rendezvous Point - ExampleS
WHO - Friend list
- Uses ethereum address or contract to signify friend
- How to use for messaging:
- use app logic to only allow connections from 'friends'
if tx.sender != CONTRACTCREATOR:stopif tx.data[0] == 0:contract.storage[1000+tx.data[1]] = tx.data[2]elif tx.data[0] == 1:suicide(CONTRACTCREATOR)
https://gist.github.com/WeMeetAgain/10010923
Rendezvous Point - Examples
WHO - topic-group connection
- Uses ethereum address or contract for connection name/info
- How to use for messaging:
- add address to a topic
- optionally link contract to address
- use address or contract as means to initiate connections
- use application logic to only allow connections from your current topic
https://gist.github.com/WeMeetAgain/9457099
if tx.data[0] == 0: // update contractif tx.data[1] < 1000: // if the contractAddress isn't valid, stopstopcontract.storage[tx.sender] = tx.data[1]if tx.data[0] == 1: // update topicif tx.data[1] < 1000: // if the topic isn't valid, stopstopif contract.storage[tx.sender + 1]: // if address has an old topicTOPICROOT = sha3(32,contract.storage[tx.sender+1])LEN = contract.storage[TOPICROOT]INDEX = contract.storage[tx.sender + 2]// set swapped address to new index position and set address indexcontract.storage[TOPICROOT+INDEX] = contract.storage[TOPICROOT+LEN]contract.storage[contract.storage[TOPICROOT+INDEX] + 2] = INDEXcontract.storage[LEN] = 0// decrement old topic lengthcontract.storage[sha3(32,contract.storage[tx.sender + 1])] = LEN - 1TOPICROOT = sha3(32,tx.data[1])LEN = contract.storage[TOPICROOT]// add address to topic list and increment lengthcontract.storage[TOPICROOT+LEN+1] = tx.sendercontract.storage[TOPICROOT] = LEN + 1// store topic and index in list for later lookupcontract.storage[tx.sender+1] = tx.data[1]contract.storage[tx.sender+2] = LEN + 1
End
Questions, comments, corrections?
- caymannava@gmail.com
Interested in WebRTC (and making it more decentralized)?
- caymannava@gmail.com
Secure Messaging With Ethereum
By wemeetagain
Secure Messaging With Ethereum
- 1,075