mattrglobal / node-bbs-signatures Goto Github PK

Error: internal error in Neon module: Index is out of bounds. Must be between 0 and 1: 2

Can be observed running the tests in this PR: #62

The blindSign API support an signer issuing an assertion where some of the messages are blinded from them, this is required for "linked secret" based subject authentication of assertions.

This API should be tested and exposed from the package along with the APIs associated to preparing the blinded messages.

Add in the automated release process and associated docs

Generated signatures appears to have zero padding within the signature, see this example base64 encoded.

BBkDTwJ6H3LLVd9wf/p5X4ZzNnFJ7usnbzxmcjcSxF2t+VWcqq6a8JYAYLeAwB0tMwi/Tu1cROZ2ioBDh0+HoV2Aj8UIYxLa5fZn1E0hLzeQadURmI7nqtofopMnXeRG8gAAAAAAAAAAAAAAAAAAAAAAxXagffQjZCCLLPu9m/8/OEl/nSNsArq30nY2hgqmYAAAAAAAAAAAAAAAAAAAAABEhciXgV9wG+MOrEb4vkFPdDGae+wIIzRJhJjKK2B7ng==

Currently because the unstable release process requires the rust to compile the native module this is included in the package.json, however the stable release process does not need to include this, so it should be deleted.

We use sonar cloud on some of our other repositories which we could elect to use here

Request to add apple silicon arm64 builds for this package to support builds on such systems.

Additionally, building a binary locally and trying to link it in a react-native project produces a further error
ld: in /Users/preetpatel/Developer/project/ios/Pods/bbs-signatures/wrappers/obj-c/libraries/libbbs.a(absvdi2.o), building for iOS Simulator, but linking in object file built for iOS, file '/Users/preetpatel/Developer/project/ios/Pods/bbs-signatures/wrappers/obj-c/libraries/libbbs.a' for architecture arm64

Github actions as of today does not have Apple Silicon Mac build environments available so we'd have to look into manual releases or utilising a third party build server

Create a samples directory that shows how to use this libraries api.

Currently in our tests we have fix constants for proof sizes hard coded to tests, instead we should have a utility function that is able to calculate the expected proof size and this should be used instead. The equation for calculating the expected proof size is here

Currently neon throws a uniform exception back to the node side and it is swallowed by the wrapper, meaning the consumer or call of the API does not get important details about the errors scope, we need to install a uniform error handling approach that gives this missing detail in a consistent manner

To track test coverage within the project, enable codecov reporting on PR's and analysing the head of master

Add benchmarking for the create and verify proof api's

Hello, I have a question about BBS+ signature performance.
As I watched Mattr youtube and node-bbs-signatures github, I saw some comparing tables about BBS+ and CL signature.
(And also saw envernym blog post about why they moved from cl signature to bbs+)
I understand CL Signature is based on RSA so the key size or other opertaions(signing, verifying, etc) are very large and slow.

So my question is below :
I want to know how Mattr test the performance of BBS+ and CL signature. Is there a paper or a presentation you can share? Performance like Key Generation, Signing, Verifying, Proof Generation.

Thanks!

Hi Team,
We see below error while installing node-bbs-signatures in windows.. Looks like there is no tarball for windows (node-v83-win32-x64.tar.gz) at the location https://github.com/mattrglobal/node-bbs-signatures/releases/

Is there a plan to release a tarball for windows or is there an alternate way to make it work on windows?

------> Logs<-------
node-pre-gyp ERR! cwd C:\UserSpace\Sources\src\lib\node_modules@mattrglobal\node-bbs-signatures
node-pre-gyp ERR! node -v v14.17.5
node-pre-gyp ERR! node-pre-gyp -v v0.17.0
node-pre-gyp ERR! not ok
404 status code downloading tarball https://github.com/mattrglobal/node-bbs-signatures/releases/download/0.12.0/node-v83-win32-x64.tar.gz
npm WARN [email protected] No repository field.
npm WARN [email protected] No license field.
npm ERR! code ELIFECYCLE

When publishing the package on NPM the readme is not being detected

Generated private keys appear to have an all zero prefix padding, see this example base64 encoded.

AAAAAAAAAAAAAAAAAAAAAFutvcqd+rMKit2/lHuUBrarW0MQHYXEhdwRiDAWF6xU1

In order to support bound signatures we must support generating key pairs in G1

Given this deals with cryptography, it would be good for us to make it easy for security researchers to responsibly disclose any discovered vulnerabilities.

Currently the bbs crate is referenced using a commit ref on a feature branch, once the crate is released, this reference should be updated.

With a BBS+ signature we are able to compress its format if we are willing to recompute y in order to recompute A, we can also save space by remove the padding from the e and the s components of the signature.

This compressed form will mean BBS+ signatures resulting length would be

48 Bytes- X
32 Bytes- E
32 Bytes- S

A total length of 112 Bytes.

node-pre-gyp http GET https://github.com/mattrglobal/node-bbs-signatures/releases/download/0.15.0/node-v108-win32-x64.tar.gz
node-pre-gyp ERR! install response status 404 Not Found on https://github.com/mattrglobal/node-bbs-signatures/releases/download/0.15.0/node-v108-win32-x64.tar.gz

When running yarn build I receive the following error:

yarn run v1.21.1
$ yarn build:neon && yarn build:ts
$ neon build --release
neon info running cargo
error: failed to parse lock file at: /Users/kyle/Dev/demo/node-bbs-signatures/native/Cargo.lock

Caused by:
  invalid serialized PackageId for key `package.dependencies`
neon ERR! cargo build failed

Error: cargo build failed
    at Target.<anonymous> (/Users/kyle/Dev/demo/node-bbs-signatures/node_modules/neon-cli/lib/target.js:121:35)
    at step (/Users/kyle/Dev/demo/node-bbs-signatures/node_modules/neon-cli/lib/target.js:32:23)
    at Object.next (/Users/kyle/Dev/demo/node-bbs-signatures/node_modules/neon-cli/lib/target.js:13:53)
    at fulfilled (/Users/kyle/Dev/demo/node-bbs-signatures/node_modules/neon-cli/lib/target.js:4:58)
    at process._tickCallback (internal/process/next_tick.js:68:7)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Because the GH workflow that runs on all PR's runs across different node environments, the test coverage reporting is being done per-node environment, rather than once.

libzmix in ursa is actually going to be broken apart into several smaller crates therefore this repository wont wrap all of zmix, rather only the functionality required to achieve bbs signatures.

Release builds only require the index.node file from the native directory

Hi,

I have set up a test repo to try out BBS+, when trying to verify a derived proof I am getting the following error:

Error: internal error in Neon module: called `Result::unwrap()` on an `Err` value: \"BBSError { inner: \\n\\n\\n\\nThe proof failed due to a revealed message was supplied that was not signed or a message was revealed that was initially hidden }\"\n

From what I gather, this is coming from the native node build.

The error does not help me much to understand what I am doing wrong (ie: what was revealed that shouldn't have been, etc).

I am basically replicating what's in the example: https://github.com/mattrglobal/jsonld-signatures-bbs/blob/master/sample/ts-node/src/demo_single.ts, so at first it does not look wrong.

How could I debug what's going on?

Thanks

Currently the top level API for this library requires the input messages to be an array of strings, this should be changed to be an array of byte arrays.

All generated signatures with sign() are outputting those of length 193 rather than the expected 192. See the bbs signature tests.

Add some content that describes BBS signatures in general and more specifically the modifications we have made to how the generator values are generated.

Hello 👋

Opening this issue as a follow-up of transmute-industries/verifiable-data#172

It's related to #182 and #181

Any ideas or suggestions on how to approach these?

Hi, im looking in ways to protect user privacy in verifiable credentials.

In W3C vc data model, they are suggesting selective disclosure as a solution and the algorithm was bbs+.

I tested selective disclosure with BbsBlsSignature2020,BbsBlsSignatureProof2020 which I really thanks to mattr!
When it comes to identifier-based correlation privacy consideration, as i searched about it,
BbsBlsBoundSignature2020,BbsBlsSignatureBoundProof2020 can be used.
I saw bbs+ explained(part1, part2) in mattr youtube channel.

But i can't find any test code about BbsBlsBoundSignature2020,BbsBlsSignatureBoundProof2020.
And also i think commitmentForBlindSignRequest, verifyBlindSignContext, blindSign is related but can't find any test code.

So my question is this.

• AreBbsBlsBoundSignature2020,BbsBlsSignatureBoundProof2020 in progress?
• Is commitmentForBlindSignRequest, verifyBlindSignContext, blindSign for BbsBlsBoundSignature2020,BbsBlsSignatureBoundProof2020?
• What is the difference of boundSignature and blindSignature?

Thanks!

When changing between installed versions of node-bbs-signatures it appears that the native node module './index.node' is not always being downloaded and updated by node-pre-gyp leading to issues, especially when changing between versions of the library that feature breaking API changes.

How to reproduce

Start with new empty project and install node-bbs-signatures

yarn add @mattrglobal/[email protected]

Then run the following

node
require("./node_modules/@mattrglobal/node-bbs-signatures/native/index.node")

Which will output

{ bls_generate_blinded_g2_key: [Function],
  bls_generate_blinded_g1_key: [Function],
  bls_generate_g2_key: [Function],
  bls_generate_g1_key: [Function],
  bls_secret_key_to_bbs_key: [Function],
  bls_public_key_to_bbs_key: [Function],
  bbs_sign: [Function],
  bbs_verify: [Function],
  bbs_blind_signature_commitment: [Function],
  bbs_verify_blind_signature_proof: [Function],
  bbs_blind_sign: [Function],
  bbs_get_unblinded_signature: [Function],
  bbs_create_proof: [Function],
  bbs_verify_proof: [Function],
  bls_verify_proof: [Function] }

Now change the installed version of the package

yarn add @mattrglobal/[email protected]

And run

node
require("./node_modules/@mattrglobal/node-bbs-signatures/native/index.node")

Note the output

{ bls_generate_blinded_g2_key: [Function],
  bls_generate_blinded_g1_key: [Function],
  bls_generate_g2_key: [Function],
  bls_generate_g1_key: [Function],
  bls_secret_key_to_bbs_key: [Function],
  bls_public_key_to_bbs_key: [Function],
  bbs_sign: [Function],
  bbs_verify: [Function],
  bbs_blind_signature_commitment: [Function],
  bbs_verify_blind_signature_proof: [Function],
  bbs_blind_sign: [Function],
  bbs_get_unblinded_signature: [Function],
  bbs_create_proof: [Function],
  bbs_verify_proof: [Function],
  bls_verify_proof: [Function] }

Which is incorrect for the 0.9.0 package which did not feature blinded key generation support and the function bls_generate_g2_key was instead called bls_generate_key

Intermediary Solution

It is recommended when changing between installed versions of the library to uninstall and reinstall the library at the new targeted version to ensure the correct native node module is downloaded.

I'd think only maintainers need to be aware of the manual release process for this which would be our team. I'd think we could remove this section of the documents.

Thoughts?

Does not appear to be such a binary: https://github.com/mattrglobal/node-bbs-signatures/releases/download/0.13.0/node-v102-darwin-arm64.tar.gz

Is it possible to get one?

npm WARN deprecated [email protected]: Please upgrade to @mapbox/node-pre-gyp: the non-scoped node-pre-gyp package is deprecated and only the @mapbox scoped package will recieve updates in the future
npm ERR! code 1
npm ERR! path /Users/gcohen/Development/verifiable-data/node_modules/@mattrglobal/node-bbs-signatures
npm ERR! command failed
npm ERR! command sh -c node-pre-gyp install --fallback-to-build=false
npm ERR! 404 status code downloading tarball https://github.com/mattrglobal/node-bbs-signatures/releases/download/0.13.0/node-v102-darwin-arm64.tar.gz
npm ERR! node-pre-gyp info it worked if it ends with ok
npm ERR! node-pre-gyp info using [email protected]
npm ERR! node-pre-gyp info using [email protected] | darwin | arm64
npm ERR! node-pre-gyp WARN Using request for node-pre-gyp https download
npm ERR! node-pre-gyp info check checked for "/Users/gcohen/Development/verifiable-data/node_modules/@mattrglobal/node-bbs-signatures/native/index.node" (not found)
npm ERR! node-pre-gyp http GET https://github.com/mattrglobal/node-bbs-signatures/releases/download/0.13.0/node-v102-darwin-arm64.tar.gz
npm ERR! node-pre-gyp http 404 https://github.com/mattrglobal/node-bbs-signatures/releases/download/0.13.0/node-v102-darwin-arm64.tar.gz
npm ERR! node-pre-gyp ERR! install error
npm ERR! node-pre-gyp ERR! stack Error: 404 status code downloading tarball https://github.com/mattrglobal/node-bbs-signatures/releases/download/0.13.0/node-v102-darwin-arm64.tar.gz
npm ERR! node-pre-gyp ERR! stack     at Request.<anonymous> (/Users/gcohen/Development/verifiable-data/node_modules/node-pre-gyp/lib/install.js:142:27)
npm ERR! node-pre-gyp ERR! stack     at Request.emit (node:events:532:35)
npm ERR! node-pre-gyp ERR! stack     at Request.onRequestResponse (/Users/gcohen/Development/verifiable-data/node_modules/request/request.js:1059:10)
npm ERR! node-pre-gyp ERR! stack     at ClientRequest.emit (node:events:520:28)
npm ERR! node-pre-gyp ERR! stack     at HTTPParser.parserOnIncomingClient [as onIncoming] (node:_http_client:618:27)
npm ERR! node-pre-gyp ERR! stack     at HTTPParser.parserOnHeadersComplete (node:_http_common:128:17)
npm ERR! node-pre-gyp ERR! stack     at TLSSocket.socketOnData (node:_http_client:482:22)
npm ERR! node-pre-gyp ERR! stack     at TLSSocket.emit (node:events:520:28)
npm ERR! node-pre-gyp ERR! stack     at addChunk (node:internal/streams/readable:324:12)
npm ERR! node-pre-gyp ERR! stack     at readableAddChunk (node:internal/streams/readable:297:9)
npm ERR! node-pre-gyp ERR! System Darwin 21.3.0
npm ERR! node-pre-gyp ERR! command "/opt/homebrew/Cellar/node/17.4.0/bin/node" "/Users/gcohen/Development/verifiable-data/node_modules/.bin/node-pre-gyp" "install" "--fallback-to-build=false"
npm ERR! node-pre-gyp ERR! cwd /Users/gcohen/Development/verifiable-data/node_modules/@mattrglobal/node-bbs-signatures
npm ERR! node-pre-gyp ERR! node -v v17.4.0
npm ERR! node-pre-gyp ERR! node-pre-gyp -v v0.17.0
npm ERR! node-pre-gyp ERR! not ok

See mattrglobal/jsonld-signatures-bbs#35 we need to expand the push-release pipelines list of published binaries.

What is default behavior of for blsVerifyProof function, when list of messages contains reveled messages and some additional messages in the end?

Just an example

import {
  generateBls12381G2KeyPair,
  blsSign,
  blsVerify,
  blsCreateProof,
  blsVerifyProof,
} from "@mattrglobal/node-bbs-signatures";

const main = async (): Promise<void> => {
  //Generate a new key pair
  const keyPair = await generateBls12381G2KeyPair();

  console.log("Key pair generated");
  console.log(`Public key base64 = ${Buffer.from(keyPair.publicKey).toString("base64")}`);

  //Set of messages we wish to sign
  const messages = [
    Uint8Array.from(Buffer.from("message1", "utf-8")),
    Uint8Array.from(Buffer.from("message2", "utf-8")),
    Uint8Array.from(Buffer.from("message3", "utf-8")),
  ];

  console.log("Signing a message set of " + messages);

  //Create the signature
  const signature = await blsSign({
    keyPair,
    messages: messages,
  });

  console.log(`Output signature base64 = ${Buffer.from(signature).toString("base64")}`);

  //Verify the signature
  const isVerified = await blsVerify({
    publicKey: keyPair.publicKey,
    messages: messages,
    signature,
  });

  const isVerifiedString = JSON.stringify(isVerified);
  console.log(`Signature verified ? ${isVerifiedString}`);

  //Derive a proof from the signature revealing the first message
  const proof = await blsCreateProof({
    signature,
    publicKey: keyPair.publicKey,
    messages,
    nonce: Uint8Array.from(Buffer.from("nonce", "utf-8")),
    revealed: [0],
  });

  console.log(`Output proof base64 = ${Buffer.from(proof).toString("base64")}`);

  const additionalMessages = [
    Uint8Array.from(Buffer.from("message4", "utf-8")),
    Uint8Array.from(Buffer.from("message5", "utf-8")),
  ];
  console.log( messages.slice(0, 2).concat(additionalMessages))
  //Verify the created proof
  const isProofVerified = await blsVerifyProof({
    proof,
    publicKey: keyPair.publicKey,
    messages: messages.slice(0, 2).concat(additionalMessages),
    nonce: Uint8Array.from(Buffer.from("nonce", "utf-8")),
  });

  const isProofVerifiedString = JSON.stringify(isProofVerified);
  console.log(`Proof verified ? ${isProofVerifiedString}`);
};

main();

Then, if it is default behavior, does it make sense to add some notes in README.md and add a test for it?

Add some typescript examples to the readme on how to use this library.

Document how the binaries for the different node environments are created with github work flows and published to github which are then fetched during package install via node-pre-gyp

Switch over the package management to use npm on public packages.

neon-bindings on windows node 11 appears to have an issue that prevents successful compilation hence preventing us from publishing a node 11 version on windows. More investigation is required into whether it is a particular minor version of node 11 or is an issue with the major release

See mattrglobal/bbs-signatures#47 for more details

Use husky to enforce commit format so that automatic change log generation can be done based on the commit messages