Post-Quantum (PQ) and Post-Quantum/Traditional (PQ/T) hybrid signatures for VCs

[AleCla97]

Description of change

Integration of Post-Quantum (PQ) and Post-Quantum/Traditional (PQ/T) hybrid signatures for VCs

• New features: pqc for PQ related code, hybrid for hybrid related code, pqc-liboqs for the pq signatures implementation based on liboqs, hybrid-liboqs for the hybrid signatures implementation, based on this draft
• JwkStoragePQ: Extension of the JwkStorage for pq keys and Memstore implementation
• Algorithm Key Pair (AKP), new Jwktype for PQ JWKs based on ML-DSA for JOSE and COSE
  draft
• CompositeAlgId: Hybrid keytype MLDSA44/65-ED25519
• DID JWK extension: create a new DID JWK with traditional, pq, hybrid and zk keys
• DIDCompositeJWK, did method for hybrid keys and his relative resolver
• JwtCredentialValidatorHybrid and JwtPresentationValidatorHybrid, hybrid signature validators
• PQCJwsVerifier, verifier for PQ signatures with an implementation based on liboqs
• New examples: pq and hybrid
• Wasm: bindings of the new functions
• Wasm: new examples: pq and hybrid
• Wasm: JwkPqMemStore and PQJwsVerifier implementation of JwkStorage and IJwsVerifier with noble post quantum for ML-DSA

Other changes

• Bump zkryptium and json proof token version to match the latest BBS and JPT drafts

Type of change

Add an x to the boxes that are relevant to your changes.

• Bug fix (a non-breaking change which fixes an issue)
• Enhancement (a non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Fix

How the change has been tested

• cargo test --release to see that there were no incompatibilities.
• the new features were tested through the new pq and hybrid tests( both rust and wasm.)
• the update of zkryptium and json proof token was also tested by running the zkp tests

Change checklist

Add an x to the boxes that are relevant to your changes.

• I have followed the contribution guidelines for this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• 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

[UMR1352]

Hey @AleCla97, sorry for the long silence. I finally have the time to get this PR a to a merge-able state. Would you guys give me access to your fork? That way I can directly push commits there to fix the merge conflicts and adapt you code to the latest version of the library

[AleCla97]

yeah sure :)

I have added you. Let me know if there are any problems!

[UMR1352]

@AleCla97 we are ready to merge, but we have a bad news. We cannot merge this PR until all commits have been signed with either a gpg or ssh key that you add to github (see how my commits as well as @AlbertoSvg have a green "verified" badge next to them?). Would you please look into that? You'll have to set up commit signing and then rebase the branch by re-signing all commits you have authored

[UMR1352]

@AleCla97 another thing, unfortunately for internal policy we'd have to add the IOTA Foundation name along side LINKS in all the license headers, even though we didn't really authored them. Are you guys fine with that? Basically the headers will have both IOTA and LINKS together.

[UMR1352]

@AleCla97 we are ready to merge, but we have a bad news. We cannot merge this PR until all commits have been signed with either a gpg or ssh key that you add to github (see how my commits as well as @AlbertoSvg have a green "verified" badge next to them?). Would you please look into that? You'll have to set up commit signing and then rebase the branch by re-signing all commits you have authored

@AleCla97 we found a workaround to avoid you guys the hassle of rebasing all of this. We can disable that constraint for this PR and I'll squash-merge it so that the merge-commit will be signed by my key. Disregard the above comment.

[AleCla97]

@UMR1352 Thank you! For us, there is no problem having both names on the license headers :)