More from last month:<p><a href="https://news.ycombinator.com/item?id=37307708">https://news.ycombinator.com/item?id=37307708</a> (258 comments)
More importantly (IMHO):<p><pre><code> ssh-keygen(1): generate Ed25519 keys by default. Ed25519 public keys
are very convenient due to their small size. Ed25519 keys are
specified in RFC 8709 and OpenSSH has supported them since version 6.5
(January 2014).
</code></pre>
* <a href="https://www.openssh.com/releasenotes.html#9.5" rel="nofollow noreferrer">https://www.openssh.com/releasenotes.html#9.5</a><p>Previously, if you didn't specify "-t", you got RSA keys; now you get Ed25519, and if you want RSA you have to ask for it.<p>NIST's publication of FIPS 186-5 in February (2023) added Ed25519 and Ed448 as approved (? allowed?) algorithms:<p>* <a href="https://csrc.nist.gov/publications/detail/fips/186/5/final" rel="nofollow noreferrer">https://csrc.nist.gov/publications/detail/fips/186/5/final</a><p>* <a href="https://en.wikipedia.org/wiki/EdDSA#Standardization_and_implementation_inconsistencies" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/EdDSA#Standardization_and_impl...</a><p>Partly one of the reasons given for the default switch:<p>* <a href="https://lists.mindrot.org/pipermail/openssh-unix-dev/2023-September/040932.html" rel="nofollow noreferrer">https://lists.mindrot.org/pipermail/openssh-unix-dev/2023-Se...</a><p>Curious to know if/when the OpenSSH folks will add Ed448 (RFC 8709, like Ed25519).
I'm very proud that we implemented server-side support for the keystroke timing obfuscation mechanism in golang.org/x/crypto/ssh already.<p>(I just clicked the Submit button! <a href="https://go.dev/cl/524775" rel="nofollow noreferrer">https://go.dev/cl/524775</a>)<p>It's a small change, but it's a signal that we're much more on top of x/crypto/ssh maintenance, compared to a year ago when we had to scramble to implement rsa-sha2-256/512 support just hours before GitHub (rightfully) dropped SHA-1 support, potentially breaking every x/crypto/ssh client.<p>The main reason is that thanks to the funding of my clients (<a href="https://words.filippo.io/full-time-maintainer/" rel="nofollow noreferrer">https://words.filippo.io/full-time-maintainer/</a>) I was able to hire Nicola Murino, the maintainer of SFTPGo, to pick up maintenance of x/crypto/ssh. This is benefiting both my clients and the whole ecosystem, and is a little step in growing the professional maintainer model.
The link that was (originally) submitted is to LWN just posting the release notes. The direct link(s) to the release notes is:<p>* <a href="https://www.openssh.com/txt/release-9.5" rel="nofollow noreferrer">https://www.openssh.com/txt/release-9.5</a><p>* <a href="https://www.openssh.com/releasenotes.html#9.5" rel="nofollow noreferrer">https://www.openssh.com/releasenotes.html#9.5</a>
The release notes do not say <i>why</i> there is a need to obfuscate keystroke timings. I guess it is designed to mitigate some attack vector? Is it already being exploited in the wild or... let's say is purely of academic interest?
If you use OpenSSH (wink), please consider donating to OpenBSD, aka the upstream developers: <a href="https://www.openbsd.org/donations.html" rel="nofollow noreferrer">https://www.openbsd.org/donations.html</a>
> This attempts to hide inter-keystroke timings by sending interactive traffic at fixed intervals (default: every 20ms) when there is only a small amount of data being sent. It also sends fake "chaff" keystrokes for a random interval after the last real keystroke. These are controlled by a new ssh_config ObscureKeystrokeTiming keyword.<p>So does it send these phantom keystrokes only when there are real keystrokes?<p>On first reading I thought it sends periodic+random keystrokes and so {Client,Server}AliveInterval option(s) may not be required to keep the connection alive. Need to try and confirm the behaviour.<p>This version also changes ssh-keygen to generate ed25519 keys by default. Time to update scripts that generate keys without a '-t' arg.