Versions Compared

Old Version 1

changes.mady.by.user Medha Parlikar

Saved on

compared with

New Version Current

changes.mady.by.user Medha Parlikar

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.