Bouncy Castle EdDSA / Ed25519 Support

[ianjoneill]

Adds the capability to use Bouncy Castle for EdDSA / Ed25519 support if it's available, so that you don't have to depend on the net.i2p.crypto EdDSA library.

If the net.i2p.crypto EdDSA library is available, that is used in preference to Bouncy Castle - to ensure there is no change for those that are already running with both providers available.

I do not believe this introduces any API breaking changes - all the existing static methods and net.i2p.crypto specific classes are still in place.

Scenarios tested - in all situations on the Mina side ssh-ed25519 was configured as the only available signature factory and an Ed25519 key was used for authentication:

• Mina as SFTP client with only net.i2p.crypto available, connecting to OpenSSH SFTP server
• Mina as SFTP client with only Bouncy Castle available, connecting to OpenSSH SFTP server
• Mina as SFTP client with both net.i2p.crypto and Bouncy Castle available, connecting to OpenSSH SFTP server
• Mina as SFTP server generating an Ed25519 host key with only net.i2p.crypto available, connecting with OpenSSH SFTP client
• Mina as SFTP server generating an Ed25519 host key with only Bouncy Castle available, connecting with OpenSSH SFTP client
• Mina as SFTP server generating an Ed25519 host key with both net.i2p.crypto and Bouncy Castle available, connecting with OpenSSH SFTP client

The generic nature of this implementation makes adding native Java 15+ support with multi-release JARs quite straight forward - once a suitable maven setup has been configured.

[tomaswolf]

Thanks a lot for tackling this.

What happens if neither BC nor net.i2p are present, and we're running on a Java that does have EdDSA/Ed25519? I'm not suggesting to change this so that it uses the Java implementation, if present. But IIRC the net.i2p "EDDSA" name is also used in Java (besides "Ed25519 and "Ed448").

[ianjoneill]

If you're running on e.g. Java 21 without BC or net2.i2p.crypto, it errors out forcing the use any EdDSA/Ed25519 functionality.

e.g. if you configure mina in client mode to only support connecting with ssh-ed25519, it will error out with:

Caused by: java.security.NoSuchAlgorithmException: EdDSA provider not supported
	at org.apache.sshd.common.util.security.SecurityUtils.generateEDDSAPublicKey(SecurityUtils.java:722)
	at org.apache.sshd.common.util.buffer.keys.ED25519BufferPublicKeyParser.getRawPublicKey(ED25519BufferPublicKeyParser.java:46)
	at org.apache.sshd.common.util.buffer.keys.BufferPublicKeyParser$2.getRawPublicKey(BufferPublicKeyParser.java:102)
	at org.apache.sshd.common.util.buffer.Buffer.getRawPublicKey(Buffer.java:573)

Due to there being no SecurityProviderRegistrar available that provides an EdDSASupport implementation.

If you don't specify the signatures when building the mina client, it won't propose ssh-ed25519 - again because there is no applicable EdDSASupport implementation.

[ianjoneill]

Hi @tomaswolf - do you have any other comments on the overall approach? If not, I can take a look at adding some tests.

[tomaswolf]

Not yet. It's on my to-do list, but until now I haven't yet found the time to look at it in detail and to give it a try.

I will eventually get to it; I just don't know yet when. I hope to have some time for this on the week-end before Christmas.

[tomaswolf]

@ianjoneill : I took a closer look. Impressive work; looks very good. You did a great job integrating this into this awfully complex maze of classes dealing with security providers and key handling.

If you have some additional tests to add, by all means do so.

The PR needs to be rebased onto current master.

The documentation about keys would need to be extended to day that ssh-ed25519 is supported if net.i2p.crypto.eddsa or Bouncy Castle are present (and net.i2p is used if both are available). Other places to update:

• https://github.com/apache/mina-sshd/blob/master/docs/files-parsing.md#pemopenssh (last sentence in that paragraph)
• https://github.com/apache/mina-sshd/blob/master/docs/dependencies.md#ed25519-java (completely optional and not recommended, but may have some appeal if someone doesn't have or want Bouncy Castle and prefers to include the small net.i2p library despite it having a security issue)

Apart for that, this looks good to go in.

I ran the JGit tests with an Apache MINA sshd snapshot including this PR and with the net.i2p registrar disabled, and they all worked.

[ianjoneill]

I've rebased, added some tests and updated the docs.

[tomaswolf]

Great, thanks a lot!

[jtnord]

I think this is incorrect as before there was only a single EDSA provider which was never FIPS compliant, now there is a FIPS compliant (bouncycastle) one (when using the FIPS variant) so it should be up to the provider to perform the isFipsMode check and return an empty optional if their EDDSA support is not compliant.

[tomaswolf]

Not sure. I don't see EdDSA listed as an "approved algorithm" in the BC FIPS Security Policy 2.0.0. It's still listed in "Table 6 - Non-Approved Algorithms Not Allowed in the Approved Mode of Operation".

[jtnord]

my mistake I am confusing ECDSA and EDDSA again :-(

[tomaswolf]

OK. I still see the point, though. A future BC-FIPS might have EdDSA as "approved algorithm". It is in NIST SP 800-140C Rev. 2 from 2023-07-25, and is listed at SP 800-140C: Approved Security Functions.

And BC currently has BC FIPS 2.1.0 undergoing validation. So we might have to refactor this approach in the near future.