tomaswolf commented on PR #591:
URL: https://github.com/apache/mina-sshd/pull/591#issuecomment-2327379523
So here's another commit on top of this PR for this single flag. See the
commit message.
With this, I think you don't need the
`FIPSBouncyCastleSecurityProviderRegistar` anymore, and the
`FIPSRegistarInitPlugin` can just do
```
System.setProperty("org.apache.sshd.security.fipsEnabled", "true");
System.setProperty("org.apache.sshd.security.defaultProvider", "BCFIPS");
```
If the flag is set, a number of non-FIPS-approved crypto-algorithms get
disabled (ed25519, curve25519, curve448, sntrup761, bcrypt, chacha20-poly1305).
Disabling sntrup761 and curve25519 means that this FIPS mode is left without
any post-quantum key exchange method.
[FIPS 203](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf) has
come out recently; it specifies the post-quantum ML-KEM key encapsulation
method. There is a [draft
RFC](https://datatracker.ietf.org/doc/html/draft-kampanakis-curdle-ssh-pq-ke-04)
for incorporating this into SSH as key exchange algorithm. Once OpenSSH has
support for this and Bouncy Castle also provides these ML-KEM instances, we can
add them easily. At that point there would be mlkem1024nistp384-sha384
available as (I believe) FIPS-compliant post-quantum algorithm. When we do have
that algorithm, I think we should keep it enabled even in FIPS mode.
Can you test that this works for your use case in Jenkins?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
