Finally! I wish OpenSSH also plan making RSA optional at build time, and set a timeline for removal shifted 1 or 2 years after DSA.
We are also likely to start exploring a post-quantum signature algorithm soon and are mindful of the overall size and complexity of the key/signature code.
That’s great news, if OpenSSH contributors commit to adding post-quantum cryptography, it’s bigger news than DSA removal.
Good point, we just dodged a bullet there. It’s worrying and reassuring at the same time. If it wasn’t for NIST’s open process for selecting new algorithms, they might not have discovered SIKE is broken until after it become a standard. Thankfully NIST has a years long, multi-round process for algo selection, where each team (and the public) can try to crack competitors’ algorithms. This helps filter out weak ones before making a final decision on the standard algo.
That’s doable for the server - but an OpenSSH client without RSA support will be useless for the next one or two decades, assuming the various appliance and cloud vendors react faster than they usually do.
Different timelines could be set for client and server, for instance by disabling RSA by default for server software first, and 2 years later for client software.
As the article explain, optional doesn’t mean it’s gone. Distributions can and already distribute a separate version for OpenSSH with old algorithms (eg for sshv1) for people forced to work with old servers. Even if distributions do not, anyone can also build OpenSSH themselves with whatever option they want.
Finally! I wish OpenSSH also plan making RSA optional at build time, and set a timeline for removal shifted 1 or 2 years after DSA.
That’s great news, if OpenSSH contributors commit to adding post-quantum cryptography, it’s bigger news than DSA removal.
The problem seems to be finding a post-quantum algorithm that doesn’t get obliterated by pre-quantum computers like what happened to SIKE:
https://m-cacm.acm.org/news/269080-nist-post-quantum-cryptography-candidate-cracked/fulltext
Good point, we just dodged a bullet there. It’s worrying and reassuring at the same time. If it wasn’t for NIST’s open process for selecting new algorithms, they might not have discovered SIKE is broken until after it become a standard. Thankfully NIST has a years long, multi-round process for algo selection, where each team (and the public) can try to crack competitors’ algorithms. This helps filter out weak ones before making a final decision on the standard algo.
That’s doable for the server - but an OpenSSH client without RSA support will be useless for the next one or two decades, assuming the various appliance and cloud vendors react faster than they usually do.
Different timelines could be set for client and server, for instance by disabling RSA by default for server software first, and 2 years later for client software.
As the article explain, optional doesn’t mean it’s gone. Distributions can and already distribute a separate version for OpenSSH with old algorithms (eg for sshv1) for people forced to work with old servers. Even if distributions do not, anyone can also build OpenSSH themselves with whatever option they want.