VRF implementation

[dcoutts]

This is the tracking ticket for the VRF crypto implementation to be used in Praos.

Needed for input-output-hk/ouroboros-network#261.

For those able to access it, the requirement discussion is here https://jira.iohk.io/browse/CDT-59

The algorithm we have chosen ​is ECVRF-ED25519-SHA512-Elligator2 as described in the draft IETF specification https://tools.ietf.org/html/draft-irtf-cfrg-vrf-06.

We have verified with the Ouroboros Praos authors and our internal crypto auditors that this is a suitable algorithm choice for Praos -- provided that the validation in the IETF spec section 5.6 is done.

The underlying implementation we have chosen is the implementation by the Algorand, as implemented in their fork of the libsodium library https://github.com/algorand/libsodium/tree/draft-irtf-cfrg-vrf-03/src/libsodium/crypto_vrf

Our internal crypto auditors have reviewed this implementation and are satisfied that it implements ECVRF-ED25519-SHA512-Elligator2 as described in the IETF draft, and are satisfied that it performs the extra validation checks from section 5.6 that are required for the use in the context of Praos.

The strategy to integrate is to implement a Haskell FFI binding to the VRF C code and use that binding library to instantiate the existing crypto class being used by consensus.

Tasks

• [x] decide where the binding code should live
• [x] establish and check the feasibility of the relationship between the C API and the target Haskell API
• [x] establish how to compile and link against the libsodium fork

Actual implementation split off into separate tickets:

• initial FFI binding (#110)
• match up against the target VRF type class (#110)
• make any necessary changes to the VRF type class and uses (#110)
• first working integration (#111)
• memlock safety (#112)

[tdammers]

Compiling & linking, remaining sub-tasks:

• move our fork somewhere more reasonable
• document its existence and how to install it
• instrument nix build setup to fetch, build, and use the fork

[i-o-m]

@tdammers and @nc6 Hi Tobias and Nick, could we please make sure to break down development and other tasks into separate GitHub issues. We need this to give visibility of activities within a Sprint.

Could you please also create a new label 'Cryto' to label all tickets.

[tdammers]

Ticket / tasks split up into #110, #111, #112.