Cryptography Specification

Use Cases

Digital Signature: (Public and Private Keys)

• It should be non-forgeable. No one else should be able to forge and copy your signature.
• Non-repudiation. If you have signed something with your signature, then you should not be able to take it back or claim that someone else has done it instead of you.
• Used by validators to sign a block.
• Transaction signatures
• Wallet address (new client)

New Token on RChain Network:

• Support the ability for contract authors to create different signatures from RChain to support new tokens on the RChain network.
• Similarly as above, provide support for different wallet addresses for these tokens.

Communications:

• Node communication will be signed by the Node's key
• Node communication will be encrypted, and use protobufs over UDP

Hashing:

• Block is cryptographically hashed when it is proposed
• Consensus / Validators use the hashing function to validate the block.

Node Software needs to:

• Generate Signature  – bootstrap operation when the node starts up.  Signature is used to identify the node.
• Private Key is used to sign communication.

Consensus algorithm needs:

• Sign block (indicates the version of consensus for the next block)
• Validate Block
• Validate transaction
• Create a transaction for interest / rewards

In Rholang we will need to support:

• Create Key – Create a new client
• Load Key  - Load a key
• SignTransaction
• Sign Block (Sign a transaction at the application layer) – Sign a block in Consensus
• Validate (public key) → Validates that the key is good

Design Considerations

Describe the issues which need to be addressed or resolved before attempting to devise a complete design.

Update/Upgrade

• We expect that crypto will need to be upgraded at some future point.  Must ensure this is possible to do.
• Forward compatibility – update to crypto would result in a fork of the blockchain.  

Compatibility with Ethereum

Nash Foster says: 

For Wallets: 

1. The design should make RChain keys as compatible with Ethereum keys as possible. It'd be ideal if an Ethereum key "just worked" as an RChain key without any modification. The "without any modification" part is optional, if it's impractical. If they don't just "copy over," then there should be a simple transformation to generate an RChain key from an Ethereum key. This is required by the RHOC conversion, as I understand it.
2. It should not be the case that an RChain wallet address is exactly the same as an Ethereum address, but it's possible for it to be close. I suggested having the wallet addresses be the same except that instead of starting with "0x..." we start it with "Rx..." Regardless, it must be the case that there is some way of converting an Ethereum address to an RChain address. It would be ideal if this function was reversible and if it was the case that F(E_addr) = R_addr if and only if Fkey(E) = R. And vice versa. I don't know if this is reasonable or even possible, but it would be ideal.

For Nodes:

• Network communications can be secured any way you like, as a general rule. It probably is simplest to use some form of TLS.
• In order to participate in Casper, the nodes will need keys and these keys have to stake funds and receive funds. So, at least one possibility in the networking for Casper is that the validator-to-validator communications should be secured by the same keys that staked the wallet. At least that way you know who you're talking to. However, this may be overkill, since you can tell the messages are valid based on their signatures.

Interfaces  

System Interface

• Blake2b256
  
  • hash(input: Array[Byte]): Array[Byte]
• Keccak256
  
  • hash(input: Array[Byte]): Array[Byte]
• Sha256
  
  • hash(input: Array[Byte]): Array[Byte]
• Curve25519
  
  • newKeyPair: (Array[Byte], Array[Byte])
  • newNonce: Array[Byte]
  • toPublic(sec: Array[Byte]): Array[Byte]
  • encrypt(pub: Array[Byte], sec: Array[Byte],nonce: Array[Byte], message: Array[Byte]): Array[Byte]
  • decrypt(pub: Array[Byte], sec: Array[Byte],nonce: Array[Byte], cipher: Array[Byte]): Array[Byte]
• Ed25519
  
  • newKeyPair: (Array[Byte], Array[Byte])
  • toPublic(sec: Array[Byte]): Array[Byte]
  • verify(data: Array[Byte], signature: Array[Byte], pub: Array[Byte]): Boolean
  • sign(data: Array[Byte], sec: Array[Byte]): Array[Byte]
• Secp256k1
  
  • secKeyVerify(seckey: Array[Byte]): Boolean
  • toPublic(sec: Array[Byte]): Array[Byte]
  • verify(data: Array[Byte], signature: Array[Byte], pub: Array[Byte]): Boolean
  • sign(data: Array[Byte], sec: Array[Byte]): Array[Byte]

Software Interface

Within the Rholang Language.

The following methods will be made available to contract authors.  

• secp256k1.verify
• ed25519.verify
• curve25519.encrypt
• sha256.hash
• keccak256.hash
• blake2b256.hash

Communications Interface

Chris Kirkwood-Watts - I don't think we have any dependencies. 

Architectural Strategies

There is a design consideration around being able to upgrade the cryptography of the RChain platform.   Delivering a single library with all the cryptographic functions is desirable. 

System Architecture

• With Roscala, we would have to include the library as part of Roscala, and then create primitives to expose to Rholang.
• Create a FFI and expose to VM and communications?
• Need to research the implications for upgrade-> VM Prims versus FFI & Library.