feat: implement ECDH

[YashBit]

Description

ECDH Implementation with NoirJS for writing tests.
See ecdh.tests.js in the package.

Here is a detailed description for a GitHub Pull Request (PR) that covers the provided code:

---

Summary

This PR introduces a set of functions and utilities for elliptic curve cryptography using the Baby JubJub curve. It includes functionality to convert byte arrays to field elements, generate public keys from private keys, and compute shared keys for the Elliptic Curve Diffie-Hellman (ECDH) protocol. The code also provides a main function for generating ECDH shared keys and includes initial placeholders for testing.

Details

1. Function: field_from_bytes

   • Description: Converts a fixed-size byte array to a field element.
   • Arguments:
     • bytes: A fixed-size array of 32 bytes that represents the data to be converted.
     • big_endian: A boolean flag indicating if the byte array is in big-endian format. If true, the conversion uses big-endian ordering; otherwise, it uses little-endian ordering.
   • Returns: A Field element that represents the converted byte array.
   • Implementation:
     • Initializes the as_field and offset variables.
     • Iterates over the byte array, calculating the field element based on the byte values and their respective offsets.
     • Supports both big-endian and little-endian byte orders.

2. Function: generate_public_key

   • Description: Generates a public key from a private key using the Baby JubJub curve.
   • Arguments:
     • private_key: A Field element representing the private key.
     • base_point: A Point on the Baby JubJub curve used as the base point for the generation of the public key.
   • Returns: A Point on the Baby JubJub curve representing the public key.
   • Implementation:
     • Creates an instance of the Baby JubJub curve with predefined parameters.
     • Computes the public key by performing scalar multiplication of the private key with the base point.

3. Function: main

   • Description: Computes ECDH shared keys based on two private keys and validates their equality.
   • Arguments:
     • private_key1 and private_key2: Arrays of 32 bytes representing the private keys.
   • Implementation:
     • Defines a base point on the Baby JubJub curve.
     • Converts the private keys from byte arrays to Field elements.
     • Generates public keys for each private key.
     • Computes shared keys using the ECDH protocol.
     • Asserts that the computed shared keys are equal, validating the correctness of the ECDH operation.

4. Tests

   • Description: Placeholder functions for testing.
   • Included Tests:
     • field_from_bytes_correct: Tests the field_from_bytes function to ensure correct conversion of a byte array to a field element.
   • Note: The test functions are currently commented out and need to be implemented with actual test cases and expected values.

Changes Made

• Added utility functions for converting byte arrays to field elements and generating public keys.
• Implemented the main function for computing ECDH shared keys and validating their equality.
• Included placeholder test functions for field_from_bytes and generate_public_key functions.

To Do

• Implement the actual test cases for the placeholder test functions.
• Validate the correctness of the generate_public_key function with real inputs.
• Ensure all functions and tests are correctly integrated and working as expected.

[sripwoud]

Hi,

Thanks for submitting this well described PR!
I'd like to wait for @signorecello to review cause I don't write noir myself.

In the meantime could you ensure the style ci check pass?

[YashBit]

@sripwoud Requested changes made.

@cedoor Will implemented the new curves you requested soon *

I would appreciate it if you could comment on the integration and the unit tests. Will add those as soon as * is completed.

[cedoor]

@YashBit

@cedoor Will implemented the new curves you requested soon *

👍🏽

I would appreciate it if you could comment on the integration and the unit tests. Will add those as soon as * is completed.

Re integration tests. I think there're not actual tests actually. You're just generating a proof without verifying it.

Looks like there's a function to verify proofs in the Noir tools: https://github.com/noir-lang/noir/blob/master/tooling/noir_js_backend_barretenberg/src/backend.ts#L127

[signorecello]

Some suggestions and requests, great work @YashBit !

[signorecello]

It's a bit confusing that this is a lib but has a main function, can this be renamed? Something like generate_shared

[sripwoud]

I think here we need to have a main function and a package of type bin, don't we @signorecello?
Because we do want to compile something: we need the compilation artifact for the node test.

Or is there another way?

[signorecello]

I mean we shouldn't name libraries according to their use in tests... For the node test we would actually write a bin project and compile that one

[signorecello]

@YashBit saw you resolved this one, but idk what's your opinion

[sripwoud]

tACK

ran locally: yarn test and yarn check

CI is broken (see #12).
capture: include mocha tests in ci see #13

[signorecello]

Just wanted to know your opinion on the naming, other than that it looks good to go

[signorecello]

I mean we shouldn't name libraries according to their use in tests... For the node test we would actually write a bin project and compile that one

[signorecello]

@YashBit saw you resolved this one, but idk what's your opinion

[sripwoud]

All my comments have be addressed. We now have a cleaner mocha/nargo tests setup. Local scripts are working.

But the CI is broken: the lockfile looks out of date.

@YashBit yarn.lock is out of date because you modified dependencies by editing manually package.json
It is better to use yarn add for that purpose as it will always update the yarn.lock accordingly.
(And I am sure you didn't use yarn add because the deps in package.json aren't sorted 😉)

Can you please bump the lockfile (trash it together with node_modules then re install deps, then push your changes)

EDIT: fixed in 116894c

[YashBit]

Just wanted to know your opinion on the naming, other than that it looks good to go

@signorecello I think what I have done makes sense

We have a main.nr file, which is required for the nargo compile, and we have a separate lib.nr file which contains all the functions (which is in fact imported by main.nr)

Without a main.nr file + a pub fn main, there will no circuit and no integrated tests.

[cedoor]

Let's merge this PR. Naming and other issues can be part of another PR in case.

#15