Cryptography Specification
Introduction
Just as arithmetic primitives are supplied to users of RhoLang, we will need to provide cryptography primitives to enable encryption, signature authentication, and hashing. Primitive cryptography operations are necessary to enable cryptocurrency applications to be build on RChain.
References:
Call out any related documents, pre-requisite documents, and documents that provide context or background.
For those that don't know what role Cryptography plays in blockchain technology, this article may help:
https://blockgeeks.com/guides/cryptocurrencies-cryptography/
Definitions:
Define any important terms or acronyms or abbreviations.
Scope
Provide a library of cryptographic primitives to be used by the RChain platform.
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:
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.
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.