Live data from Hacker News

OpenSSH 9.5 released with keystroke timing obfuscation

lwn.net

21–30 of 60 posts

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#21

More importantly (IMHO): 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). * https://www.openssh.com/releasenotes.html#9.5 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. NIST's…

Somehow I've never heard of Curve448 or the company Rambus. It's giving me (unfounded) Crypto AG vibes. https://en.wikipedia.org/wiki/Crypto_AG

Rambus was pretty well known for using a submarine patent against RAM manufacturers back in late nineties https://www.edn.com/submarine-patents-could-torpedo-rambus/ followed by fifteen years of acting like a patent troll...

They may have good tech but have an history of being super shady.

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#22
post #9

The release notes do not say why 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?

There is this cool thing I've noticed about software as it matures and this is a good example of that. When you're first starting out on a project, have no users, and its mostly feature incomplete there is little to no drive or reason to care about whole classes of security and performance issues... You're trying to just get the thing to work.

Let's ignore ongoing feature creep and development in projects for now (I'll address this in a second). As the core software becomes functional, gains users, has bugs fixed, the threat model of the software needs to change and grow. Generally software in this state gets progressively more stable and in that stability you can see the tiny ripples of very small edge cases.

For software where security is paramount and has an uncountable number of users protecting uncountable bytes of data like SSH, the tiny ripples of extremely esoteric attacks become a reasonable thing to address as a feature improvement. Do I need this feature for my personal threat model or even the threat model of my company? No probably not... But it doesn't hurt to have it either.

This feature raises the cost of attacking the software, and may dissuade different attacker from even trying. Most of practical security is more about making attacks expensive enough that they attacker will have to spend more than the value of what they would obtain if they were able to break into it and this change helps keep that high watermark well above those thresholds.

For software that does have ongoing feature creep this process is a lot slower but does seem to happen for opensource projects specifically that can survive their infancy sufficiently long enough to become foundational components like SSH and Curl. I've never seen this level stability from closed source software.

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#24
post #16

Earlier quoted context omitted.

Somehow I've never heard of Curve448 or the company Rambus. It's giving me (unfounded) Crypto AG vibes. https://en.wikipedia.org/wiki/Crypto_AG

Strange, I didn't expect Rambus to be involved in cryptography, nor that they would give away the spec and implementation. I guess it was designed to be a smaller die-area solution for some of their silicon IP products, and opening it up just makes it more convenient for their customers to use. (And, hopefully, nobody is stupid enough to use some vendor's secret proprietary crypto in their chips). I'd be interested t…

Rambus bought Cryptography Research about 12 years ago: https://www.rambus.com/rambus-completes-acquisition-of-crypt...

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#25
post #9

The release notes do not say why 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?

There was a recent research paper shared here where it was claimed using keystroke timing and some AI, researchers could predict the password with significant accuracy.

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#26
post #5

Earlier quoted context omitted.

What are the pros/cons of Ed448?

> Ed25519 is one of the two digital signature algorithms today that use the EdDSA algorithm framework. The other is Ed448, which targets a higher security level (224-bit vs 128-bit) but is also slower and uses SHAKE256 (which is overkill and not great for performance). * https://soatok.blog/2022/05/19/guidance-for-choosing-an-elli...

I'm using RSA8192 with SSH and not seeing any noticable performance problems. ECC is generally faster than RSA, so just always using Ed448 or even larger should be a no-brainer.

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#27
post #14

More importantly (IMHO): 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). * https://www.openssh.com/releasenotes.html#9.5 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. NIST's…

Last I checked, Azure didn't support Ed25519 keys, so manual fallback to RSA will now be required. https://feedback.azure.com/d365community/idea/1dca6716-dc25-...

That seems like specifically Azure DevOps, not the Azure platform generally? I assume any OS running inside Azure Compute, or any other managed services will support Ed25519 fine?

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#28
post #14

Earlier quoted context omitted.

Last I checked, Azure didn't support Ed25519 keys, so manual fallback to RSA will now be required. https://feedback.azure.com/d365community/idea/1dca6716-dc25-...

That seems like specifically Azure DevOps, not the Azure platform generally? I assume any OS running inside Azure Compute, or any other managed services will support Ed25519 fine?

The API for creating Azure VMs doesn't support specifying an ED25519 key.

https://docs.microsoft.com/en-us/azure/virtual-machines/linu...

But once you've created the VM you can log in and replace that RSA key with an ED25519 one just like any standard Linux install, via ssh-copy-id or manually updating authorized_keys or whatever you want. So you just need a throwaway RSA key for the initial deployment.

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#30

I'm very proud that we implemented server-side support for the keystroke timing obfuscation mechanism in golang.org/x/crypto/ssh already. (I just clicked the Submit button! https://go.dev/cl/524775 ) 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) d…

Why does the server side need support for that? Is it the ping/pong feature mentioned in the OpenSSH announcement?
Post reply on HN