Expect to solve the security issues of eddsa

[SomerGG]

my xrpl4j version

<dependency>
      <groupId>org.xrpl</groupId>
      <artifactId>xrpl4j-client</artifactId>
      <version>4.1.0</version>
</dependency>
<dependency>
      <groupId>org.xrpl</groupId>
      <artifactId>xrpl4j-core</artifactId>
      <version>4.1.0</version>
</dependency>

Dependencies with security issues

<dependency>
      <groupId>net.i2p.crypto</groupId>
      <artifactId>eddsa</artifactId>
</dependency>

GHSA-p53j-g8pw-4w5f, Score: 4.3
The implementation of EdDSA in EdDSA-Java (aka ed25519-java) through 0.3.0 exhibits signature malleability and does not satisfy the SUF-CMA (Strong Existential Unforgeability under Chosen Message Attacks) property. This allows attackers to create new valid signatures different from previous signatures for a known message

[sappenin]

Thanks for filing this issue. Per #630, the net.i2p.crypto dependency is not actually used in xrpl4j (it's a false-positive). Instead, this dependency is coming from the crypto-conditions library (which can use the ed25519 crypto condition) however, xrpl4j (and XRPL more generally) doesn't support ED25519-SHA256 crypto-conditions. The only type of crypto-condition supported by the XRPL is the PREIMAGE-SHA256 type, which doesn't use ECDSA at all.

In addition, for anything related to ECDSA, xrpl4j is using BouncyCastle, which doesn't have the problem referenced above.

All that to say, #630 should remove the false positive here.

Note also that if you have software that relies on the net.i2p.crypto.eddsa dependency, then str4d/ed25519-java#96 is the ticket to watch and potentially comment on.

[sappenin]

Closing this for now as a dup of #630. However, please re-open if I've missed anything.

[SomerGG]

Closing this for now as a dup of #630. However, please re-open if I've missed anything.

Thanks for your reply, There is also net.i2p.crypto in this dependency

<dependency>
      <groupId>com.ripple.cryptoconditions</groupId>
      <artifactId>jackson-datatype-cryptoconditions</artifactId>
</dependency>

Will they be excluded together？

[sappenin]

Will they be excluded together？

Good catch, yes all instance of the net.i2p.crypto should be excluded as part of #630. I'll update #630 with a note about that.