feat(eddsa-poseidon): adds Blake2s hashing for eddsa and conditional imports

[hannahredler]

Description

Current implementation of the EdDSA Poseidon uses the Blake-1 hashing algorithm. This PR implements Blake2b algorithm and conditional imports such that the user can choose to use a different hashing algorithm if required.

Related Issue(s)

Partially Closes #152
Adds the first optional hashing algorithm

Other information

The implementation of Blake2b is based on this one, migrated to Typescript and changed to a class structure to mirror the Blake1 implementation. The test cases were lifted directly from the repo to ensure consistent output.

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• I have run yarn style without getting any errors
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[hannahredler]

@cedoor @artwyman the only thing I haven't managed to get to work is to import the sub packages from outside the project and check they import correctly, after running yarn build. If you could direct me in the best way to ensure this works, I can validate that

[artwyman]

I don't think I have the time or expertise to review this in detail, but here are a few design discussion points to consider from the point of view of 0xPARC's projects (Zupass and PODs) making use of this library, which might be a reasonable stand-in for

• I think it's important the packaging allow for avoiding the cost of the unused hashing options here. E.g. if I need only blake-1, and I structure my imports appropriately, I shouldn't see the size impact of blake-2b in my bundle (and vice versa), similar to the way the poseidon-lite module works for different sizes.
• Adding more hash options definitely seems good. Changing the default in particular is something to consider carefully, due to its impact on existing users, and the validity of their existing signed data. It's certainly very much a breaking change, and could cause compatibility headaches for any developer who doesn't notice it's happened. It should certainly be reflected in the semantic version, and I might go so far as to change the TypeScript interface so as to explicitly break existing code which doesn't get hand updated. I think it would be safer to add blake-2b as an option, but leave the default as-is.

For Zupass in particular, we have existing tickets and PODs signed using the blake-1 variant so we're unlikely to switch anytime soon, and would have to introduce some new version/config fields in our formats in order to do so. I'd expect SemaphoreV4 to be in a similar situation where they care very much about compatibility.

I'd be interested to hear the advantages of blake-2b so as to think carefully about when an upgrade might be warranted. Are there known vulnerabilities in blake-1? Is blake-2b stronger, faster, or superior in some other way?

[hannahredler]

Thanks for the comment @artwyman.

As far as I understand it, Blake2 is optimised to be faster and more efficient, whilst reliably offering a similar level of security. Thus if changing it could cause a headache down the line, I agree that it might be better to keep it as an option rather than changing the default, and this can always be a decision that is easily taken later.

In terms of bundle size, I have structured the code to only return the compiled version of the chosen algorithm, so that should be working as intended.

[cedoor]

Hey @hannahredler, thanks for this PR!

I added some comments 👍🏽

[hannahredler]

@cedoor comments addressed - ready for re-review 👍

[cedoor]

LGTM, just two comments before merging!

[gitpoap-bot]

Congrats, your important contribution to this open-source project has earned you a GitPOAP!

GitPOAP: 2024 ZK-KIT Contributor:

Head to gitpoap.io & connect your GitHub account to mint!

Learn more about GitPOAPs here.