tomaswolf commented on issue #928: URL: https://github.com/apache/mina-sshd/issues/928#issuecomment-6180441945
> would contributions of pure ml-dsa and pure ml-kem have a chance of being reviewed and potentially included in an apache mina release? Even if experimental at first? Sure. But I'm wary of AI-generated code, though that AI-generated plan isn't all bad. ;-) I see enough of bad or not-so-good AI-written code at work already. (I also see some reasonable code from AIs.) Pure ML-KEM is super easy since we already have the hybrid ML-KEM variants; I've done this in the last hour. (Not pushed yet.) The problem is interoperability tests. This needs a docker container containing some other SSH implementation (preferably a reputable one, not someone else's hobby project) that does pure ML-KEM. Then coding up a unit test testing our client against that third-party server is easy, and there's already a test that tests all implemented key exchanges between our own client and server. So both client and server side are exercised, and interoperability with at least that one third-party implementation would be ensured. With some extra effort one could perhaps even run a third-party client in a container and make it connect to our Java test server running on the host. If we can't test for interoperability, we could at best ship releases that don't enable these algorithms. But that's far from optimal. Pure ML-DSA is a bit more work; it needs public and private keys (with code to read/write them, and that part is a quite a bit more convoluted than I like), and then new built-in signatures. Here I'd really first like to have the hybrid ssh-mldsa44-ed25519: that one we can test for interoperability with stock OpenSSH, and doing pure ML-DSA afterwards is then a piece of cake. But then the pure ML-DSA should also be tested for interoperability, and I haven't found any usable docker container. None for wolfSSH, and the one I found for oqs-openssh is super old (the description still talks about kyber and dilithium -- that's not what we'd need). One minor problem with pure ML-DSA is that the Fluhrer draft does not specify how private keys are stored. [Miller's draft for hybrid ML-DSA](https://datatracker.ietf.org/doc/draft-ietf-sshm-composite-sigs/) does so (private keys are stored as the seed), and whatever would be done for pure ML-DSA in SSH should be compatible with that. So I'd require that private keys be stored as the seed only in SSH format. Also, I'd prefer to do ML-DSA on the 3.0 stream, not in the 2.X stream. (Branch dev_3.0.) 3.0 refactored some things related to security providers, and it has MR-JARs so that one could use Java's built-in ML-DSA implementation on Java versions where it is available. (And BouncyCastle otherwise.) Note that BouncyCastle is an optional dependency. At least it should be possible to use standard JCE interfaces for this. (For KEM we had to use BouncyCastle low-level APIs because javax.crypto.KEM is not available on lower Java versions, and we still want to support Java 8.) If ML-DSA is first done on the main (master) branch, the merge into dev_3.0 could get a bit nasty. Also, the 3.0 stream uses testcontainers 2.x, and has extracted all the container tests from sshd-core to a separate sshd-test project, so that all tests (a) can be run towards the end of the build, since they're relatively long-running and (b) can be run properly with all three I/O libraries (NIO2, MINA, netty). Since ML-DSA needs more things, it should not be a single PR. That would be too big to review properly. A series of PRs implementing this a bit at a time would be better. For instance, first adding the keys and support for reading and writing to and from buffers (wire format), with unit tests. Then support form reading and writing to/from files in OpenSSH format. Then the signature. Then SSH certificates (not sure if anything extra might be needed there). All with unit tests. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
