hiero-ledger / hiero-ledger/hiero-consensus-node
Crypto Library
- Dominant language
- Java
- Stars
- 406
- Forks
- 226
- Avg merge
- 3d 4h
- Merged PRs (30d)
- 210
Description
The platform currently uses a few different third party cryptography libraries:
- `secp256k1`
- `libsodium`
- `bouncycastle`
Create a consolidated cryptography library that exposes only the functions required by the consensus node and uses as little external code as possible. For the native librarieswe currently use call JNI wrapper libraries (`org.hyperledger.besu:secp256k1` for `secp256k1`, and [`lazysodium`](https://github.com/terl/lazysodium-java) for `libsodium`), replace these with custom wrappers (either JNI or ProjectPanama) that invoke the respective native binaries that we build ourselves. For `bouncycastle`, we should take the minimum amount that we need from it and just make it part of the crypto library.
The crypto library API should use PBJ data types like `Bytes` and deal with immutable objects. There should not be any threading or thread safety - this will be left to the caller.
Contributor guide
Research direction
Start by mapping the consensus node's current uses of secp256k1, libsodium, and bouncycastle. Define the consolidated library's required API around PBJ types and immutable objects, including the native wrapper approach and the stated threading boundary. Done means the required functions are provided without the existing third-party wrapper dependencies.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- cryptography
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100