The problem with secp256k1

Owned by Medha Parlikar (Unlicensed)
Last updated: Jun 07, 2018


The Requirements

  • As an ETH Node operator, I want to use my Ethereum keys for my node identity on RChain.
  • I need to generate a TLS certificate from my Ethereum keys so I can boot up my RChain node.
  • The RChain network will use the node identity as the validator identity.
  • Block proposal messages will use the same private key as communications.
  • As a node operator I only want to manage a single set of keys per node instance.


Definitions:

Node Identity: Nodes are identified by a public key address on the RChain network.  IP addresses can change, and it's important that all messages on the network be identifiable by a mechanism other than the IP address sending the message.  A public key address serves this purpose.

Validator Identity: Validators also have a public identity that is represented by a key.   Validators participating in the consensus protocol have to sign block proposal messages with their private key.  Validators bond amounts are associated with their public identity (key).


Motiviation

Reference: https://github.com/grpc/grpc-java/blob/master/SECURITY.md

Currently the best performance ALPN is delivered by OpenSSL. Support for OpenSSL is only provided for the Netty transport via netty-tcnative, which is a fork of Apache Tomcat's tcnative, a JNI wrapper around OpenSSL.
One important information about BoringSSL and netty-tcnative: It's a statically linked "uber" jar with all binaries for all supported platforms. The correct binary for the platform gets selected at runtime.(edited)
Additional informations about the versions of netty-tcnative http://netty.io/wiki/forked-tomcat-native.html

Technical issue:

The gRPC java implementation depends on netty-tcnative.  netty-tcnative uses boring-ssl as a drop in replacement for open ssl.  boring-ssl does not have an implementation of secp256k1 in it.  The functions for k1 are in the header files for boring-ssl, but the actual implementation is not included.  


There exists also a statically linked version of netty-tcnative which has binaries included for OpenSSL (only one plattform). However this version is not available from Maven (central dependencies repository). So this is a DIY version. We have built this statically linked netty-tcnative on Ubuntu 16.04TLS for all Linux systems and tested it on Ubuntu and Fedora 28
The recommended way for production systems is the dynamically linked netty-tcnative. It doesn't matter which EC curve we use. So to be clear, BoringSSL statically linked netty-tcnative-boringssl-static is not the preferred way for production systems. On the other hand it seems that everyone is using it in production because the dynamically linked version is broken.


Options:

  1. Use netty-tcnative with open ssl - dynamically linked option.  Declare open ssl as a dependency and link to it.  A file that uses C macros to do version management for open ssl has shortcomings in that it does not provide support for all the versions of open ssl that we would need.  A senior developer would need to update the C macros and validate that the multiple supported versions of open ssl all work properly on Debian, Fedora and OSX
  2. Produce a netty-tcnative jar that includes the right version of open ssl statically linked to netty-tcnative.  We could use this jar for all linux x86 64 platforms. Separate jars for OSX and Windows would be required, along with code to check the platform and dynamically load the right jar on startup
  3. Write the secp256k1 implementation for boring-ssl.  Not sure if the pull request would be accepted and merged into the project.