elliptic-curve cryptography

Library to work with elliptic-curve cryptography based on libsodium and blst.

| Bindings | | | |------------|-------------------------------|--------------------------------------------------------------------------------------------------------------------------------------| | Java | jvm/ecc | | | Javascript | js/ecc | | | Python | python/ecc | |

Features

OPRF
OPAQUE
Two-Round Threshold Schnorr Signatures with FROST
Ethereum BLS Signature
BLS12-381 Pairing
Proxy Re-Encryption (PRE)
Cryptographic primitives and utilities

OPRF Oblivious pseudo-random functions

This is an implementation of draft-irtf-cfrg-voprf-21 ciphersuite OPRF(ristretto255, SHA-512) using libsodium.

An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between client and server for computing the output of a Pseudorandom Function (PRF). The server provides the PRF secret key, and the client provides the PRF input. At the end of the protocol, the client learns the PRF output without learning anything about the PRF secret key, and the server learns neither the PRF input nor output.

There are two variations of the basic protocol:

VOPRF: is OPRF with the notion of verifiability. Clients can verify that the server used a specific private key during the execution of the protocol.
POPRF: is a partially-oblivious VOPRF that allows clients and servers to provide public input to the PRF computation.

The OPRF flow is shown below (from the IRTF draft):

    Client(input)                                        Server(skS)
  -------------------------------------------------------------------
  blind, blindedElement = Blind(input)

                             blindedElement
                               ---------->

                evaluatedElement = BlindEvaluate(skS, blindedElement)

                             evaluatedElement
                               <----------

  output = Finalize(input, blind, evaluatedElement)

For the advanced modes VOPRF and POPRF refer to the published draft.

OPAQUE The OPAQUE Asymmetric PAKE Protocol

This is an implementation of draft-irtf-cfrg-opaque-12 using libsodium.

OPAQUE consists of two stages: registration and authenticated key exchange. In the first stage, a client registers its password with the server and stores its encrypted credentials in the server, but the server never knows what the password is.

The registration flow is shown below (from the IRTF draft):

       creds                                   parameters
         |                                         |
         v                                         v
       Client                                    Server
       ------------------------------------------------
                   registration request
                ------------------------->
                   registration response
                <-------------------------
                         record
                ------------------------->
      ------------------------------------------------
         |                                         |
         v                                         v
     export_key                                 record

In the second stage, the client outputs two values, an "export_key" (matching that from registration) and a "session_key". The server outputs a single value "session_key" that matches that of the client.

The authenticated key exchange flow is shown below (from the IRTF draft):

       creds                             (parameters, record)
         |                                         |
         v                                         v
       Client                                    Server
       ------------------------------------------------
                      AKE message 1
                ------------------------->
                      AKE message 2
                <-------------------------
                      AKE message 3
                ------------------------->
      ------------------------------------------------
         |                                         |
         v                                         v
   (export_key, session_key)                  session_key

The public API for implementing the protocol is:

Client

opaque_ristretto255_sha512_CreateRegistrationRequest
opaque_ristretto255_sha512_FinalizeRequest
opaque_ristretto255_sha512_3DH_ClientInit
opaque_ristretto255_sha512_3DH_ClientFinish

Server

opaque_ristretto255_sha512_CreateRegistrationResponse
opaque_ristretto255_sha512_3DH_ServerInit
opaque_ristretto255_sha512_3DH_ServerFinish

Two-Round Threshold Schnorr Signatures with FROST

This is an implementation of draft-irtf-cfrg-frost-13 using libsodium.

The draft presents a two-round signing variant of FROST, a Flexible Round-Optimized Schnorr Threshold signature scheme. FROST signatures can be issued after a threshold number of entities cooperate to issue a signature, allowing for improved distribution of trust and redundancy with respect to a secret key.

Unlike signatures in a single-party setting, threshold signatures require cooperation among a threshold number of signers each holding a share of a common private key. The security of threshold schemes in general assume that an adversary can corrupt strictly fewer than a threshold number of participants.

This implementation follows the trusted dealer key generation documented in the Appendix B of the draft using Shamir and Verifiable Secret Sharing.

Ethereum BLS Signature

Ethereum uses BLS signatures as specified in the IETF draft draft-irtf-cfrg-bls-signature-05 ciphersuite BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_RO_POP_.

This library provides the following API:

ecc_sign_eth_bls_KeyGen
ecc_sign_eth_bls_SkToPk
ecc_sign_eth_bls_KeyValidate
ecc_sign_eth_bls_Sign
ecc_sign_eth_bls_Verify
ecc_sign_eth_bls_Aggregate
ecc_sign_eth_bls_FastAggregateVerify
ecc_sign_eth_bls_AggregateVerify

BLS is a digital signature scheme with aggregation properties that can be applied to signatures and public keys. For this reason, in the context of blockchains, BLS signatures are used for authenticating transactions, votes during consensus protocols, and to reduce bandwidth and storage requirements.

BLS12-381 Pairing

In the context of pairing friendly elliptic curves, a pairing is a map e: G1xG2 -> GT such that for each a, b, P and Q

e(a * P, b * Q) = e(P, Q)^(a * b)

You can use this to obtain such pairings:

// c code, for a very similar java code, look at the unit tests
byte_t a[ecc_bls12_381_SCALARSIZE];
byte_t b[ecc_bls12_381_SCALARSIZE];
ecc_bls12_381_scalar_random(a);
ecc_bls12_381_scalar_random(b);

byte_t aP[ecc_bls12_381_G1SIZE];
byte_t bQ[ecc_bls12_381_G2SIZE];

ecc_bls12_381_g1_scalarmult_base(aP, a); // a * P
e

Ecc

Install / Use

README