Control: severity -1 wishlist On Sun, Jan 26, 2025 at 03:56:29PM +0200, Martin-Éric Racine wrote: > In its postinst, openssh-server currently generates host keys with upstream > defaults. While there's nothing inherently wrong with that, a more proactive > approach to strong cryptography might be desirable. > > The homepage of the auditing tool 'ssh-audit' suggests [1] using the > following keygen recipes instead: > > ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N "" > ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N "" > > The key difference with upstream defaults (and openssh-server postinst) and > the above is the enforcement of 4096-bit RSA keys. > > It would be extremely desirable for Debian to implement this out of the box.
ssh-keygen's current default for RSA is 3072 bits. I know people always go for "bigger is better", but that's not actually quite clear here. Firstly, why 4096? People often seem to get there by just doubling 2048 because doubling feels like a natural thing to do with computers, but it's not obvious that there's a particular reason to do that here. NIST SP 800-57 Part 1 Revision 5 estimates that breaking 3072-bit RSA keys is about a factor of 2^16 more work than 2048-bit, and says that the security level of 3072-bit RSA keys is acceptable through 2031 and beyond. (NIST SP 800-56Br2 estimates that breaking 4096-bit is a further factor of 2^24 more work on top of that.) Given that that's the latest time window they specify anything for, I interpret that as "it's not yet worth trying to guess what the landscape is going to look like after that". Secondly, RSA's performance gets noticeably worse with very large key sizes. Signing with a 4096-bit key is on the order of three times as slow as signing with a 3072-bit key. Admittedly, this is just the host key so it probably only matters for things like key exchange on connection establishment and rekeying; but if the difference is between completely impractical to attack with any vaguely suspected non-quantum-computer technology for the foreseeable future and even more completely impractical to attack, it's not clear that it's worth the trouble. Thirdly, OpenSSH prefers to use Ed25519 host keys if it can agree those between server and client. Those have an estimated security strength of 128 bits, the same as 3072-bit RSA (as well as being faster, and better-designed to defend against side-channel attacks) - so it's not clear it's worth fiddling with the RSA host key length. Fourthly, by the time any even remotely plausible attacks on 3072-bit RSA keys appear, I suspect we'll mostly be using different host key algorithms anyway. Maybe that's Ed448, or maybe it's some kind of PQC thing (on which I am in no way an expert). My crystal ball isn't really up to the task. Fifthly, the ssh-audit hardening guide doesn't give any particular argument for why 3072-bit RSA keys are inadequate here. It amounts to "bigger is better" - OK, but that's not actually a reason for stopping at 4096 either, and so I'd rather have well-reasoned opinions from cryptographers. The current upstream defaults and things like NIST standards are my best available proxy for that. For all these reasons, I'm disinclined to say that I know better than upstream here. 3072-bit RSA seems like a fine default at the moment, and I expect that Debian will follow future changes made upstream. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
