nbaars
Tuweni project appears to be unmaintained, switch to other options?
Is your feature request related to a problem? Please describe. The Tuweni project appears to be abandoned, with the Apache Incubator repository being archived. A fork by the original author exists, but besides one version it has also not seen any updates. Without maintenance of the library this could lead to bugs and vulnerabilities not getting addressed.
Describe the solution you'd like Perhaps switching to BouncyCastle or other libraries might be an option.
Describe alternatives you've considered None
Additional context
Thanks for submitting your first issue, we will have a look as quickly as possible.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
@ghsa-retrieval correct we need to move away from Tuweni. Do you have interest in picking this up?
@nbaars I would be interested in this. Replacing the library could be challenging though, as we need to ensure that it remains fully compatible with how libsodium works.
@robertguetzkow would be great if you can pick this up! let me know if you need any help.
@nbaars I'll give it a try. What would be your preferred approach, should we use a specific provider (like Bouncy Castle) or just implement generically against JCA? The decision may have impact on the minimum required Java version to support all cryptographic algorithms.
Using a specific provider is fine. Bouncycastle is already used in the project.
Will do. Currently quite busy at work though, so it might take a bit until I can implement it.
I'm starting to map out what changes are needed and in particular how libsodium and Bouncy Castle implement their Ed25519. I need to check whether or not we can ensure that the validation rejects the same inputs, e.g. libsodium performs small-order checks.
Sorry for the long delay. Seems that Bouncy Castle performs comparable checks to libsodium. Since both v2 and v4 have an overlap in cryptographic primitives, would it be ok if we move them to commons? I would also like to add the test vectors that libsodium uses, so we can be sure that our Bouncy Castle based implementation works as intended and accepts/rejects the same inputs.
Edit: The implementation can be nearly identical to v4. The only aspect that I'm still unsure about is the encoding of the private key. Libsodium expects 64 bytes that contain a concatenation of private and public key. The current implementation of tests for v4 seems to convert from this format using JcaPEMKeyConverter and passes the object containing the 32 bytes key (+2 bytes in internal representation). I might be missing something, but it seems that the private key format handling is not consistent as v2 takes the 64 bytes as-is.
I will let you know once the PR is ready. Unfortunately, work is keeping me busy so I did not get around to it during the week and I currently have other obligations.
If you do have requirements regarding the organization of cryptographic functions and expected input format for v2 vs. v4, please let me know.
@nbaars Thank you for fixing this and apologies for not following up. Unfortunately work has kept me more busy than anticipated and I didn't have time to work on this.