Bouncy Castle Sk-EdDSA / Sk-Ed25519 Support

[atlEdP]

Description

Recently in 2.15 PR #639 (SSHD-988) was implemented so that we can remove dependancy on net.i2p

However the security key variant (specifically usage of SkECDSAPublicKeyEntryDecoder.java and SkED25519PublicKeyEntryDecoder.java) are not included in this change, and still require net.i2p. This means if we use sk we cannot move off net.i2p to Bouncy Castle.

Suggest to update the sk keys to also have support for Bouncy Castle.

Motivation

We cant truly remove net.i2p which has a security weakness if we utilise sk keys

Alternatives considered

No response

Additional context

No response

[tomaswolf]

Correct. Unfortunately the class SkED25519PublicKey references class net.i2p.crypto.eddsa.EdDSAPublicKey in its public API, so this cannot be fixed without breaking API.

We can fix this for sure in a future new version 3.0 (API breaks are fine on major version number bumps), but in the 2.X stream, I don't see how it could be done without breaking API.

Maybe we could risk an API break all the same? On the client side, I think SK keys are currently unusable anyway since the required native interface and configuration are missing, and if they existed, they aren't used, and on the server side, all uses of SK keys are probably deep in the framework itself and user code never cares about them: a server only needs to be able to reconstruct the underlying ed25519 key from binary data sent as an sk-ed25519 key (or possibly from authorized_keys).

In particular, fixing this would require changing

public class SkED25519PublicKey implements SecurityKeyPublicKey<EdDSAPublicKey> {

to

public class SkED25519PublicKey implements SecurityKeyPublicKey<PublicKey> {

which widens the return type on SkED25519PublicKey.getDelegatePublicKey() and is thus not binary compatible.

I wonder if there is existing user code that would have a problem with this...

[tomaswolf]

Fixed in bca964c.