tomaswolf commented on issue #915: URL: https://github.com/apache/mina-sshd/issues/915#issuecomment-5749980425
I haven't looked at PQ signatures in detail yet; AFAIK the jury is still out on how exactly to support these in SSH. (Which PQ algorithms? Hybrid construction or not? Or both? If hybrid, which combiner shall be used? Which exact instantiations of which algorithms?) There are lively discussions on the IETF SSH mailing list about this, and there are multiple draft RFCs. But basically I think: * there will be new key types. * with new signatures. * the rest of the SSH handling will be left largely untouched. * chances are high that SSH will go for a hybrid construction (PQ combined with a classical algorithm) New key types will mean new code for serializing and deserializing to wire format. It will need new reader/writer classes to deal with keys in files. Hybrid keys will actually have two public keys (a PQ one and a classical one), and two private keys. There will be new BuiltinSignature instances for PQ and combined signatures. Some general operations like comparing keys or generating keys will need to be adapted to be able to compare or generate PQ or combined keys in addition to the classical keys. There may be some work to do to deal with the selection of the SecurityProvider for PQ keys and signatures (SecurityProviderRegistrar stuff), and different adapter classes depending on the choice (BC vs. JDK on JDKs that offer built-in PQ algorithms). Existing places currently working with one of the already established key types will most likely not need to change. I think when PQ signatures are introduced in Apache MINA SSHD we'll do so only in the upcoming 3.0 major version, but not in the 2.X stream. Your estimate of 5-12 months, if that's person-days, strikes me as massively overestimated for the above. Looking at your report data, it seems to me that the evaluation is basically flawed. First, it makes no sense to include test classes. In regression tests it is perfectly fine to use a low-security key for authentication (or even plain password authentication) if the topic of the test is not high-security public-key authentication. Second, adding support for PQ signatures is not "replacing classical signatures", so there is no need to "migrate" existing code paths dealing with classical key and signature types. Some PQ signatures or keys can be huge and may be larger than a normal SSH packet. If such key or signature types are chosen for SSH, some way to deal with them in the SSH transport protocol needs to be found. Such protocol amendments would likely add significant complexity. Somewhat off-topic: in the SSH authentication protocol, signatures are ephemeral and short-lived. Using PQ signatures in SSH is more interesting for use as stand-alone SSH signatures, as used for instance for signing git commits. But there the signature size is an important consideration. If every commit object in a git repo is huge because of some huge PQ signature attached it might negatively impact the performance of git. -- 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]
