2018-06-18 Meeting notes: secp256k1 sync on next steps

• Just to be on the same page with secp256k1 and netty-tcnative with OpenSSL:      

macOS: The official dynamically linked netty-tcnative from Maven works fine

Linux: The official dynamically linked (against OpenSSL) netty-tcnative from Maven doesn't work at all. We can however contribute to the netty-tcnative project and make it work. The problem manifests only in the official release because they try to be backward-compatible with older versions of OpenSSL. When compiled from sources against the right version of OpenSSL the dynamically linked version should work. It works for me on Ubuntu 16.04, compiled against OpenSSL 1.0.2. It did not work for me on Fedora 28, compiled against OpenSSL 1.1.0. There are no official statically linked versions of netty-tcnative on Maven. They have to be compiled from sources, what I did. The same statically linked netty-tcnative jar works on Ubuntu and on Fedora. I didn't test it on Debian (or other distros), but I think that it will work too.

MS Windows: No information collected so far.          

• RISK - If we just use TLS for encryption, then you can't know if you've been man in the middled

• QUESTION - What does it meant that the validators have a sec256k1 public key? Where did it come from?
  • Validators generate it themselves
  • It is part of participating in the Ethereum network
  • These validators would like to continue to use this key on the RChain platform
  • Where did this requirement come from?
    • Michael Stay (Unlicensed) to check with Nash
• DECISION At a minimum we do want to support secp256k1 for wallets
  • If the software supports this, then why can't it also support using it as a validator key?
• Supporting secp256k1 for TLS adds complexity to the design
  • QUESTION do we need it?
    • Michael Stay (Unlicensed) follow up with Nash on why he wants this
    • It is standard practice to keep keys separate for separation of concerns
    • IDEA 
      • Node identity use r1 and validators use k1
      • OR use ed25519 for TLS and node identities, and use secp256k1 for wallets
        • No point in using r1 if we can't achieve compatibility
• Sebastian does have a working solution for k1, but it requires Open SSL statically linked library
  • This is no good! We cannot ship statically linked crypto to certain countries
  • To achieve a weak link to Open SSL, we would need to submit an update to netty-tcnative
• REQUIREMENTS
  • We have to support secp256k1 on the blockchain in Rholang and wallets
    • This is critical for RHOC/REV swap and to be supported until Venus
    • After Venus, we will not need to continue to support
  • For TLS Kyle's recommendation is to use ed25519 
    • Validators keep or create their secp256k1 keys
  • Node identifier
    • Currently using a hash of the Ethereum public key
    • Node ID should be the key used for signing Casper messages (Kyle)
      • Node ID happens at a very low level well before a Casper message (Pawel)
    • IDEA Reimplementing the original handshake protocol will achieve this 
      • Issues two keys: 1) transport key (do not need to store) and 2) Casper key (must be stored)
      • Should handshake be two phases?
        • Phase 1 Node A: Hi, this my public key! 
        • Phase 2 Node B: Hi, this is my public key! Now they are connected.
• QUESTION - If we have two different algorithms, is there a risk of collision of the signing keys?
  • No, because you tag them

• Proposed work flow
  • Start node
  • Node establishes TLS connection (no one cares what protocol or certificate is used)
  • When you want to send a message, you have to sign using the TLS parameters with an identity Casper will use
  • If you want to say you're a validator, you need to sign TLS parameters with the other node's public key
    • Concern that all TLS happens under the hood and access through API may be difficult
      • May be possible to do using the intercepter feature
• Question about using and getting the TLS parameters
  • TLS gets established (this is the key Casper will use)
  • Get info about the connection
  • Sign it using the validator key
  • This is the first message sent
• DECISION extend the first message protocol and have TLS intercepter to validate